MySQL随机生成唯一ID：用数组排除已知ID的方案是否安全可行？

你的方案在小数据量场景下是可行的，但存在扩展性、性能和并发可靠性方面的明显局限，下面针对你的疑问逐一拆解：

1. 安全问题 #

• 客户端篡改风险：完全不用担心。你用的random_int()是服务端执行的PHP代码，生成逻辑、数据库查询、ID检查全在服务器端完成，客户端关闭JavaScript、修改Cookie根本碰不到这部分代码，自然不存在篡改源码的可能。
• 劫持与枚举风险：如果这个6位ID是直接暴露给用户的（比如作为URL参数、订单号），攻击者确实可以通过枚举000000-999999来遍历所有资源——这是6位ID长度太短的问题，和你的生成方案无关。另外，random_int()是密码安全级别的随机函数，本身不会被预测，只要ID不被轻易枚举，就不存在生成逻辑被劫持的风险。
• 重复ID风险：单线程下没问题，但高并发场景会出现竞态条件：两个请求同时生成相同ID，都通过了预检查，然后同时写入数据库，导致ID重复——这是这个方案最核心的可靠性隐患。

2. 性能问题 #

• 小数据量（几万条以内）：几乎没影响，全量查询ID和数组检查的开销都可以忽略。
• 数据量增大（几十万条）：
  • 数据库查询：SELECT id FROM table会返回几十万条数据，占用数据库带宽和服务器内存；
  • 内存与CPU：把几十万条ID存在数组里，每次生成新ID都要遍历数组检查，CPU开销会明显上升，生成ID的耗时会越来越长；
  • 并发压力：多个请求同时执行全量查询，会快速消耗数据库连接池，导致服务器延迟升高。

服务器端方案的优劣 #

优势 #

• 实现简单，逻辑直观，初期开发和维护成本极低；
• 生成的ID是无规律的，相比自增ID能隐藏数据规模，避免用户通过ID推断业务量。

劣势 #

• 扩展性极差：6位ID最多只能容纳90万个唯一值，数据量接近这个上限时，生成有效ID的时间会指数级增长，直到完全无法生成；
• 并发可靠性差：高并发下极易出现重复ID，破坏数据唯一性；
• 资源浪费：每次生成ID都要全量查询数据库，属于冗余操作，放大了数据库压力。

优化建议 #

如果想继续使用随机ID方案，推荐这些改进方向：

• 增加ID长度：改成8位或10位随机数，可用ID数量瞬间提升几个数量级，既降低碰撞概率，也能大幅增加枚举难度；
• 替换全量查询为单条检查：不要加载所有ID到内存，生成单个ID后直接用数据库查询验证是否存在，比如执行SELECT EXISTS(SELECT 1 FROM your_table WHERE id = ?)，内存开销几乎为0，数据库压力也小很多；
• 解决竞态条件：在生成ID并写入数据库的流程中，使用数据库事务（带排他锁）或分布式锁，确保同一时间只有一个请求能验证并写入某个ID；
• 预生成ID池：提前批量生成一批未使用的ID存入数据库，每次需要时直接从池里取出，避免实时生成和检查的开销。

内容的提问来源于stack exchange，提问作者Antonio