从一次慢查询说起：给 MySQL 加索引前，先看懂执行计划

前几天，一张只有几万行的订单表，查一个用户最近 30 天的订单居然要两秒多。第一反应是“加个索引吧”，但加索引之前，我先跑了一次 EXPLAIN——这一步，决定了后面是真优化，还是把问题藏得更深。先看 type 和 rows。type 是 ALL，基本就是全表扫描；rows 很大，说明它扫描后还要再过滤。很多慢查询不是数据量大，而是条件根本没有走到索引。接着看 key：如果 key 是空，说明没有用上任何索引；如果 key 有值，再看 Extra 里有没有 Using filesort、Using temporary，这两个出现，排序和临时表往往就是耗时的大头。那次的问题其实很典型：查询条件是 user_id 和 created_at，表上却只有一个主键索引。加索引时，顺序也很关键。把等值条件放前面、范围条件放后面，例如先 user_id、再 created_at，多数情况下比反过来更有效。最左前缀原则说白了就是：索引从左到右用，中间断了，后面就用不上。加完索引后，别只看一次查询变快了，要再跑一次 EXPLAIN，确认 type 从 ALL 变成了 ref 或 range，rows 明显下降，Extra 里不再出现 filesort。索引不是越多越好，每多一个索引，写入就要多维护一份，读快了、写慢了也可能是新的问题。我的习惯是：先 EXPLAIN 定位，再加索引，最后再 EXPLAIN 验证——三步走完，才算一次完整的慢查询处理。