慢查询日志有效性的核心在于验证“谁查、查什么、怎么筛、怎么判”，漏掉rows_examined与query_time比值将使90%优化失效；需检查日志路径权限、long_query_time作用域、避免log_queries_not_using_indexes误开，并结合原始日志字段精准定位索引缺失、锁竞争或排序问题。
直接结论：慢查询日志本身不解决问题，关键在“谁查、查什么、怎么筛、怎么判”——漏掉 Rows_examined 和 Query_time 的比值，90% 的优化努力都白费。
如何确认慢查询日志真正在记录有效数据
很多团队开了日志却没效果，不是配置错了，而是根本没验证日志是否真在捕获“有优化价值”的语句。
-
SHOW VARIABLES LIKE 'slow_query_log'返回ON≠ 日志在写入；必须同时检查slow_query_log_file路径是否存在、MySQL 进程是否有写权限（常见于 SELinux 或 Docker 容器挂载目录权限不足） -
long_query_time是按 query 执行完成时间判定的，但SET SESSION long_query_time = 0.5对当前连接生效，SET GLOBAL long_query_time = 0.5才影响新连接 —— 已存在的连接仍沿用旧阈值，这点极易被忽略 - 如果启用了
log_queries_not_using_indexes = ON，大量短查询（如SELECT COUNT(*) FROM config）也会进日志，导致噪音爆炸；生产环境建议只在排查索引缺失时临时开启，日常关闭
为什么直接看 mysqldumpslow -s t -t 10 /var/log/mysql/mysql-slow.log 往往失效
这个命令默认把相似 SQL 归并（比如带不同 ID 的 WHERE 条件会被抽象成 N），但归并逻辑依赖空格和换行，而 ORM 自动生成的 SQL 经常格式混乱，导致本该归为一类的慢查询被拆成几十条，排序后根本看不出规律。
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 加
-a参数能避免数字/字符串抽象，但代价是失去聚合能力；更稳妥的做法是先用grep "Query_time:" mysql-slow.log | sort -k2 -nr | head -20提取原始耗时 top20，再人工比对 -
mysqldumpslow不解析Rows_examined，而这个字段才是判断索引是否生效的黄金指标 ——Query_time: 0.8但Rows_examined: 2800000，说明它根本没走对索引，比Query_time: 3.2却只扫了 12 行更急需优化 - 日志里带
# User@Host:行能定位具体应用模块，但默认输出被mysqldumpslow丢弃；需配合awk '/^# User@Host:/ {user=$0; next} /^# Query_time:/ {print user, $0}' mysql-slow.log提取调用方
从日志字段快速判断优化方向
每条慢日志里的注释块不是摆设，Rows_examined、Lock_time、Rows_sent 三个数连起来看，基本能锁定问题类型：
- 若
Rows_examined≈ 表总行数（比如 500 万行表扫了 490 万行），且key字段为空 → 缺索引或索引未命中，优先EXPLAIN对应 SQL，检查type是否为ALL - 若
Rows_examined很小（几百行），但Query_time高、Lock_time占比超 30% → 锁竞争问题，不是 SQL 本身慢，而是被其他事务阻塞，需查SHOW ENGINE INNODB STATUS中的TRANSACTIONS部分 - 若
Rows_examined远大于Rows_sent（比如扫 10 万行只返回 10 行），且Extra含Using filesort或Using temporary→ 排序/分组未走索引，考虑调整 ORDER BY 字段顺序或加覆盖索引
日志分析后最容易被跳过的动作
找到慢 SQL 只是开始，真正卡住落地的是验证和闭环。
- 不要直接在生产库跑
EXPLAIN—— 某些 SQL 在慢日志里是带参数的（如WHERE id = ?），而EXPLAIN需要真实值；用SELECT @@last_insert_id或日志中的SET timestamp=...时间戳反查 binlog 获取实际参数 - 加完索引后，必须确认
Rows_examined显著下降；有时加了索引但优化器没选，要用EXPLAIN FORMAT=JSON看used_range_access和chosen_range_access字段 - 日志轮转后旧文件别直接
rm——mysqladmin flush-logs slow会生成新文件，但旧文件可能还在被mysqldumpslow读取中，建议用logrotate配置 +postrotate脚本触发分析任务
