MySQL慢查询排查完整流程步骤详解

在日常数据库运维中，慢查询就像一颗定时冲击波——平时不显山不露水，一旦流量上来，瞬间就能把系统拖垮。今天分享一套已经过无数次实战检验的排查方案，从发现问题到定位根因，再到优化落地，全链路覆盖，可以直接拿来用。

第一步：确认慢查询是否存在

1.1 开启慢查询日志

先别急着分析，得确认慢查询到底有没有被记录。默认情况下，MySQL的慢查询日志可能是关闭的，需要手动开启。

-- 查看当前状态SHOW VARIABLES LIKE 'slow_query%';SHOW VARIABLES LIKE 'long_query_time';-- 临时开启（重启失效）SET GLOBAL slow_query_log = ON;SET GLOBAL long_query_time = 1;  -- 超过1秒记录SET GLOBAL log_queries_not_using_indexes = ON;

这里有个小建议：生产环境里long_query_time设成1秒通常够用，如果业务对延迟极其敏感，可以调到0.5秒甚至更低。不过要注意，记录太细可能会产生大量日志，影响磁盘IO。

1.2 查看慢查询数量与内容

开启之后，怎么知道有没有慢查询？两个命令搞定：

# 统计慢查询次数SHOW GLOBAL STATUS LIKE '%Slow_queries%';# 查看最近慢查询日志文件路径SHOW VARIABLES LIKE 'slow_query_log_file';

数值如果一直往上飙，说明系统确实存在性能瓶颈，该进入下一步了。

第二步：分析慢查询语句

2.1 使用 EXPLAIN 分析执行计划

拿到慢查询SQL后，第一件事就是用EXPLAIN看执行计划。这就像去医院做CT，能直接看到MySQL是怎么执行这条语句的。

EXPLAIN SELECT * FROM orders WHERE status = 1 ORDER BY created_at DESC LIMIT 100;

重点关注这几个字段，一旦出现危险信号，基本就是问题所在：

2.2 使用 SHOW PROFILE 查看耗时分布

EXPLAIN能告诉你“怎么执行”，但想知道“时间花在哪里”，还得靠SHOW PROFILE。这个工具可以精确到每个步骤的耗时。

-- 开启 profilingSET profiling = 1;-- 执行你的慢查询SELECT * FROM orders WHERE ...;-- 查看所有查询的耗时SHOW PROFILES;-- 查看具体某个 Query_ID 的详细耗时SHOW PROFILE FOR QUERY 1;

重点看这几个步骤的耗时占比：Sending data、Sorting result、Creating tmp table。如果某个步骤时间异常高，比如Sending data占了90%，那说明数据量大或索引没用好；Sorting result高则意味着排序操作消耗大，可能需要优化排序字段的索引。

第三步：常见原因与对应解决方案

3.1 没走索引 → 加索引

这是最经典的问题。先检查表上已有的索引：

-- 检查是否有可用索引SHOW INDEX FROM orders;

如果发现查询条件字段没有索引，或者索引不合适，那就加一个复合索引。注意字段顺序：等值条件字段放前面，范围条件字段放后面。

-- 添加复合索引（注意字段顺序：等值条件在前，范围条件在后）ALTER TABLE orders ADD INDEX idx_status_created (status, created_at);

3.2 索引失效 → 改写 SQL

有时候明明有索引，但查询还是慢，那很可能是索引失效了。常见的“坑”有这几个：

• 对索引列使用函数：WHERE DATE(created_at) = '2024-01-01' — 改成范围查询WHERE created_at >= '2024-01-01' AND created_at < '2024-01-02'
• 隐式类型转换：WHERE user_id = '123'（user_id 是 int） — 类型要匹配，去掉引号
• 前导模糊匹配：WHERE name LIKE '%张三' — 这种只能用全文索引或改业务逻辑

3.3 数据量过大 → 分页优化 / 归档

深分页是另一种常见痛点。比如翻到第10000页，MySQL需要先扫描大量行，再丢弃掉前面的，非常低效。

深分页优化示例：

-- 原始写法（越往后越慢）SELECT * FROM orders ORDER BY id LIMIT 100000, 20;-- 优化写法（子查询用覆盖索引）SELECT * FROM orders WHERE id > (SELECT id FROM orders ORDER BY id LIMIT 100000, 1)ORDER BY id LIMIT 20;

如果数据量实在太大，还可以考虑数据归档：把历史数据迁移到归档表或分区表，这样主表的行数降下来，查询自然就快了。

3.4 锁等待 → 排查锁冲突

有时候慢不是因为SQL本身慢，而是被其他事务堵住了。这种情况在高并发写操作时尤其常见。

-- 查看当前正在等待锁的事务SELECT * FROM information_schema.INNODB_TRXG-- 查看锁等待关系SELECT * FROM sys.schema_table_lock_waits;-- 强制结束阻塞事务（慎用）KILL [trx_mysql_thread_id];

注意：KILL操作要谨慎，确保不会造成数据不一致。更推荐从业务层面优化事务逻辑，减少锁持有时间。

3.5 SQL 写得烂 → 重写

有些慢查询纯粹是SQL写法太“奔放”。典型坏写法包括：

• SELECT * → 只取需要的列，减少数据传输
• 子查询嵌套过深 → 改用 JOIN 或临时表
• OR 条件 → 拆成 UNION ALL，能利用索引
• 循环查询 → 批量查询 + IN，避免N+1问题

第四步：系统层面排查

4.1 查看数据库配置是否合理

有时候SQL本身没问题，但数据库配置没跟上，也会导致慢。重点关注这几个参数：

-- 关键参数检查SHOW VARIABLES LIKE 'innodb_buffer_pool_size';    -- 建议设为内存的60%-70%SHOW VARIABLES LIKE 'tmp_table_size';              -- 临时表大小限制SHOW VARIABLES LIKE 'max_connections';             -- 连接数是否过高

其中innodb_buffer_pool_size是最关键的，如果设置太小，MySQL会频繁进行磁盘IO，性能直线下降。一般建议设为物理内存的60%~70%，如果服务器是专用数据库，可以更高。

4.2 查看服务器资源

数据库的根因也可能是服务器资源本身不够。用系统命令看看：

# CPU、内存、IO 情况topiostat -x 1free -h

如果 CPU 高但 IO 低 → SQL 计算量大或索引不合理，需要优化SQL或增加索引。

如果 IO 高但 CPU 低 → 磁盘瓶颈，考虑换 SSD 或增加 buffer pool 大小。

第五步：建立长效机制

5.1 定期巡检脚本

优化不是一次性的，需要持续监控。可以定期跑这两个查询，防患于未然：

-- 查询当前运行时间最长的SQLSELECT * FROM information_schema.PROCESSLIST WHERE COMMAND != 'Sleep'ORDER BY TIME DESC LIMIT 10;-- 查询全表扫描次数最多的表SELECT * FROM sys.schema_unused_indexes;

5.2 监控告警

有了日志和巡检，还得有告警机制。建议这样做：

• 设置 long_query_time = 1，持续采集慢查询日志
• 使用 Percona Toolkit 的 pt-query-digest 分析日志规律，找出高频慢SQL
• 接入 Prometheus + Grafana 监控 QPS、慢查询数量趋势，一旦异常立刻告警

一句话总结排查思路

先确认慢在哪（日志+profile），再看为什么慢（explain+索引），最后对症下药（加索引/改SQL/扩资源）。 这套流程走下来，90%的慢查询问题都能解决。剩下的10%，可能就是业务架构层面的问题了，比如分库分表、缓存、读写分离等，那又是另一个话题了。