连接字段变更加剧页分裂，因其多为随机分布的二级索引，插入/更新易落于b+树中间页，触发搬数据、改指针等标准页分裂；自增仅优化主键尾部追加，对连接字段无效。
为什么连接字段变更会加剧页分裂
连接字段（比如 JOIN 条件中用的外键列）如果本身是频繁更新或非递增的，它很可能就是二级索引。而二级索引的 B+ 树在插入/更新时无法享受主键那种“尾部追加”优化——哪怕主键是自增的，name、status_id、category_code 这类用于连接的字段，只要值分布随机，写入就大概率落在中间页，直接触发标准页分裂：搬一半数据、改父节点指针、可能连带非叶层分裂。
自增序列只对主键有效，别误用在连接字段上
把 user_id 改成 AUTO_INCREMENT 没用，如果它本就不是主键；更不能给 order_status 或 product_type 加自增属性——它们是业务语义字段，不是存储结构控制点。真正起作用的，是让「被 JOIN 的那张表」的主键本身具备趋势递增性，且该主键被另一张表作为外键引用。
- 错误做法：
ALTER TABLE orders ADD COLUMN join_seq BIGINT AUTO_INCREMENT UNIQUE—— 这只是多加一列，不改变orders.user_id索引的物理写入模式 - 正确路径：确保
users.id是BIGINT UNSIGNED AUTO_INCREMENT，且orders.user_id是普通索引（非主键），这样orders表按user_id插入时，虽然仍是随机位置，但至少users表自身不会因连接操作反复分裂 - 若必须高频按非主键字段连接（如
orders.created_date），应建前缀索引 + 控制单次写入批次，避免INSERT ... SELECT扫描全表再批量插入导致二级索引页反复重排
连接场景下真正有效的页分裂缓解手段
与其强行给连接字段套自增，不如从数据流向和索引设计入手：
- 对高频 JOIN 的维度表（如
products、categories），用BIGINT自增主键，并禁用手动INSERT INTO t(id) VALUES(...)—— 避免空洞回填引发中间页插入 - 连接字段若为字符串（如
VARCHAR(32) uuid），不要建为主键，改为CHAR(16) BINARY+UUID_TO_BIN()存储，并在该列上建二级索引；虽不能消除分裂，但比原生VARCHAR(36)减少约 40% 页内空间占用，延缓填满速度 - 批量导入关联数据时，先按连接字段排序（如
ORDER BY user_id），再插入 —— 让二级索引写入尽量局部化，降低单页命中频次 - 监控
SHOW TABLE STATUS LIKE 'orders'中的Data_free值，持续 >5% 表总大小且增长快，说明user_id索引已严重分裂，此时OPTIMIZE TABLE orders比调innodb_fill_factor更直接有效
最容易被忽略的点：连接本身不写盘，但它的索引维护会
SELECT a.*, b.name FROM orders a JOIN users b ON a.user_id = b.id 这条语句不产生页分裂，但后续任何 INSERT INTO orders (user_id, ...) 都会触碰 orders.user_id 索引页。很多人只优化查询，却放任写入路径上的索引持续碎片化。真正的瓶颈往往不在 JOIN 逻辑，而在那个被反复写入的二级索引页是否总在“中间开刀”。
