自增主键通常提升写入效率，因数据按序存储避免页分裂；uuid等非连续主键易致性能下降；仅在分库分表、id重用或前端暴露时自增主键才可能有害。
自增主键本身不降低索引性能，反而通常提升写入效率
MySQL 中使用 AUTO_INCREMENT 的整型主键（如 INT 或 BIGINT）作为聚簇索引（InnoDB 默认），数据物理存储按该主键顺序排列。这意味着新记录总是追加到索引页末尾，避免页分裂和随机磁盘寻址——这对高并发 INSERT 场景非常友好。
常见误解是“自增会导致索引变大、查询变慢”，但实际影响来自字段类型和索引设计本身，而非“自增”这个属性。真正拖慢查询的是：没有合理覆盖查询条件的二级索引、主键过大（比如用 VARCHAR(255) 做自增主键）、或在自增列上做范围扫描却缺乏有效过滤。
为什么 UUID 或雪花 ID 作为主键更容易引发性能问题
当用非连续值（如 UUID()、SNOWFLAKE）替代自增主键时，InnoDB 聚簇索引无法顺序插入，新行可能被插入到任意中间页，频繁触发页分裂、碎片增加、缓冲池命中率下降。实测中，相同写入量下，UUID 主键的 INSERT 吞吐常比自增主键低 30%–60%，且 SELECT ... WHERE id = ? 的缓存局部性更差。
-
UUID是 128 位字符串，占用空间大，导致二级索引中每条记录的PRIMARY KEY复制体积更大 - InnoDB 的
adaptive hash index对非顺序键效果减弱 - 备份/恢复、主从复制时 binlog 中的行镜像体积更大，网络和磁盘压力上升
自增主键在什么情况下反而有害
只有当业务强依赖“全局唯一可预测性”或需要跨分片/多主同步时，纯自增才成瓶颈。例如：
- 分库分表场景下，多个 MySQL 实例各自维护
AUTO_INCREMENT，ID 易冲突（需配合auto_increment_offset和auto_increment_increment调整） - 逻辑删除 + 高频重用 ID 的场景（如回收
id=1001后再次分配），可能引发二级索引指针混乱（虽 InnoDB 允许，但应用层难追踪） - 误把自增主键当成业务标识暴露给前端（如
/api/user/123），导致数据量可被枚举、爬虫遍历风险上升
此时应分离「数据库内部标识」与「对外业务 ID」，用独立字段（如 external_id CHAR(16) UNIQUE）承载可读/安全需求。
如何验证当前主键索引是否健康
直接查 information_schema.INNODB_METRICS 或使用 SHOW INDEX FROM table_name 观察 Cardinality 是否合理；更实用的是看写入时的锁等待和页分裂指标：
SELECT
NAME,
COUNT
FROM information_schema.INNODB_METRICS
WHERE NAME IN ('innodb_dblwr_writes', 'innodb_page_splits', 'innodb_rows_inserted');
若 innodb_page_splits 持续高于 innodb_rows_inserted 的 5%，说明插入热点分散、页利用率低——大概率不是自增的问题，而是主键被人为打散（比如设置了 innodb_autoinc_lock_mode = 0 且混用 INSERT ... SELECT），或用了非单调字段做主键。
真正要注意的，从来不是“要不要自增”，而是“主键是否最小、稳定、无业务含义、且能支撑写入模式”。其他所有优化，都建立在这个基础上。
