MySQL聚簇索引：字符型与整型主键的性能差异及原理咨询

先明确聚簇索引的核心逻辑 #

MySQL InnoDB的聚簇索引，叶子节点直接存储完整的行数据，所有数据都是按照索引键的顺序物理排列的——这是理解两者差异的基础。

1. 索引键的本质差异 #

• 整数型主键（INT/BIGINT等）：
  • 排序逻辑是直观的数值大小顺序，计算和比较成本极低。
  • 单条键值占用空间小（4或8字节），相同大小的索引页能容纳更多索引条目，IO效率更高，缓存命中率也更好。
• 字符型主键（VARCHAR/CHAR等）：
  • 排序依赖字符集的字典序（比如utf8mb4是按Unicode编码值排序），字符串比较的计算成本远高于整数。
  • 单条键值占用空间大（比如一个utf8mb4字符占3-4字节，长字符串会占用更多），索引页能存的条目数大幅减少，IO次数会显著增加。

2. 插入时的页分裂风险（核心问题） #

这是你最关心的点，直接说结论：

• 自增整数主键：新插入的主键值永远大于现有最大主键，数据直接追加到聚簇索引的最后一个叶子页，只有当该页满了才会创建新页，几乎不会出现「插入到索引中间」的情况，页分裂概率极低，插入性能稳定。
• 字符型主键：
  • 如果是无序生成的字符主键（比如UUID、随机字符串、用户自定义的无规律编码），新键值的字典序大概率落在现有索引的中间区间，这时必须将目标索引页分裂为两个页，迁移部分数据到新页，同时更新上层索引的指针。频繁的页分裂会带来额外IO开销，还会产生大量索引碎片，长期会导致插入和查询性能双双下降。
  • 特殊情况：如果字符主键是严格递增的（比如按时间戳生成的固定格式字符串202405200001、202405200002，或者自增数字转成的字符串），插入时也是追加到索引末尾，和自增整数主键的表现完全一致，不会触发中间插入的页分裂。

3. 其他隐性性能影响 #

• 查询性能：整数索引的比较、排序操作更快，字符索引需要处理字符串编码的逐字符比较，尤其是长字符串，耗时明显更长；同时因为索引页条目少，查询时需要加载更多页，IO成本更高。
• 存储空间：字符主键的聚簇索引总占用空间更大——不仅叶子节点的主键值更长，非叶子节点也需要存储主键值，连带整个索引结构的存储空间都会膨胀，进一步增加IO压力。

内容的提问来源于stack exchange，提问作者jinwoo