答案是定位耗时操作并分析执行路径。通过开启慢查询日志筛选慢SQL，使用EXPLAIN查看执行计划，重点检查type、key、rows和Extra字段，排查缺失索引、索引失效、扫描过多、回表严重等问题，结合performance_schema统计进一步诊断，最终优化SQL和索引设计。
分析 MySQL 慢查询的根本原因，关键在于定位耗时操作并理解其执行路径。核心方法是开启慢查询日志，结合 EXPLAIN 分析执行计划，再从索引、表结构、SQL 写法等角度排查。
1. 开启并查看慢查询日志
确保 MySQL 已记录执行时间较长的 SQL，这是分析的前提。
— 查看慢查询日志是否开启
SHOW VARIABLES LIKE ‘slow_query_log’;
— 查看慢查询阈值（单位：秒）
SHOW VARIABLES LIKE ‘long_query_time’;
— 临时开启慢查询日志（需有权限）
SET GLOBAL slow_query_log = ‘ON’;
SET GLOBAL long_query_time = 1;
日志文件中会记录超过阈值的 SQL 及其执行时间、锁等待时间等信息，可用于筛选重点优化对象。
2. 使用 EXPLAIN 分析执行计划
对慢查询语句前加上 EXPLAIN，查看 MySQL 如何执行这条 SQL。
EXPLAIN SELECT * FROM users WHERE name = ‘John’;
重点关注以下字段：
type：访问类型，ALL 表示全表扫描，性能最差；index 或 ref 更好key：实际使用的索引，为 NULL 说明未走索引rows：扫描行数，越大越慢Extra：额外信息，出现 Using filesort 或 Using temporary 通常表示性能问题
3. 常见慢查询原因及对策
根据 EXPLAIN 结果和业务逻辑，排查以下常见问题：
缺少有效索引：WHERE、JOIN、ORDER BY 字段未建索引。解决方法是创建合适的单列或复合索引索引失效：使用函数、类型转换、% 前缀模糊匹配（LIKE ‘%abc’）会导致索引无法使用扫描行数过多：即使有索引，若过滤性差（如查性别字段），MySQL 可能选择全表扫描回表严重：覆盖索引可减少回表，SELECT 尽量避免用 *数据量过大：考虑分库分表或归档历史数据锁竞争：长时间运行的事务阻塞其他操作，可通过 SHOW ENGINE INNODB STATUS 查看锁情况
4. 利用 performance_schema 进一步诊断
MySQL 自带的 performance_schema 提供更细粒度的运行时统计。
SELECT * FROM performance_schema.events_statements_history WHERE sql_text LIKE ‘%users%’;
可查看 SQL 的执行次数、平均耗时、锁时间、IO 次数等，帮助识别高频慢语句。
基本上就这些。开启日志、看执行计划、查索引、优化 SQL，是标准流程。关键是养成习惯，定期巡检慢查询日志。
以上就是如何在mysql中分析慢查询原因的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/4978.html
微信扫一扫 
支付宝扫一扫 
