MySQL慢查询优化实战：从EXPLAIN解析到高效索引设计
EXPLAIN分析中key_len为NULL？可能是索引未命中
执行EXPLAIN后，若发现key_len显示为NULL或数值过小，通常意味着查询未能有效利用索引。许多开发者误以为索引创建有误，但更常见的原因是查询条件不符合索引的最左前缀匹配原则。例如，对于联合索引(a, b, c)，查询WHERE b = 1将无法使用该索引；即使查询条件为WHERE a = 1 AND c = 1，索引也仅能使用首列a，而c列无法参与过滤。
面对此类问题，建议按以下步骤排查：
- 重点关注
EXPLAIN的type字段：若值为ALL（全表扫描）或index（全索引扫描），表明存在严重的性能瓶颈，需优先优化。 - 对比
possible_keys与key字段：若possible_keys列出了可用索引但key为NULL，说明优化器经过成本估算后认为全表扫描效率更高。这可能由于查询结果集过大，或表的统计信息陈旧。执行ANALYZE TABLE更新统计信息，往往能有效改善执行计划。 - 避免在索引列上使用函数：例如
WHERE YEAR(create_time) = 2024会导致create_time索引失效。应改写为范围查询：WHERE create_time >= ‘2024-01-01’ AND create_time < ‘2025-01-01’，以充分利用索引。
联合索引字段顺序如何设计？依据查询模式而非字段权重
设计联合索引时，常见的误区是依据字段的“重要性”排序，如将主键或时间字段盲目前置。实际上，索引顺序应由高频查询模式决定，即WHERE、ORDER BY、GROUP BY子句中字段的组合与出现顺序。
遵循以下原则可设计出高效的联合索引：
- 等值查询字段优先左置：将使用
=、IN的等值条件字段置于索引最左侧，并按照其在高频查询中的组合顺序排列。例如，若常见查询为WHERE tenant_id = ? AND status = ?，则应创建(tenant_id, status)索引。 - 范围查询字段置于末尾：范围查询（如
>、BETWEEN、LIKE ‘abc%’）的字段应排在所有等值查询字段之后。一旦使用范围查询，其右侧的索引列将无法用于进一步的过滤（但若查询仅需覆盖索引数据，则仍可被利用）。 - 兼顾排序与分组需求：若查询常包含
WHERE条件与ORDER BY create_time DESC，可将create_time加入联合索引末尾。这样数据库可直接利用索引的有序性避免额外排序，显著提升查询速度。
哪些字段不适合建立索引？避免盲目添加
索引并非越多越好。在写密集型的表上过度建索引，或在区分度低的字段上建索引，会显著降低INSERT、UPDATE性能，并浪费存储资源。
以下类型的字段需谨慎考虑是否建索引：
- 区分度过低的字段：通过公式
SELECT COUNT(DISTINCT col) / COUNT(*)计算区分度。若结果低于0.01（例如性别字段仅含“男”、“女”两种值），为其单独建索引的收益通常微乎其微。 - 大文本字段：对
TEXT或超长VARCHAR字段直接建索引代价高昂。可考虑使用前缀索引，如INDEX (content(100))，但需确保前缀长度足以区分大多数行，否则可能因键值重复过多而影响效率。 - 频繁更新的字段：索引需要实时维护。若字段被高频修改，维护索引的开销可能超过其查询收益。在高并发写入场景下，有时可接受偶尔的慢查询，或通过应用层缓存、读写分离等方案替代索引。
索引已优化但慢查询依旧？排查锁竞争与长事务
当EXPLAIN显示索引使用正常，但查询性能仍不稳定或偶发卡顿时，问题可能已超出索引范畴，转向锁竞争或长事务阻塞。
此时应将排查重点转向数据库并发控制：
- 检查InnoDB状态：执行
SHOW ENGINE INNODB STATUS\G，重点关注TRANSACTIONS与LOCK WAIT部分，识别是否存在未提交的长事务或锁等待。 - 定位长事务：运行
SELECT * FROM information_schema.INNODB_TRX ORDER BY trx_started LIMIT 5，找出运行时间最久的事务，它们往往是锁争用的源头。 - 审查应用逻辑：确认代码中是否存在未提交的事务，或是否在事务内混用
SELECT … FOR UPDATE与复杂业务处理，导致行锁持有时间过长，阻塞其他并发操作。
数据库性能优化是一项系统工程。真正的难题往往源于查询语句、索引设计、事务边界与锁机制等多层因素的相互影响。一个WHERE条件的细微调整，可能同时改变执行计划、锁粒度乃至复制延迟。因此，切勿仅局限于EXPLAIN的输出，而应结合全局上下文进行综合诊断，方能从根本上解决慢查询问题。
