MySQL自增主键适合单机常规场景，但分布式、安全、语义化需求下应慎用或替换；推荐单主无分片场景使用，多活/分库/对外API等场景建议改用UUID或雪花ID，或采用物理主键+逻辑business_id折中方案。
MySQL 自增主键（AUTO_INCREMENT）是最常用、最直观的主键生成方式，但它并非万能解法——是否选用，关键看业务场景和长期可维护性。
优点：简单高效，适合多数常规场景
自增主键天然有序、写入性能高、索引紧凑，对 MySQL 的 B+ 树索引非常友好：
- 插入快：新记录总追加到索引末尾，避免页分裂和随机 I/O；
-
存储省：通常是
INT或BIGINT，仅占 4 或 8 字节，远小于 UUID 或业务字符串； -
查询稳：范围查询（如
id BETWEEN 1000 AND 2000）、分页（LIMIT配合ORDER BY id）效率高； - 开发省心：无需应用层生成或协调唯一 ID，MySQL 自动保证全局递增（单机下）。
缺点：分布式与扩展性受限
自增主键在单实例下表现优秀，但一旦涉及分库分表、主从切换、多写架构，问题就浮现：
-
无法跨实例全局唯一：多个 MySQL 实例各自维护自己的
AUTO_INCREMENT，ID 必然重复； - 主从延迟或故障时 ID 不连续：例如批量插入后主库宕机，部分自增值可能未同步到从库，恢复后出现跳号甚至冲突；
- 不支持预分配或业务语义：无法按时间、租户、区域等维度嵌入信息，也不便于做幂等校验或日志追踪；
-
暴露数据规模风险：ID 连续递增易被爬虫推测总量（如
/user/123456→/user/123457），存在业务安全隐忧。
实用建议：什么情况下坚持用？什么情况下该换？
不必一刀切替换，但要有判断依据：
- 推荐继续用：单主 MySQL、读多写少、无分片需求、ID 无对外暴露要求（如后台管理系统、内部日志表）；
- 建议慎用或替换：需水平拆分（如用户表按 uid 分库）、计划接入多活架构、ID 要嵌入时间/机器信息（如雪花 ID）、或对外提供 API 且需隐藏数据增长节奏；
-
折中方案：保留自增主键作物理主键和聚集索引，同时增加一个
business_id字段（如 UUID 或雪花 ID）作为逻辑主键和外部接口标识，兼顾性能与扩展性。
一个小提醒：自增不是“永远递增”
MySQL 的 AUTO_INCREMENT 值受多种因素影响，并非严格单调：
- 事务回滚会导致已分配的自增值“丢失”，产生空洞；
-
INSERT ... ON DUPLICATE KEY UPDATE可能触发自增但最终未插入； - 重启后 InnoDB 会扫描最大值再加一（而非读取系统变量），若上次是手动
INSERT ... SELECT插入大 ID，重启后可能跳得更远。
因此，永远不要假设自增 ID 是连续、可预测或可用于计数统计的依据。
