联合索引字段过多会导致B+树变高、I/O增加、最左前缀失效风险上升、写入性能下降、优化器成本估算失真；应精简字段，避免大字段，拆分高频查询索引。
联合索引字段太多会导致B+树节点膨胀
联合索引本质是B+树，每个索引项要存储所有字段的值。字段越多、越长（比如VARCHAR(500)或JSON），单个索引页能容纳的键值就越少。结果就是树变高、磁盘I/O次数增加——原本3层能查到的数据，可能变成4层甚至5层，每次查询多一次随机读。
实操建议：
- 用
SHOW INDEX FROM table_name看Cardinality和Index_length，如果索引长度远超数据行平均长度，说明字段冗余或过大 - 避免把
TEXT、BLOB、大VARCHAR加进联合索引；高频查询中只覆盖id、status、created_at这类轻量字段 - MySQL 8.0+ 可用
INFORMATION_SCHEMA.INNODB_SYS_INDEXES查索引页数，辅助判断是否过深
最左前缀失效风险随字段数上升而陡增
联合索引(a, b, c, d, e)只有在查询条件严格匹配前缀时才有效：比如WHERE a = ? AND b = ?能用，但WHERE a = ? AND c = ?就只能用上a，c之后的字段全部失效。字段越多，“断点”越容易出现在中间，优化器更可能放弃该索引，退回到全表扫描或临时表。
常见错误现象：
-
EXPLAIN显示key用了索引，但rows接近全表行数 -
Extra列出现Using where; Using index condition——说明ICP起了作用，但没真正“走完”索引路径 - 同样查询在测试环境快、线上慢，往往是因为线上数据分布导致前缀选择性骤降
写入性能被多个字段同步拖垮
每条INSERT/UPDATE/DELETE都要更新整个联合索引项。5字段联合索引比2字段索引多写3个字段值，还涉及更多内存拷贝、排序、页分裂。尤其当字段含可变长度类型时，InnoDB需频繁做页重组。
影响不止于单次DML：
- 高并发写入下，
innodb_row_lock_waits指标明显上升 - buffer pool中索引页占比过高，挤占热数据缓存空间，间接拖慢其他查询
- 主从复制延迟加剧，因为从库回放时同样要重建完整索引项
优化器成本估算失真，容易选错索引
MySQL优化器对多字段联合索引的成本估算依赖统计信息（如各前缀组合的基数）。字段超过3个后，统计直方图精度下降，cardinality值常严重偏离真实分布。这时优化器可能误判(a,b,c,d,e)比(a,b)更优，实际执行却扫了10倍行数。
验证方式：
- 强制用
USE INDEX(idx_a_b_c_d_e)对比IGNORE INDEX的EXPLAIN FORMAT=JSON输出，看cost_info里query_cost是否虚低 - 对高频查询单独建精简索引，比如把
(user_id, status, type, created_at, updated_at)拆成(user_id, status)+(user_id, created_at) - MySQL 8.0+ 可开启
optimizer_trace，检查range_analysis阶段是否因字段过多跳过某些索引评估
