MySQL
难道没人做渗透测试吗？测试人员看到自增ID就兴奋，直接判定为可遍历漏洞。没有一劳永逸的解决方案，所有措施旨在提高攻击成本。如果仅用自增ID而无其他防护，爬虫通过接口如id123可轻易获取全部数据。若采用无序ID，并模拟页面操作，最多也只能爬取部分数据。因此，无序ID相比有序ID更安全。其次，这是一种规范化的做法。虽然你自己清楚哪些数据敏感，也知道接口需要添加权限和频率限制，以防止数据被随意遍历，但你无法确保同事是否有同样的意识，也无法保证当前项目或后续接手的人是否能做到位。因此，不如统一使用无序 ID，这样即便出现问题，影响范围也会更小，责任也更容易界定。数据虽然有自增ID，但实际并未使用，那这个自增ID到底有何意义？这是我一直存在的疑问。如果说它是为提升查询效率而存在，但在单表情况下，我宁愿选择分表；对于联表查询，要么拆分，要么给主表加字段。我曾参与过系统迁移工作，涉及不同数据库间的数据迁移，同时新旧系统并行、数据同步，这种场景下，使用UUID确实更简便高效。第一版简单说渗透到数据库，第二版详细讲接口，认真读过就不该再以为是渗透数据库了。对于评论中提到的
MySQL特性，我都有点赞支持。把这个东西当作猴一样展示，让大家开开眼。如果按业务场景区分，非敏感信息用ID随意爬取也无所谓。原本隐私泄露的漏洞，不被发现就无法称为漏洞。大家知道信息为何被不靠谱的程序员泄露给骗子和销售了吗？比如开车，没人是为了撞车而开的，确保不发生
事故是首要目标。但万一出了意外，防撞梁、安全气囊、安全带肯定得配备齐全。不能因为觉得自己不会出事，就为了节省成本而不安装这些安全配置吧？
