先定位慢查询，再分析执行计划并检查索引使用。开启慢查询日志记录耗时SQL，用EXPLAIN分析type、key、rows及Extra信息，确认是否使用索引及是否存在全表扫描。根据查询条件创建复合索引遵循最左前缀原则，避免冗余索引。通过SHOW PROCESSLIST、Performance Schema和OPTIMIZER_TRACE监控运行状态与优化器行为，综合调优高频SQL以预防性能退化。
排查MySQL查询优化问题，关键在于定位慢查询、分析执行计划、检查索引使用情况，并结合系统状态做综合判断。以下是具体步骤和方法。
启用慢查询日志
慢查询日志是发现性能问题的第一步。开启后可以记录执行时间超过指定阈值的SQL语句。
在配置文件my.cnf中添加：
[mysqld]slow_query_log = ONslow_query_log_file = /var/log/mysql/slow.loglong_query_time = 1log_queries_not_using_indexes = ON
或动态启用：
SET GLOBAL slow_query_log = 'ON';SET GLOBAL long_query_time = 1;SET GLOBAL log_output = 'FILE';
重启服务或生效后，可通过tail -f /var/log/mysql/slow.log查看慢SQL。
使用EXPLAIN分析执行计划
对可疑SQL使用EXPLAIN或EXPLAIN FORMAT=JSON查看执行路径。
type：关注连接类型，从优到劣为const → eq_ref → ref → range → index → ALL（全表扫描）key：实际使用的索引，若为NULL需考虑添加索引rows：估算扫描行数，越大说明效率越低Extra：出现Using filesort或Using temporary通常表示需要优化
示例：
EXPLAIN SELECT * FROM orders WHERE user_id = 100 AND status = 'paid';
检查并优化索引
索引设计不合理是常见性能瓶颈。
确认查询条件中的字段是否有合适索引，特别是WHERE、JOIN、ORDER BY涉及的列避免过多或重复索引，影响写性能使用复合索引时注意最左前缀原则可借助SHOW INDEX FROM table_name;查看现有索引考虑使用覆盖索引减少回表次数
例如为上面查询创建复合索引：
CREATE INDEX idx_user_status ON orders(user_id, status);
监控运行状态与资源消耗
通过性能视图了解当前数据库负载。
查看正在执行的线程：SHOW PROCESSLIST;（或SHOW FULL PROCESSLIST;）启用Performance Schema获取更详细统计信息查询系统状态变量：SHOW STATUS LIKE 'Handler%'; 或 SHOW STATUS LIKE 'Key_%';使用INFORMATION_SCHEMA.OPTIMIZER_TRACE跟踪优化器决策过程（需开启）
开启优化器追踪：
SET optimizer_trace="enabled=on";SELECT * FROM information_schema.optimizer_trace;
基本上就这些。重点是先抓慢SQL，再用EXPLAIN看执行路径，结合索引和系统状态调优。坚持定期审查高频查询，能有效预防性能退化。
以上就是如何在mysql中排查查询优化问题的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/5337.html
微信扫一扫 
支付宝扫一扫 
