定位慢查询需先开启慢查询日志，设置slow_query_log并配置long_query_time阈值，通过mysqldumpslow或pt-query-digest分析耗时SQL；再用EXPLAIN查看执行计划，重点观察type、key、rows和Extra字段，确认是否使用索引及是否存在性能隐患；结合SHOW FULL PROCESSLIST实时监控运行中的查询，识别长时间运行的连接；最后利用performance_schema收集SQL执行统计，按总耗时或平均耗时排序定位热点语句，实现系统性排查与优化。
MySQL查询耗时分析的核心在于定位慢查询、理解执行路径并优化SQL或索引。直接从数据库运行状态和执行计划入手，能快速发现问题所在。
启用慢查询日志（Slow Query Log）
这是分析耗时查询的第一步。通过记录执行时间超过指定阈值的SQL语句，可以锁定需要优化的目标。
- 在配置文件 my.cnf 中开启：
slow_query_log = ON slow_query_log_file = /var/log/mysql/slow.log long_query_time = 1 log_queries_not_using_indexes = ON
- long_query_time 设置为1表示超过1秒的查询会被记录，可根据业务调整。
- 重启服务或动态生效：
SET GLOBAL slow_query_log = 'ON'; - 使用 mysqldumpslow 或 pt-query-digest 分析日志内容，找出高频或最耗时的SQL。
使用 EXPLAIN 分析执行计划
对可疑SQL使用 EXPLAIN 可查看MySQL如何执行该查询，重点关注是否走索引、扫描行数、连接方式等。
- 在SQL前加上 EXPLAIN，例如：
EXPLAIN SELECT * FROM users WHERE email = 'test@example.com';
- 关注字段：type（连接类型，ALL最差）、key（实际使用的索引）、rows（扫描行数）、Extra（如 Using filesort、Using temporary 表示性能隐患）。
- type 推荐为 range、ref 或 const；避免 ALL 和 index 全表或全索引扫描。
查看实时连接与状态（SHOW PROCESSLIST）
当数据库响应变慢时，可通过该命令查看当前正在执行的查询。
- 执行：
SHOW FULL PROCESSLIST; - 观察 State 列，如 "Sending data"、"Copying to tmp table" 等可能表示操作复杂或资源消耗大。
- 结合 Time 列判断哪些查询执行时间过长，可考虑 kill 掉异常连接。
利用 performance_schema 进阶分析
MySQL 5.6+ 提供 performance_schema，可深度监控SQL执行细节。
- 启用并查询 statements 配置：
UPDATE performance_schema.setup_instruments SET ENABLED = 'YES', TIMED = 'YES' WHERE NAME LIKE '%statement/%'; UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE '%statements%';
- 查询最耗时的SQL：
SELECT DIGEST_TEXT, COUNT_STAR, SUM_TIMER_WAIT / 1000000000 AS total_sec, AVG_TIMER_WAIT / 1000000000 AS avg_sec FROM performance_schema.events_statements_summary_by_digest ORDER BY SUM_TIMER_WAIT DESC LIMIT 10;
可精准定位平均或总耗时高的语句，适合生产环境长期监控。
基本上就这些。开启慢日志抓问题SQL，用EXPLAIN看执行路径，结合processlist和performance_schema做实时或历史分析，就能系统性排查MySQL查询慢的原因。
