MySQL的AUTO_INCREMENT不支持随机化，强行实现会导致主键冲突、插入失败等问题；应保留其作内部主键，另用UUID、雪花ID或混淆哈希生成对外暴露的不可预测ID，并加唯一索引和防枚举措施。
MySQL 的 AUTO_INCREMENT 本身不支持“随机化”，强行让它“随机”会破坏其设计逻辑，反而引发主键冲突、插入失败、索引碎片等问题。真正可行的方案是：**放弃自增ID作为对外暴露的业务ID，改用独立生成的随机/不可预测ID字段**。
为什么不能把 AUTO_INCREMENT 设成随机值
MySQL 的 AUTO_INCREMENT 是一个严格递增（或按步长递增）的计数器，由存储引擎（InnoDB）内部维护。它不接受手动指定非递增值（除非显式插入，但会破坏后续自增行为）。常见错误尝试包括：
- 执行
INSERT INTO t (id, name) VALUES (FLOOR(RAND()*1000), 'x')—— 这只是“绕过自增”，不是“让自增变随机”；一旦某次插入没指定id，就会触发AUTO_INCREMENT继续从上次最大值+1开始，导致混乱 - 试图用触发器在
BEFORE INSERT中修改NEW.id—— InnoDB 会报错ERROR 1363: Cannot modify AUTO_INCREMENT value in trigger - 用
ALTER TABLE ... AUTO_INCREMENT = N配合随机数 —— 只能设整数起点，无法动态跳变，且无并发安全保证
真正防爬的有效替代方案
核心思路：保留 AUTO_INCREMENT 作为内部主键（用于关联、索引、性能），另加一个 external_id 字段用于对外暴露（如 URL、API 返回、前端展示）。这个字段必须满足：唯一、不可预测、无序、可索引。
推荐做法：
-
用
UUID()直接生成：类型设为CHAR(36)或BINARY(16)（后者更省空间且索引更快）。插入时直接赋值：INSERT INTO users (external_id, username) VALUES (UUID(), 'alice') -
用雪花 ID（Snowflake）在应用层生成：Java/Python/Go 等语言都有成熟库（如
twitter-snowflake、py-snowflake），生成 64 位数字 ID，含时间戳+机器号+序列号，全局唯一且大致有序，但对爬虫来说仍难以推测下一条 -
用加密哈希 + 自增ID 混淆：例如
HEX(SHA2(CONCAT(id, 'salt_abc123'), 256))，但需确保盐值保密且不泄露原始id，否则仍可反推
注意：无论哪种方式，都必须给该字段加 UNIQUE 约束，并建索引，否则插入重复会失败且难排查。
如果坚持用纯数字随机ID，必须处理冲突
若业务强要求 6–10 位纯数字 ID（如订单号），又不想用 UUID，可用以下带重试的存储过程，但务必理解代价：
DELIMITER $$
CREATE PROCEDURE insert_with_random_id(IN p_name VARCHAR(50))
BEGIN
DECLARE v_id BIGINT DEFAULT 0;
DECLARE v_count INT DEFAULT 0;
REPEAT
SET v_id = FLOOR(RAND() * 9000000) + 1000000; -- 7位随机数
SELECT COUNT(*) INTO v_count FROM users WHERE external_id = v_id;
UNTIL v_count = 0 END REPEAT;
INSERT INTO users (external_id, username) VALUES (v_id, p_name);
END$$
DELIMITER ;关键风险点：
- 高并发下，重试循环可能卡住或超时（尤其未加索引时）
- 表越大，
SELECT COUNT(*)越慢，应改用SELECT 1 FROM users WHERE external_id = ? LIMIT 1 - 没有事务包裹，极端情况下可能插入重复（需加
INSERT IGNORE或捕获1062错误码）
最容易被忽略的细节
很多人只关注“ID怎么生成”，却忘了暴露路径本身才是爬虫入口。即使 ID 随机，如果 API 允许按 ID 枚举（如 /api/user/123 → /api/user/124），攻击者只需发大量请求就能撞出有效 ID。真正防爬要组合落地：
- 禁用基于 ID 的批量枚举接口（比如不允许
?start_id=1000&limit=100） - 对敏感接口加频率限制、登录态校验、Token 签名
- 前端不渲染原始 ID，用映射表或短期 Token 替代（如
user_abcxyz对应真实external_id） -
AUTO_INCREMENT主键依然保留，别删——它对 JOIN、外键、InnoDB 聚簇索引性能至关重要
