MySQL索引优化：联合索引最左前缀原则

理解联合索引与最左前缀原则

联合索引在MySQL底层基于B+Tree数据结构构建，其核心特征是将多个列的值按创建时的顺序拼接后排序存储。最左前缀原则是指查询条件必须从联合索引的最左侧列开始匹配，且不能跳过中间的列。例如，对表创建索引idx_a_b_c(a, b, c)，查询条件包含a或a,b或a,b,c时可命中索引；若仅查询b或b,c，则无法利用该索引。列顺序直接影响查询效率，因为B+Tree的排序优先级由左至右递减。将区分度高、常用于等值查询的列放在左侧，能更快缩小扫描范围；若将范围查询列置于左侧，则右侧列将无法参与索引排序与过滤。理解这一机制是合理设计索引与编写高效SQL的前提。

设计联合索引与编写高效查询

设计联合索引时，应遵循等值列优先、范围列靠后、高频查询列前置的原则。以用户订单表为例，若常按user_id（等值）和create_time（范围）查询，应创建idx_user_time(user_id, create_time)。在编写查询时，等值条件可任意顺序书写，优化器会自动调整；但范围条件（如大于、小于、BETWEEN）一旦出现在某列，该列之后的索引列将失效。对于ORDER BY和GROUP BY，若排序或分组字段与联合索引顺序一致且均为升序或降序，可直接利用索引完成排序，避免文件排序。例如SELECT * FROM orders WHERE user_id = 100 ORDER BY create_time DESC可完全命中索引。合理组合条件与索引顺序，能显著减少回表次数与临时表开销。

用EXPLAIN验证索引是否生效

使用EXPLAIN命令是验证联合索引是否生效的标准方法。执行EXPLAIN SELECT语句后，需重点关注key（实际使用的索引名）、key_len（使用的索引字节长度）、type（访问类型）及Extra字段。以idx_a_b_c(a, b, c)为例，若查询条件为WHERE a = 1 AND b > 10，key显示该索引，key_len仅包含a和b的长度，type通常为range，Extra可能显示Using index condition。若条件为WHERE b = 2 AND c = 3，key将为NULL，type退化为ALL全表扫描。通过对比不同SQL的key_len与type，可直观判断最左前缀的匹配程度。建议在生产环境压测前，务必通过EXPLAIN确认执行计划是否符合预期，避免索引设计偏离实际查询模式。

避开联合索引失效的常见写法

联合索引在实际应用中常因写法不当而失效。首先，跳过最左列会导致索引完全不被使用，需调整查询条件或补充单列索引。其次，对索引列使用函数或表达式会破坏B+Tree的有序性，例如WHERE YEAR(create_time) = 2023应改为范围查询WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31'。第三，隐式类型转换（如字符串字段传入整型参数）会触发全表扫描，需确保参数类型与表结构严格一致。第四，范围条件后的列无法继续利用索引，可通过拆分查询或调整索引列顺序优化。最后，LIKE前置通配符会导致索引失效，应改用全文索引或倒排结构。通过规范SQL写法与定期审查执行计划，可最大化联合索引的利用率。