SQL优化实战：从Explain执行计划到千万级数据查询调优全解析

慢查询拖垮整个系统？一个Explain就能定位90%的性能瓶颈。在实际开发中，我们每天都在和数据库打交道，但真正懂SQL调优的人却少之又少。很多人遇到查询慢的第一反应就是加索引，结果越加越慢，系统反而更卡。今天这篇文章，我会用真实案例带你走一遍从发现问题、分析问题到解决问题的完整流程，看完之后你会发现，SQL优化并没有想象中那么玄乎。

一、SQL优化为什么这么重要

在互联网公司里，数据库几乎是所有业务的核心引擎。订单系统、用户系统、日志系统，全部依赖数据库来读写数据。一旦某条SQL写得不好，轻则接口响应变慢，重则直接把数据库拖死，造成全线服务不可用。

我之前经历过一次线上事故：一条统计报表的SQL在凌晨跑批时把主库CPU干到了100%，导致订单创建接口全部超时，持续了将近20分钟。后来排查发现，就是一个简单的多表关联查询，少写了一个过滤条件，导致全表扫描了一张800万行的表。

所以说，SQL优化不是锦上添花的技能，而是每个后端开发必须掌握的基本功。

二、Explain：SQL优化的第一把钥匙

想要优化SQL，首先得学会"看病"。而MySQL提供的Explain命令，就是最好的诊断工具。很多人写了几年SQL，从来没用过Explain，这是非常可惜的。

我们先来看一个简单的案例。假设有一张用户订单表orders，结构如下：

字段名 类型 说明

id bigint 主键

user_id bigint 用户ID

status tinyint 订单状态

create_time datetime 创建时间

amount decimal 订单金额

现在有一条查询SQL：

sql

SELECT * FROM orders WHERE user_id = 1001 AND status = 1;

我们用Explain看一下它的执行计划：

+----+-------------+--------+------+---------------+------+---------+-------+------+-------------+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |

+----+-------------+--------+------+---------------+------+---------+-------+------+-------------+

| 1 | SIMPLE | orders | ALL | NULL | NULL | NULL | NULL | 5000 | Using where |

+----+-------------+--------+------+---------------+------+---------+-------+------+-------------+

☆ 从这张结果中我们能读出几个关键信息：

1、type列显示为ALL，说明这条SQL进行了全表扫描，这是性能最差的情况。

2、possible_keys和key都为NULL，说明没有用到任何索引。

3、rows显示为5000，意味着MySQL需要逐行扫描5000条记录才能找到结果。

这个结果一目了然：这条SQL没有走索引，需要优化。

三、索引策略：不是建得越多越好

很多开发人员有一个误区，觉得索引建得越多查询就越快。其实恰恰相反，索引是一把双刃剑。

☆ 索引的优点很明显：

1、大幅提升查询速度，特别是范围查询和排序操作。

2、能够有效减少需要扫描的数据行数。

☆ 但索引也有代价：

1、每张表上的每个索引都会占用磁盘空间，索引越多占用越大。

2、写入操作（INSERT、UPDATE、DELETE）会变慢，因为每次写数据都要同步更新索引树。

3、过多的索引会让MySQL优化器在选择执行计划时产生困惑，反而可能选错索引。

回到刚才的例子，我们给user_id和status分别加上索引：

sql

ALTER TABLE orders ADD INDEX idx_user_id (user_id);

ALTER TABLE orders ADD INDEX idx_status (status);

再次执行Explain：

+----+-------------+--------+------+---------------------+-------------+---------+-------+------+--------------------------+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |

+----+-------------+--------+------+---------------------+-------------+---------+-------+------+--------------------------+

| 1 | SIMPLE | orders | ref | idx_user_id,idx_status | idx_user_id | 8 | const | 120 | Using where; Using index |

+----+-------------+--------+------+---------------------+-------------+---------+-------+------+--------------------------+

☆ 这次的变化非常明显：

1、type从ALL变成了ref，说明走了非唯一索引扫描。

2、key列显示用到了idx_user_id这个索引。

3、rows从5000降到了120，扫描行数减少了97%以上。

不过这里还有一个问题：status这个字段的区分度很低，大部分订单的status都是1（已完成），所以单独建status索引效果并不好。更好的做法是建一个联合索引：

sql

ALTER TABLE orders DROP INDEX idx_user_id;

ALTER TABLE orders DROP INDEX idx_status;

ALTER TABLE orders ADD INDEX idx_user_status (user_id, status);

再看Explain结果：

+----+-------------+--------+------+---------------------+----------------+---------+-------+------+--------------------------+

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |

+----+-------------+--------+------+---------------------+----------------+---------+-------+------+--------------------------+

| 1 | SIMPLE | orders | ref | idx_user_status | idx_user_status | 16 | const | 45 | Using where; Using index |

+----+-------------+--------+------+---------------------+----------------+---------+-------+------+--------------------------+

☆ 联合索引的效果更好：

1、rows进一步降到了45行，说明MySQL精准定位到了需要的数据。

2、Extra中出现了Using index，说明这是一个覆盖索引，连回表操作都省了。

四、查询优化案例：一个订单统计SQL的调优之路

下面分享一个我在实际项目中遇到的真实案例。

业务需求是：查询最近30天内，每个用户的订单总金额，并且只统计金额大于100元的订单。

最初开发写的SQL是这样的：

sql

SELECT user_id, SUM(amount) as total_amount

FROM orders

WHERE create_time >= DATE_SUB(NOW(), INTERVAL 30 DAY)

AND amount > 100

GROUP BY user_id

ORDER BY total_amount DESC

LIMIT 10;

这条SQL在数据量只有几万行的时候跑得还行，但当订单表增长到500万行之后，查询时间直接飙到了8秒多。

💡注意：本文所介绍的软件及功能均基于公开信息整理，仅供用户参考。在使用任何软件时，请务必遵守相关法律法规及软件使用协议。同时，本文不涉及任何商业推广或引流行为，仅为用户提供一个了解和使用该工具的渠道。

你在生活中时遇到了哪些问题？你是如何解决的？欢迎在评论区分享你的经验和心得！

希望这篇文章能够满足您的需求，如果您有任何修改意见或需要进一步的帮助，请随时告诉我！

感谢各位支持，可以关注我的个人主页，找到你所需要的宝贝。

博文入口：https://blog.csdn.net/Start_mswin 复制到【浏览器】打开即可,宝贝入口：https://pan.quark.cn/s/b42958e1c3c0 宝贝：https://pan.quark.cn/s/1eb92d021d17

作者郑重声明，本文内容为本人原创文章，纯净无利益纠葛，如有不妥之处，请及时联系修改或删除。诚邀各位读者秉持理性态度交流，共筑和谐讨论氛围～

📋 复制整篇文章