MySQL如何通过配置提升慢查询分析效率
排查数据库性能问题，慢查询日志（Slow Query Log）往往是第一站。但默认配置下的日志，信息量有限，常常让人有“隔靴搔痒”之感——只知道SQL慢了，却不知道它“为什么”慢。今天，我们就来聊聊如何通过一系列配置，让慢查询日志从一份简单的“黑名单”，升级为一份详尽的“诊断报告”。
怎么让 slow query log 记录更完整、可读性更强
默认的 slow_query_log 只记执行时间超阈值的 SQL，不带锁等待、解析耗时、执行计划摘要等关键信息，查问题时经常要反复连上去 EXPLAIN，效率低。
必须打开几个配套配置，否则日志只是“慢了”，不是“为什么慢”：
long_query_time = 1（按需调低，但别设0，MySQL 5.7+ 对0有特殊行为）log_queries_not_using_indexes = ON（注意：只对明确走全表扫描的语句生效，加了索引但没用上不算）log_slow_admin_statements = ON（否则ALTER TABLE、ANALYZE TABLE这类管理语句不会进慢日志）log_slow_sla ve_statements = ON（主从架构下，从库执行慢的 SQL 也得记录）
关键在于，需要开启log_slow_verbosity='full'（8.0.26+版本）、log_slow_admin_statements、log_slow_sla ve_statements及log_queries_not_using_indexes，并配合pt-query-digest --explain或应用层主动EXPLAIN，才能使slow query log包含锁等待、执行计划等完整诊断信息。
为什么 slow log 默认不记录参数化后的 SQL 和执行计划
这其实是个设计权衡问题。MySQL 的慢日志是在服务端语句执行完后写入的，它记录的是原始文本（query 字段），而不是预处理后的绑定值。至于执行计划，比如EXPLAIN FORMAT=JSON的输出，默认也不包含——原因很简单：执行计划的生成和日志写入是两个独立阶段，如果每次都自动记录详细的执行计划，其开销不可控，可能反而影响性能。
想补全这部分信息，只能靠外部工具或应用层配合：
- 用
pt-query-digest解析日志时加--explain参数，它会尝试重放 SQL 并抓取执行计划（注意权限和数据一致性风险） - 在应用层统一打点：比如用
MySQLi::get_warnings()或PDO::getAttribute(PDO::ATTR_SERVER_VERSION)判断版本后，对慢 SQL 主动补发EXPLAIN FORMAT=TREE - 避免直接依赖日志里的
Rows_examined做判断——它在JOIN场景下是各表扫描行数乘积，常被高估
log_output = FILE vs TABLE 对分析效率的实际影响
选 FILE（默认）还是 TABLE（写入 mysql.slow_log）？这看似是个偏好问题，实则关乎运维效率。
FILE 看起来原始，但配合 pt-query-digest 或 mysqldumpslow 这类命令行工具，聚合分析起来非常快。而 TABLE 虽然能用 SQL 直接查询，听起来方便，实际却容易踩三个坑：
mysql.slow_log是CSV引擎，不支持索引，10 万行以上SELECT就卡- 日志写入是同步的，写
TABLE比写文件多一次 SQL 解析 + 存储引擎调用，极端高并发下可能拖慢慢查询本身 TRUNCATE TABLE mysql.slow_log不清空磁盘文件，只是删 CSV 数据，残留内容仍占空间
所以，除非有非常特定的、需要SQL联查的需求，否则FILE通常是更稳妥高效的选择。
常见错误：slow log 明明开了却看不到预期 SQL
配置都设对了，为什么还是抓不到“元凶”？最常被忽略的，是MySQL对“慢”的定义和实际用户体验的“卡顿”路径不一致。比如：
- SQL 执行时间
< long_query_time，但锁等待（innodb_row_lock_time）很长——它不会进 slow log，得看information_schema.INNODB_TRX - 存储过程里调用的 SQL，日志只记
CALL proc_name，不记内部语句（除非开启log_output = FILE+log_slow_verbosity = 'full'，仅 8.0.26+ 支持） - 客户端设置了
SET SESSION long_query_time = 0，但全局long_query_time是 2，这时以 session 值为准——而很多监控工具只读全局变量，误判配置未生效
因此，要真正定位“用户感知到的卡顿”，不能只盯着slow log这一亩三分地。更全面的做法，是把 performance_schema.events_statements_history_long 和 events_waits_history_long 一起捞出来，对齐时间戳进行综合分析，才能拼出性能瓶颈的完整拼图。
