MySQL的InnoDB存储引擎默认使用B+树作为索引结构，主键索引是聚簇索引，数据行直接存储在主键索引的叶子节点中。当插入新数据时，InnoDB需要根据主键的值找到对应的插入位置，自增ID的特性让这个插入过程更加高效。
自增ID的写入特性
自增ID的核心特性是每次插入新记录时，ID值会自动递增，新插入的ID一定比之前所有记录的ID都大。对于B+树来说，新的记录会直接追加到当前最后一个数据页的末尾，不需要在已有的数据页中间寻找插入位置。
这种顺序写入的模式和磁盘的顺序读写特性高度契合，能减少磁盘的随机IO操作，提升数据写入的效率。如果使用的是UUID或者业务自定义的无序主键，新插入的主键值可能落在已有的两个主键值之间，就需要在已有的数据页中间插入数据。
什么是页分裂
InnoDB中数据是按页存储的，默认每页大小是16KB，一个数据页中存储了多行数据，数据行按照主键的顺序排列。当一个数据页已经写满，又需要往这个页中插入新的数据时，InnoDB就会触发页分裂操作。
页分裂的过程是：创建一个新的数据页，把原数据页中一半的数据移动到新页中，然后调整前后数据页的链表指针，再把新记录插入到对应的位置。这个过程会带来额外的性能开销，具体影响包括：
- 需要额外的磁盘IO来写入新页和修改原有页的指针
- 分裂后的两个数据页空间利用率都会下降，可能出现很多碎片空间
- 频繁页分裂会导致B+树的结构变得不够紧凑，增加索引的层级，降低查询效率
自增ID如何减少页分裂
自增ID的插入顺序和B+树的叶子节点顺序完全一致，新记录永远插入到最后一个数据页的末尾。只有当最后一个数据页写满时，才会创建新的数据页，新的数据页只需要追加到原有页的后面即可，不需要拆分已有的数据页。
我们可以通过一个简单的示例来对比两种主键的插入表现，首先创建两个测试表，一个使用自增ID做主键，一个使用无序的UUID做主键：
-- 自增ID主键表
CREATE TABLE test_auto_id (
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(50),
create_time DATETIME
) ENGINE=InnoDB;
-- UUID主键表
CREATE TABLE test_uuid_id (
id VARCHAR(36) PRIMARY KEY,
name VARCHAR(50),
create_time DATETIME
) ENGINE=InnoDB;
接下来分别向两个表中插入10万条测试数据，自增ID表的插入过程几乎不会出现页分裂，而UUID表的插入过程中会频繁触发页分裂，插入耗时通常是自增ID表的2到3倍。
页分裂对性能的实际影响
我们可以通过SHOW TABLE STATUS命令查看表的碎片率，碎片率越高说明页分裂带来的空间浪费越严重。执行以下命令查看两个测试表的状态：
SHOW TABLE STATUS LIKE 'test_auto_id'; SHOW TABLE STATUS LIKE 'test_uuid_id';
对比两个结果的Data_free字段，UUID主键表的Data_free值会明显更高，说明存在更多的碎片空间。同时UUID主键的B+树层级也会更高，因为页分裂导致每个页存储的数据行更少，相同数据量下需要更多的页来存储。
自增ID的适用场景和注意事项
自增ID适合大多数业务场景，尤其是写多读少、需要高频插入数据的场景。但需要注意以下几点：
- 自增ID的值可以被预测，不适合需要隐藏数据量的业务场景，比如用户ID如果自增，容易被遍历猜测用户数量
- 自增ID在分布式场景下可能存在冲突问题，需要结合分布式ID生成方案，比如雪花算法生成的趋势递增ID，同样具备顺序写入的优势
- 如果业务已经有天然的趋势递增字段，比如创建时间，也可以考虑用该字段做主键，同样能减少页分裂
总结
MySQL建议使用自增ID做主键的核心原因，就是自增ID的顺序特性匹配B+树的存储结构，能避免无序插入带来的频繁页分裂问题，从而提升插入性能、减少空间碎片、保持索引结构的紧凑性。在实际表结构设计时，如果没有特殊的业务需求，优先选择自增ID或者趋势递增的ID作为主键，是性价比很高的优化手段。