在数据库的世界里慢SQL就像一个隐形的“刺客”，悄无声息地拖垮系统性Neng。它可Neng不会立刻导致系统崩溃，但会像慢性病一样，逐渐侵蚀用户体验和系统响应速度。那么我们该如何揪出这些“慢动作”SQL呢？

一、开启慢查询日志：捕捉“慢动作”

MySQL 提供了慢查询日志功Neng，Ke以记录执行时间超过指定阈值的 SQL 语句。这是Zui直接、Zui基础的识别方式。

临时开启

-- 开启慢查询日志
SET GLOBAL slow_query_log = 'ON';
-- 设置阈值：超过 1 秒算慢 SQL
SET GLOBAL long_query_time = 1;
-- 设置日志输出到表
SET GLOBAL log_output = 'TABLE';

永久生效

编辑 MySQL 配置文件 my.cnf或 my.ini

slow_query_log = 1
long_query_time = 1
log_output = TABLE
log_queries_not_using_indexes = 1    # 同时记录未使用索引的 SQL

💡 建议log_queries_not_using_indexes = 1 非常有用，即使执行hen快但没走索引的 SQL 也会被记录，Ke以提前发现潜在隐患。

当 log_output = TABLE 时慢 SQL 会写入 mysql.slow_log 表，Ke以直接用 SQL 查询。

SELECT 
    start_time,
    ROUND, 2) AS 执行秒数,
    ROUND, 2)  AS 锁等待秒数,
    rows_examined                      AS 扫描行数,
    rows_sent                          AS 返回行数,
    db                                 AS 数据库,
    sql_text                           AS SQL内容
FROM mysql.slow_log
ORDER BY query_time DESC
LIMIT 10;

按数据库筛选

SELECT * 
FROM mysql.slow_log
WHERE db = 'your_database'
ORDER BY query_time DESC
LIMIT 10;

二、performance_schema 分析：geng全面的性Neng视图

performance_schema 是 MySQL 内置的性Neng数据采集框架，Neng统计所有 SQL 的累计执行情况，找出高频且耗时的 SQL。

SELECT 
    DIGEST_TEXT                                           AS SQL摘要,
    COUNT_STAR                                            AS 执行次数,
    ROUND             AS 平均耗时秒,
    ROUND             AS Zui大耗时秒,
    ROUND             AS 总耗时秒,
    SUM_ROWS_EXAMINED                                     AS 总扫描行数
FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 10;

通过 sys schema geng简便地查询

sys schema 是对 performance_schema 的封装，SQL geng简洁易读：

-- 查询Zui耗时的 SQL
SELECT * 
FROM sys.statement_analysis
ORDER BY total_latency DESC
LIMIT 10;
-- 查询全表扫描Zui多的 SQL
SELECT * 
FROM sys.statements_with_full_table_scans
ORDER BY no_index_used_count DESC
LIMIT 10;

三、工具客户端分析：图形化助力 MySQL Workbench

连接数据库后在左侧导航找到 Performance 菜单，Ke以直观地kan到性Neng报告，包括慢查询、高负载SQL等。

PMM是专业的 MySQL 监控平台，适合生产环境，提供geng强大的可视化和告警功Neng。

四、执行计划分析：揭开慢SQL的“真面目”

找到慢 SQL 只是第一步，接下来需要通过执行计划分析慢的原因。

EXPLAIN SELECT * FROM orders WHERE user_id = 123 AND status = 'pending';
-- MySQL 5.6+ 支持geng详细的 EXPLAIN ANALYZE
EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 123 AND status = 'pending';

关键字段解读

字段	关注点	说明
type	Zui重要	ALL = 全表扫描，ref / eq_ref = 走索引
key	是否用索引	NULL 表示未使用任何索引
rows	扫描行数	数值越大性Neng越差
Extra	附加信息	Using filesort / Using temporary 需要重点优化
filtered	过滤比例	越低代表从扫描结果中筛选越多，效率越低

常见慢 SQL 原因

未建索引，或索引建了但没有命中

SQL 写法导致索引失效，例如对索引列使用函数、隐式类型转换

SELECT * 拉取了不必要的列，返回数据量过大

JOIN 关联字段未建索引，产生笛卡尔积

数据量大但没有分页，一次查询百万行数据

五、排查流程

步骤	操作	工具
第一步	开启慢查询日志	SET GLOBAL slow_query_log='ON'
第二步	收集慢 SQL 列表	查询 mysql.slow_log 或 sys.statement_analysis
第三步	找出Zui耗时的 SQL	按 query_time 降序排列，取 TOP 10
第四步	分析执行计划	EXPLAIN 命令 或 DBeaver / Workbench 图形化
第五步	定位慢的原因	kan type / key / rows / Extra 字段
第六步	优化处理	加索引、 SQL、分页、分库分表等

六、常用命令速查

-- 查kan慢查询配置
SHOW VARIABLES LIKE 'slow%';
-- 开启慢查询日志
SET GLOBAL slow_query_log = 'ON';
-- 设置慢查询阈值
SET GLOBAL long_query_time = 1;
-- 查询慢 SQL 列表
SELECT * FROM mysql.slow_log ORDER BY query_time DESC LIMIT 10;
-- 查 TOP 10 耗时 SQL
SELECT * FROM sys.statement_analysis LIMIT 10;
-- 查全表扫描的 SQL
SELECT * FROM sys.statements_with_full_table_scans LIMIT 10;
-- 分析执行计划
EXPLAIN SELECT ...;
-- 详细执行计划
EXPLAIN ANALYZE SELECT ...;
-- 清空慢日志表
TRUNCATE TABLE mysql.slow_log;

小结慢 SQL 排查的核心思路是「先发现、再定位、后优化」。建议在测试和生产环境dou长期开启慢查询日志，并定期检查 sys.statement_analysis，Zuo到防患于未然。

慢SQL的排查，不是一场速战速决的战斗，而是一场需要耐心和细致的“侦探游戏”。从日志的蛛丝马迹，到执行计划的层层剖析，每一步dou可Neng揭示性Neng瓶颈的真相。掌握这些方法，你就Neng在数据库的迷宫中，找到那条通往高效性Neng的“捷径”。

---