<p>mysqldumpslow报错或漏行，因MySQL 8.0默认开启log_slow_extra，老版本工具不识别新增字段如# Rows_examined，导致整条记录跳过；应升级至8.0+版本或改用pt-query-digest。</p>
mysqldumpslow 报错或漏行，大概率是日志含 log_slow_extra 字段
MySQL 8.0 默认开启 log_slow_extra（除非显式关闭），日志里会多出 # Rows_examined: 12345、# Lock_time: 0.000123 这类键值对行。老版本 mysqldumpslow（如来自 MySQL 5.7 工具包）不认识这些行，直接跳过整条记录，导致统计数变少、Top SQL 漏掉。
验证方式：运行 head -n 20 /var/log/mysql/mysql-slow.log | grep -E '^(# Time|# Rows_examined|# Lock_time)'，如果看到带 # Rows_examined 的行，说明日志已启用 extra 格式。
- 临时解决：执行
SET GLOBAL log_slow_extra = OFF，再等新日志生成（但会丢失关键诊断字段） - 推荐做法：改用
pt-query-digest，它原生支持 8.0 日志格式，能正确解析 microsecond 级时间、识别 prepared statement 占位符 - 若坚持用
mysqldumpslow，必须确认其版本 ≥ 8.0：mysqldumpslow --version；路径通常是/usr/bin/mysqldumpslow，不是旧版/usr/local/mysql/bin/mysqldumpslow
日志不写文件，查 /var/lib/mysql/hostname-slow.log 为空
MySQL 8.0 默认把慢查询日志输出到系统表 mysql.slow_log，而非文件——前提是 log_output 值为 TABLE 或 FILE,TABLE，且未显式设为 FILE。很多运维仍习惯翻文件，结果发现空。
先确认当前配置：SELECT @@slow_query_log, @@log_output, @@slow_query_log_file;
- 若
@@log_output返回TABLE或FILE,TABLE，但@@slow_query_log_file是空值或默认路径，说明没启用文件输出 - 要恢复写文件，必须三步一起做：
SET GLOBAL slow_query_log = ON、SET GLOBAL log_output = 'FILE'、SET GLOBAL slow_query_log_file = '/var/log/mysql/mysql-slow.log' - 注意权限：升级后
/var/log/mysql/目录所属用户可能从mysql变成mysqld，需手动chown mysqld:adm /var/log/mysql并确保可写
用 performance_schema.events_statements_summary_by_digest 替代日志？别信
有人以为开了 performance_schema 就不用开慢日志了，这是误解。该表只保留最近聚合摘要，受 performance_schema_digests_size 限制（默认仅 2000 条），且不存原始 SQL 文本，只有 digest hash，也没 Query_time 的原始微秒级值。
它适合查“当前最耗时的 SQL 模板”，但无法回溯历史、无法比对升级前后同一语句的延迟变化。
- 真正需要归档分析、跨周期对比时，必须依赖慢查询日志（文件或表）
-
mysql.slow_log表字段完整：sql_text、query_time、lock_time、rows_examined，可直接SELECT过滤分析 - 但要注意：
mysql.slow_log默认不启用，需先SET GLOBAL log_output = 'TABLE'，且表本身有大小限制（max_slowlog_size），不适合长期高频率写入
升级后 long_query_time 设为 0.5，5.7 和 8.0 行为不一致
MySQL 8.0 内部以微秒存储 long_query_time，支持小数秒（如 0.5），而 5.7 实际只截断到秒级，设 0.5 会被当成 0，导致日志爆炸。
升级后若沿用旧配置，可能突然出现大量日志，甚至填满磁盘。
- 检查实际生效值：
SELECT @@long_query_time;，不要只看配置文件 - 会话级设置会覆盖全局值，排查时需同时查
SELECT @@global.long_query_time, @@session.long_query_time; - 生产环境建议设为
1.0起步，观察一周后再下调；避免设0或0.1这类极低值
日志格式变了不是单纯“换工具”就能糊弄过去的事——Rows_examined 和 Lock_time 这些字段一旦缺失，你根本没法判断一条慢查到底是 SQL 写得差，还是被锁卡住。很多人关掉 log_slow_extra 图省事，结果优化半天，才发现瓶颈压根不在执行逻辑上。
