确认MySQL慢查询日志是否开启应直接查系统变量：SHOW VARIABLES LIKE 'slow_query_log' 返回ON才真正启用；slow_query_log_file指定日志路径，long_query_time设阈值（单位秒，支持小数）。
怎么确认 MySQL 慢查询日志当前是否开启
直接查系统变量最可靠，别信配置文件里写了就等于生效：SHOW VARIABLES LIKE 'slow_query_log' 返回 ON 才算真开；slow_query_log_file 告诉你日志写哪，long_query_time 是阈值（单位秒，支持小数，比如 0.5 表示 500ms）。
常见错误现象：改了 my.cnf 但日志没生成——大概率是没重启 MySQL 或者被运行时 SET 覆盖了。MySQL 8.0+ 默认不启用慢日志，哪怕配置文件有也得显式设为 ON。
-
SET GLOBAL slow_query_log = ON可热启，但 MySQL 重启后失效（除非也写进配置文件） - 如果
slow_query_log_file指向的目录 MySQL 进程没写权限，日志会静默失败，mysqld日志里可能报Can't open log file -
long_query_time对于带锁等待的语句，只计算执行时间，不包含锁等待时间（MySQL 5.6.5+ 可用log_slow_slave_statements和log_queries_not_using_indexes辅助定位）
MySQL 5.7 和 8.0 的配置差异在哪
核心区别在默认行为和参数名：5.7 默认关，8.0 依然默认关，但 8.0 引入了 log_output 控制输出目标（FILE、TABLE 或两者），而 5.7 只能写文件；另外 8.0 把慢日志表从 mysql.slow_log 改成 performance_schema.slow_log（需手动启用 log_output = 'TABLE' 才写进去）。
使用场景：线上不敢动磁盘 I/O？可临时切 log_output = 'TABLE'，查完再导出分析；但注意 TABLE 方式性能开销略高，且 slow_log 表默认不索引，大数据量时 SELECT 很慢。
- 5.7 配置片段：
slow_query_log = 1、slow_query_log_file = /var/log/mysql/mysql-slow.log - 8.0 推荐组合：
slow_query_log = ON、log_output = 'FILE'、long_query_time = 1.0（避免设太低，否则日志爆炸） - 8.0 若用
TABLE，必须先SET GLOBAL log_output = 'TABLE'，再SET GLOBAL slow_query_log = ON，顺序反了无效
为什么开了慢日志却看不到 INSERT/UPDATE 的记录
因为默认只记录 SELECT —— 这点极容易被忽略。MySQL 认为“慢”是针对查询语句的，DML 默认不进慢日志，除非显式打开 log_slow_admin_statements（影响 ALTER、ANALYZE 等）或 log_slow_slave_statements（仅从库生效）。
真实场景：某个 INSERT ... SELECT 卡了 20 秒，但慢日志里找不到——它本质是查询 + 写入，但日志只看最外层类型。这时候得靠 log_queries_not_using_indexes 或 Performance Schema 的 events_statements_history_long 补位。
-
log_slow_admin_statements = ON才能让OPTIMIZE TABLE、CREATE INDEX这类管理语句进慢日志 -
log_queries_not_using_indexes = ON会把所有没走索引的查询都记下来（哪怕long_query_time设很高），适合建索引前摸底，但上线后建议关掉，日志量太大 - 真正想抓慢 DML，优先用
performance_schema.events_statements_summary_by_digest查平均延迟，比翻慢日志更准
分析慢日志时最容易漏掉的三个点
不是格式看不懂，而是关键上下文被日志本身过滤掉了：没有连接信息、没有事务边界、没有执行计划。比如同一条 SELECT 在不同事务里执行时间差 10 倍，慢日志里只记 SQL 文本和耗时，看不出是不是被锁住。
所以别只盯着 mysqldumpslow 或 pt-query-digest 的统计结果，得交叉验证：
- 检查对应时间点的
SHOW ENGINE INNODB STATUS输出，找TRANSACTIONS和LOCK WAIT段落 - 确认慢日志时间戳是否和系统时区一致（
log_timestamps = SYSTEM或UTC，不一致会导致时间对不上） -
mysqldumpslow -s t按总时间排序，但要注意合并后的 “N” 次调用，实际单次未必慢——得看原始日志里# Query_time后面的原始值
慢日志只是线索，不是证据链终点。尤其在读写混合、长事务多的库上，单看它容易误判瓶颈位置。
