MySQL 慢查询优化：从索引到执行计划

SEO关键词： MySQL慢查询优化、MySQL索引优化、SQL性能优化、EXPLAIN执行计划、数据库性能调优、MySQL查询慢

文章摘要： MySQL 查询速度变慢，可能与索引缺失、SQL 写法不合理、数据量增长或索引失效有关。本文结合实际 SQL 示例，介绍慢查询定位、EXPLAIN 执行计划分析、索引优化和分页查询优化等常见方法，帮助开发者提升数据库查询性能。

一、为什么数据库查询会越来越慢？

在项目开发初期，即使没有为数据库设计复杂的索引，查询也可能很快。随着业务运行时间增长，数据量从几千条增加到几十万甚至上百万条，原本正常的 SQL 就可能出现明显的性能问题。

常见原因主要有以下几种：

1. 缺少索引： 数据库需要扫描大量数据才能找到目标记录。
2. 索引失效： 在索引列上使用不合理的函数或类型转换，导致索引无法有效利用。
3. SQL 设计不合理： 查询了不需要的字段，或者关联了过多的数据表。
4. 深分页查询： 使用较大的 OFFSET，数据库需要扫描并跳过大量记录。
5. 数据库资源不足： CPU、内存、磁盘 I/O 或数据库连接数达到瓶颈。

排查慢查询时，不建议直接给所有字段添加索引。更合理的方式是先定位问题，再根据执行计划制定优化方案。

二、使用 EXPLAIN 分析 SQL

MySQL 提供了 EXPLAIN 命令，可以帮助开发者了解 SQL 的执行计划。

例如，有一张用户订单表：

CREATE TABLE orders (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    user_id BIGINT NOT NULL,
    status TINYINT NOT NULL,
    amount DECIMAL(10, 2) NOT NULL,
    create_time DATETIME NOT NULL
);

现在需要查询某个用户的订单：

SELECT id, user_id, status, amount, create_time
FROM orders
WHERE user_id = 10001
ORDER BY create_time DESC;

可以在查询前加上 EXPLAIN：

EXPLAIN
SELECT id, user_id, status, amount, create_time
FROM orders
WHERE user_id = 10001
ORDER BY create_time DESC;

重点关注以下字段：

如果 type 为 ALL，通常意味着全表扫描。但这并不一定代表 SQL 存在问题：当表很小，或者查询需要读取大部分数据时，全表扫描也可能是合理的。

同样，rows 是优化器的估算值，并不是实际读取行数。对于复杂查询，还需要结合实际执行耗时、数据分布和其他执行信息进行判断。

三、使用联合索引优化查询

假设订单表经常执行下面的查询：

SELECT id, amount, create_time
FROM orders
WHERE user_id = 10001
ORDER BY create_time DESC;

如果 user_id 没有索引，数据库可能需要扫描大量订单，再筛选出目标用户的数据。

可以创建联合索引：

CREATE INDEX idx_user_create_time
ON orders (user_id, create_time);

这个索引首先按照 user_id 组织索引记录，再按照 create_time 排列同一用户的记录，有机会同时帮助数据库完成条件过滤和排序。

对于联合索引，需要注意最左前缀原则。

例如，索引为：

(user_id, status, create_time)

通常可以用于以下条件：

WHERE user_id = 10001;

WHERE user_id = 10001
  AND status = 1;

WHERE user_id = 10001
  AND status = 1
  AND create_time >= '2026-01-01';

但如果只查询 status，由于没有使用最左侧的 user_id，该索引通常无法像预期一样进行高效的常规索引查找。

需要注意，索引并不是越多越好。每增加一个索引，都会带来额外的存储开销，并增加插入、更新和删除操作的维护成本。创建索引前，应结合真实查询场景进行评估。

四、避免索引失效的常见写法

1. 尽量不要在索引列上使用函数

假设 create_time 已经建立索引，下面的写法可能无法充分利用该索引：

SELECT *
FROM orders
WHERE DATE(create_time) = '2026-10-27';

可以改为时间范围查询：

SELECT *
FROM orders
WHERE create_time >= '2026-10-27 00:00:00'
  AND create_time <  '2026-10-28 00:00:00';

这样通常更有利于使用 create_time 索引进行范围查找。

2. 避免不必要的 SELECT *

如果业务只需要订单编号和金额，就不必查询整行数据。

不推荐：

SELECT *
FROM orders
WHERE user_id = 10001;

可以改为：

SELECT id, amount
FROM orders
WHERE user_id = 10001;

减少读取和传输的数据量，有助于降低数据库与应用之间的通信成本。对于特定查询，还可能通过覆盖索引进一步减少回表操作。

五、优化 LIMIT 深分页查询

后台管理系统经常使用分页查询：

SELECT id, amount, create_time
FROM orders
ORDER BY id DESC
LIMIT 100000, 20;

当偏移量很大时，数据库可能需要扫描并跳过大量记录，最终只返回 20 条数据。

如果业务允许，可以改为基于上一页最后一条记录的游标分页：

SELECT id, amount, create_time
FROM orders
WHERE id < 100020
ORDER BY id DESC
LIMIT 20;

这里假设上一页最后一条记录的 id 为 100020，并且 id 是主键。数据库可以利用主键索引定位起始位置，避免大偏移量造成的额外开销。

游标分页尤其适合订单列表、消息记录等连续翻页场景。但它与传统页码分页不同，不能直接跳转到任意页；如果排序字段不唯一，还应增加唯一字段作为辅助排序条件，避免分页过程中出现重复或遗漏。

六、建立一套慢查询排查流程

当线上数据库出现查询变慢的问题时，可以按照以下顺序排查：

1. 定位 SQL： 查看慢查询日志，确认具体 SQL、执行时间和调用频率。
2. 分析执行计划： 使用 EXPLAIN 检查访问方式、索引使用情况和估算扫描行数。
3. 检查索引： 判断是否缺少合适的索引，或者已有索引是否能够匹配查询条件。
4. 优化 SQL： 减少不必要的字段、数据扫描和大偏移量分页。
5. 验证优化效果： 在具有代表性的数据量和负载下，对比优化前后的执行耗时及资源使用情况。
6. 检查系统瓶颈： 如果 SQL 本身没有明显问题，还需要关注锁等待、连接池、磁盘 I/O、内存和 CPU 使用率。

特别需要注意，不能仅凭一次执行结果就判断优化成功。缓存状态、并发请求和数据分布都可能影响测试结果。生产环境中进行索引变更前，也应评估锁表风险、磁盘空间和业务影响。

七、总结

MySQL 性能优化并不是简单地增加索引，而是一个从现象定位到执行计划分析，再到 SQL 调整和效果验证的过程。

对于日常开发而言，优先掌握慢查询日志、EXPLAIN、联合索引、索引失效排查和游标分页，已经能够解决不少常见的数据库性能问题。

优化数据库时，先找到真正的瓶颈，再采取针对性的措施。 只有结合实际执行计划和测试结果，才能判断优化是否有效，而不是单纯依靠经验修改 SQL。