如何定位耗时sql_mysql性能分析技巧

定位耗时sql需先启用慢查询日志并配置long_query_time，再用mysqldumpslow归类分析，接着通过EXPLaiN诊断执行计划，最后结合PROCEsslIST和锁等待监控长事务与阻塞。

定位耗时 SQL 是 MySQL 性能分析中最直接也最关键的一步。核心思路是：先抓“慢”的，再看“为什么慢”。重点不在查所有 SQL，而在快速聚焦真正拖慢系统的那几条。

开启并配置慢查询日志

这是最基础、最可靠的入口。MySQL 默认不记录慢查询，需手动启用：

• 在 my.cnf（或 my.ini）中添加：
  slow_query_log = ON
  slow_query_log_file = /var/log/mysql/mysql-slow.log
  long_query_time = 1.0（单位秒，建议初设为 1，高并发场景可调至 0.5）
• 动态开启（无需重启）：
  SET GLOBAL slow_query_log = ON;
  SET GLOBAL long_query_time = 1;
• 注意：long_query_time 对已建立连接不生效，新连接才生效；若用代理（如 proxySQL），可能需额外配置其慢日志。

用 mysqldumpslow 快速归类分析

原始慢日志杂乱冗长，直接 grep 效率低。mysqldumpslow 是官方配套工具，能按模板聚合统计：

• 查看执行次数最多、平均耗时最长的前 10 条：
  mysqldumpslow -s c -t 10 /var/log/mysql/mysql-slow.log
• 查看总耗时最长的前 10 条（关注“拖累大盘”的 SQL）：
  mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log
• 加 -g “WHERE.*status” 可过滤含特定关键词的模板，缩小范围。

结合 EXPLAIN 精准诊断执行计划

找到可疑 SQL 后，别急着改逻辑，先看 MySQL 实际怎么执行它：

• 对 select 语句加 EXPLAIN format=TREE（8.0+）或 EXPLAIN（通用），重点关注：
  – type：是否用了 index/ range/ ref？全表扫描（ALL）要警惕
  – key 和 possible_keys：是否命中索引？为何没选最优索引？
  – rows：预估扫描行数是否远超实际返回行数？
  – Extra：出现 using filesort、Using temporary、Using join buffer 意味着有优化空间
• 对 UPDATE/delete 也适用：
  EXPLAIN UPDATE … 或先转成等价 SELECT 再 explain。

实时抓取正在运行的长事务和阻塞

有些 SQL 并不慢，但因锁等待或事务过长，导致其他请求排队——这时慢日志可能不记录，需主动监控：

• 查当前运行超 1 秒的连接：
  SELECT * FROM information_schema.PROCESSLIST WHERE TIME > 1 AND COMMAND != ‘Sleep’;
• 查锁等待关系（8.0+）：
  SELECT * FROM performance_schema.data_lock_waits;
  或经典方式：
  SHOW ENGINE INNODB STATUSG，关注 TRANSACTIONS 部分的 lock wait。
• 配合 sys.schema_long_running_queries 视图（需 sys schema 已安装）可一键查长时间未结束的查询。