分布式主键会让二级索引变“胖”，因为InnoDB通过index extensions机制自动将主键追加到每个二级索引叶子节点中；主键越长（如CHAR(20)雪花ID达32字节），每条二级索引记录冗余越大，导致索引页数增多、扇出降低、树高增加、IO上升及缓存命中率下降。
为什么分布式主键会让二级索引变“胖”
InnoDB会自动把主键列追加到每个二级索引末尾，这是index extensions机制。当主键是单列BIGINT（8字节）时，二级索引每条记录多存8字节；但换成分布式主键（比如BIGINT + SMALLINT组合，或CHAR(20)雪花ID），主键长度可能飙升到16–32字节甚至更长——这些字节会原样复制进每个二级索引的每一条叶子节点记录里。
常见错误现象：表数据才200万行，SHOW TABLE STATUS却显示某个INDEX占用空间比聚簇索引还大；EXPLAIN显示用了索引，但rows估算异常高。
- 分布式主键越长，二级索引B+树的扇出（fan-out）越小 → 树高度更容易增加 → 查询需更多IO
- 每页（16KB）能存的键值数量下降 → 同等数据量下，索引页数增多 → 缓存命中率降低
- 如果主键含字符串（如
CHAR(20)），还会因字符集（如utf8mb4）进一步放大存储开销
如何压缩二级索引里的主键冗余
核心思路不是删主键，而是让主键本身更紧凑，并控制二级索引覆盖范围。InnoDB不支持“禁用index extensions”，但可以绕过它的膨胀效应：
- 用
BIGINT替代字符串型分布式ID（例如把雪花ID转为数值存储，而非VARCHAR） - 避免复合主键：即使业务需要多字段唯一性，也应另建
UNIQUE INDEX，主键保持单列BIGINT自增或BIGINT雪花数值 - 对高频查询的二级索引，显式包含查询所需列（即创建覆盖索引），减少回表 → 间接降低对主键字段的依赖强度
- 删除低选择性、低使用率的二级索引——它们在主键变长后，单位收益（QPS提升）/成本（空间+写入开销）比急剧恶化
示例：原表主键为(shard_id, snowflake_id)（共16字节），改为主键id BIGINT，再加UNIQUE KEY uk_shard_snow(shard_id, snowflake_id)。此时所有二级索引只追加8字节id，而非16字节组合。
联合索引设计要避开主键扩展陷阱
当你创建一个联合索引如INDEX idx_status_created(status, created_at)，InnoDB内部实际按(status, created_at, pk)组织。如果pk很长，这个“隐式三元组”的排序和比较开销就不可忽视。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 把高选择性列放在联合索引最左：例如
status只有3个值，就不该放最左；换成tenant_id（区分度高）更合理 - 避免在联合索引中重复包含主键字段：比如主键是
id，就别再写INDEX idx_xxx(x, id)——这等于主动放大冗余 - 用
SELECT ... FROM tbl WHERE status = ? ORDER BY created_at LIMIT N这类查询时，若created_at本身有索引，注意它已被扩展为(created_at, pk)，未必需要新建status + created_at索引
分页场景下主键膨胀的连锁反应
分布式主键常伴随分页优化需求（如游标分页WHERE id > ? ORDER BY id LIMIT 20）。但若id是32字节字符串，不仅索引体积大，B+树内排序、比较、页分裂都更耗CPU；更麻烦的是，当用WHERE status = ? AND id > ?做条件时，id > ?无法利用status索引的有序性，容易退化为索引扫描。
真实踩坑点：某系统将id CHAR(20)作为主键，又建了INDEX idx_type_created(type, created_at)，结果分页查询WHERE type = 'order' AND id > 'xxx'完全走不了该索引——因为id不在索引里，优化器判定范围条件失效。
解决关键不是加索引，而是承认：一旦主键不可压缩，就得接受二级索引“天然臃肿”。这时候更应聚焦于减少索引数量、提升单索引复用率，而不是试图靠堆索引来弥补设计缺陷。
