一个索引让性能提升170倍Explain教你看懂真相干了八年的数据库工程自认为对SQL调优已经驾轻就熟。直到上个月一个线上慢查询把我按在地上摩擦了整整两天——一个简单的订单查询跑了5.2秒业务方天天催用户投诉不断。最后排查下来问题出在一个被我忽视的索引上。今天就把这次踩坑经历掰开揉碎讲清楚希望能帮正在做SQL优化的你少走弯路。一、问题复现那个让人头疼的慢查询先说说背景。我们有个电商订单系统订单表 orders 大概有800万条数据每天还在以5万条的速度增长。业务方反馈说查询某个时间范围内某个用户的订单列表页面加载要等五六秒用户体验极差。原始查询语句大概是这样的sqlSELECTo.order_id,o.user_id,o.order_amount,o.order_status,o.created_at,oi.product_name,oi.product_priceFROM orders oLEFT JOIN order_items oi ON o.order_id oi.order_idWHERE o.user_id 123456AND o.created_at 2025-06-01AND o.created_at 2025-07-01ORDER BY o.created_at DESCLIMIT 20;看起来很简单对吧一个用户ID加时间范围再加个关联查询按理说不应该慢到哪去。但现实就是这么打脸——执行计划显示这个查询走了全表扫描扫描了将近400万行数据才返回20条结果。二、问题诊断Explain 不会骗人遇到慢查询第一件事就是看执行计划。用 Explain 分析一下sqlEXPLAIN SELECTo.order_id,o.user_id,o.order_amount,o.order_status,o.created_atFROM orders oWHERE o.user_id 123456AND o.created_at 2025-06-01AND o.created_at 2025-07-01ORDER BY o.created_at DESCLIMIT 20;执行计划结果idselect_typetabletypepossible_keyskeyrowsExtra1SIMPLEoALLidx_user_id,idx_created_atNULL3987654Using where; Using filesort看到 typeALL 和 rows3987654 的时候我整个人都不好了。明明有索引为什么没走再看 possible_keys 一栏MySQL 知道有 idx_user_id 和 idx_created_at 两个单列索引但 keyNULL 表示它一个都没用。这个问题其实很典型当查询条件涉及多个列而每个列只有单独索引时MySQL 的优化器可能认为走索引还不如全表扫描快。尤其是当 user_id123456 这个条件的选择性不够高时——这个用户有20万条订单记录占全表的2.5%MySQL 觉得扫索引再回表还不如直接扫全表。更糟糕的是Extra 列还出现了 Using filesort这意味着排序也没走索引需要在内存或磁盘上做额外的排序操作。双重打击之下5秒的查询时间也就不奇怪了。三、解决方案联合索引的正确打开方式问题清楚了解决方案也就明确了创建一个联合索引让查询条件和排序都能利用索引。sqlALTER TABLE orders ADD INDEX idx_user_created (user_id, created_at DESC);这里有几个关键点需要注意1、字段顺序很重要把等值查询条件 user_id 放在前面范围查询条件 created_at 放在后面。这是联合索引设计的基本原则——等值条件在前范围条件在后。2、排序字段直接定义DESCMySQL 8.0 支持降序索引如果查询中 ORDER BY ... DESC 是常态直接在索引定义时指定 DESC可以避免文件排序。3、覆盖索引的考量如果查询只涉及 user_id、created_at、order_amount、order_status 这几个字段可以做一个覆盖索引把查询字段都包含进去避免回表sqlALTER TABLE orders ADD INDEX idx_user_created_cover(user_id, created_at DESC, order_amount, order_status);创建完索引后再看执行计划idselect_typetabletypepossible_keyskeyrowsExtra1SIMPLEorefidx_user_createdidx_user_created198Using where; Using indextyperef扫描行数从400万降到198Extra 里 Using index 表示索引覆盖不用回表。查询时间从5.2秒降到了0.03秒快了170多倍。四、关联查询的索引优化解决了主查询的问题还得看看 LEFT JOIN 那边的情况。order_items 表有1200万条数据关联条件是 o.order_id oi.order_id如果 oi.order_id 上没有索引关联查询一样会慢。检查一下sqlSHOW INDEX FROM order_items;果然order_items 表的主键是自增的 item_idorder_id 上只有一个普通索引。不过这个索引已经能用了关联查询时 MySQL 会先驱动 orders 表用联合索引快速定位然后通过 order_id 索引去 order_items 表查找。如果 order_items 表经常按 order_id 做关联查询可以考虑把索引改成联合索引把经常查询的字段也包含进去sqlALTER TABLE order_items ADD INDEX idx_order_product(order_id, product_name, product_price);这样关联查询时不仅能用上索引还能直接从索引中获取 product_name 和 product_price完全避免回表。五、优化后的完整查询与效果对比优化后的完整查询sqlSELECTo.order_id,o.user_id,o.order_amount,o.order_status,o.created_at,oi.product_name,oi.product_priceFROM orders oLEFT JOIN order_items oi ON o.order_id oi.order_idWHERE o.user_id 123456AND o.created_at 2025-06-01AND o.created_at 2025-07-01ORDER BY o.created_at DESCLIMIT 20;优化效果对比指标优化前优化后扫描行数3987654198查询类型ALL全表扫描ref索引引用排序方式filesort文件排序索引排序查询耗时5.2秒0.03秒回表次数大量回表索引覆盖六、这次踩坑教会我的几个道理1、单列索引不是万能药。很多开发同学习惯在每个查询字段上单独建索引觉得这样就能覆盖所有查询场景。但实际工作中多条件查询才是常态联合索引往往比单列索引高效得多。2、Explain 是调优的第一工具。遇到慢查询不要凭感觉猜直接用 Explain 看执行计划。重点关注 type、rows、Extra 三列它们能告诉你查询到底慢在哪。3、索引设计要考虑排序。很多人只关注 WHERE 条件忽略了 ORDER BY。如果排序字段能包含在索引中MySQL 可以直接按索引顺序读取数据省掉 filesort 的开销。4、不要过度索引。联合索引虽然好但不是越多越好。每个索引都会增加写入开销占用存储空间。根据实际查询模式设计最核心的几个索引就够了。5、覆盖索引是性能利器。如果查询字段都能从索引中获取MySQL 就不需要回表这能减少大量随机 I/O。尤其是在 OLTP 场景下覆盖索引的效果非常明显。七、几个实用的索引优化建议在日常工作中我总结了几条索引优化的实战经验1、分析慢查询日志。MySQL 的慢查询日志是宝藏定期分析能发现很多隐藏的性能问题。可以用 pt-主题-digest 工具来分析慢查询日志找出最耗时的查询。2、关注索引选择性。索引列的值越分散选择性越高索引效果越好。像性别这种只有两个值的列建索引意义不大。而用户ID、订单号这类高选择性的列索引效果就很明显。3、避免在索引列上做函数操作。比如 WHERE DATE(created_at) 2025-06-01这会让索引失效。应该改成 WHERE created_at 2025-06-01 AND created_at 2025-06-02。4、合理使用索引提示。有时候 MySQL 的优化器会选错索引可以用 FORCE INDEX 或 USE INDEX 来强制指定索引。不过这只是临时方案根本解决还是要优化索引设计。5、定期维护索引。随着数据的增删改索引会产生碎片影响查询性能。定期用 OPTIMIZE TABLE 重建索引可以保持索引的高效性。八、写在最后那次线上事故之后我花了一周时间把系统里所有核心查询都过了一遍用 Explain 逐个分析优化了十几个慢查询。最大的感悟是索引优化不是一锤子买卖而是需要持续关注和迭代的过程。业务在变数据量在涨查询模式也在变。今天好用的索引三个月后可能就成了瓶颈。定期做性能巡检用 Explain 和慢查询日志做体检才能让数据库始终保持最佳状态。希望这次踩坑经历能给你一些启发。如果你在 SQL 优化上也有什么心得或者踩过什么坑欢迎一起交流探讨。注意本文所介绍的软件及功能均基于公开信息整理仅供用户参考。在使用任何软件时请务必遵守相关法律法规及软件使用协议。同时本文不涉及任何商业推广或引流行为仅为用户提供一个了解和使用该工具的渠道。你在生活中时遇到了哪些问题你是如何解决的欢迎在评论区分享你的经验和心得希望这篇文章能够满足您的需求如果您有任何修改意见或需要进一步的帮助请随时告诉我感谢各位支持可以关注我的个人主页找到你所需要的宝贝。博文入口山峰哥-CSDN博客复制到【浏览器】打开即可,宝贝入口常用软件宝贝精品文件作者郑重声明本文内容为本人原创文章纯净无利益纠葛如有不妥之处请及时联系修改或删除。诚邀各位读者秉持理性态度交流共筑和谐讨论氛围