mysqldumpslow 是用于归类、聚合和排序相似 SQL 模板的统计工具，通过抽象参数（如数字→N）实现语义级聚合；加 -a 才显示原始 SQL，-s c/-s l 比 -s t 更利于定位高频或锁等待瓶颈，需注意路径、权限及日志格式兼容性。
直接结论：mysqldumpslow 不是用来“读日志”，而是用来“归类+聚合+排序”相似 SQL 模板的统计工具；不加 -a 时它自动抽象参数（如 WHERE id = 123 → WHERE id = N），这才是它真正高效的地方。
为什么 mysqldumpslow 输出的 SQL 看起来“不像真实语句”？
这是设计使然，不是 bug。默认行为会把数字、字符串、IP、时间戳等替换成占位符（N、S、C），目的是将语义相同但参数不同的查询聚合成一条统计项。
- 例如：
SELECT * FROM users WHERE id = 1001和SELECT * FROM users WHERE id = 1002会被合并为SELECT * FROM users WHERE id = N，Count: 2 - 若想看原始 SQL（比如要复制出来跑
EXPLAIN），必须加-a参数：mysqldumpslow -a /var/log/mysql/mysql-slow.log - 不加
-a时，Rows=100.0 (1000)中的100.0是平均返回行数，括号里是总行数 —— 这个聚合值对评估扫描代价非常关键
按什么维度排序最能快速定位瓶颈？
别一上来就用 -s t（总执行时间）。多数情况下，真正拖垮数据库的是高频低耗但累积耗时高的查询，或锁等待长的语句。
-
-s c -t 10：先看执行次数最多的前 10 条 —— 高频 SQL 即使单次快，也可能因重复执行压垮连接池或缓存 -
-s l -t 5：锁定时间（Lock=）长的语句容易阻塞其他事务，尤其在写密集场景下比Time更危险 -
-s t适合查“单次执行超长”的离群点，但要注意：如果某条 SQL 执行了 30 秒但只发生 1 次，优先级通常低于执行 1 秒却发生 500 次的语句 - 组合使用更有效：
mysqldumpslow -s c -t 5 /var/log/mysql/mysql-slow.log | grep -E "(UPDATE|DELETE|INSERT)"快速筛出高频写操作
权限、路径、日志格式这三处最容易卡住
报错 Permission denied 或 Can't read slow log file 不一定是配置问题，大概率是运行环境没对齐。
- 路径必须写全：
mysqldumpslow默认读/var/lib/mysql/hostname-slow.log，但你实际日志可能在/var/log/mysql/mysql-slow.log—— 务必确认slow_query_log_file的值：SELECT @@slow_query_log_file; - 权限问题：MySQL 写日志用的是
mysql用户，而你 shell 登录可能是普通用户。直接sudo mysqldumpslow /path/to/slow.log最省事，别试图改日志文件属主 - 日志格式兼容性：MySQL 8.0.23+ 默认启用
log_output = TABLE（写入slow_log表），此时mysqldumpslow无法读取 —— 必须先切回文件模式：SET GLOBAL log_output = 'FILE';，再确认slow_query_log已开启
过滤和调试时别依赖 -g，用管道更可控
-g 只做简单行匹配，且正则语法受限（不支持 +、? 等），容易漏掉关键 SQL。
- 想看所有含子查询的慢 SQL：
mysqldumpslow -a /var/log/mysql/mysql-slow.log | grep -A 2 -B 1 "SELECT.*SELECT"（-A/-B带上下文，方便看完整结构） - 想排除健康 SQL（如心跳检测）：
mysqldumpslow -a /var/log/mysql/mysql-slow.log | grep -v "/* ping */" - 调试时加
-v能看到解析过程，但输出极冗长；真要查解析失败原因，不如直接head -20 /var/log/mysql/mysql-slow.log看原始日志格式是否被截断或乱码
真正难的不是跑通命令，而是理解每行输出中 Count、Time、Lock、Rows 四个数字之间的关系——它们共同指向 SQL 的真实负载特征。比如 Count: 15 Time=0.80s (12s) Lock=0.75s (11.25s)，说明锁等待占了执行时间的 94%，这时优化方向根本不在 SQL 本身，而在事务边界或隔离级别。
