真正要优化的SQL应优先用mysqldumpslow -s c -t 10看执行次数最多者，再交叉比对-s at（总耗时）而非仅依赖-s t（平均耗时），因高频低效查询（如无LIMIT分页、未缓存聚合）对系统压力远超单次长耗时SQL；默认不加-a才能正确归并参数不同但语义相同的SQL，避免统计失真。
怎么用 mysqldumpslow 看出真正要优化的 SQL
直接看 mysqldumpslow -s t -t 10 /var/log/mysql/slow.log 得到的“平均耗时最高”的 10 条，不等于最该优先优化的。真正影响系统负载的，往往是那些执行次数多、单次不慢但总耗时爆炸的 SQL。
关键判断逻辑是：先看 -s c（执行次数），再交叉比对 -s at（总耗时）和 -s t（平均耗时）。比如一条 SQL 执行了 5000 次，平均 0.2s，总耗时 1000s；另一条只执行 3 次，平均 8s，总耗时才 24s——前者对 CPU 和 IO 的持续压力远大于后者。
-
-s c排序能暴露高频低效查询，比如没加 LIMIT 的分页、重复调用的无缓存聚合 -
-s at更贴近实际资源占用，Time=0.25s (250.0s)这种括号里数字才是总耗时 - 别只信
-s t，平均值容易被个别长尾拖高，掩盖批量小查询的真实危害
为什么加 -a 参数后结果反而更难定位问题
-a 会禁用 SQL 指纹抽象，把所有带不同参数的语句当独立 SQL 处理，导致统计失真。例如 SELECT * FROM users WHERE id = 123 和 SELECT * FROM users WHERE id = 456 在不加 -a 时会被合并为 SELECT * FROM users WHERE id = N，计数为 2；加了 -a 就变成两条各计 1，无法识别这是同一类未走索引的查询模式。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 默认行为（不加
-a）才是合理起点：它自动归并语义相同、仅参数不同的 SQL - 只有当你明确想查某条具体语句（如含特定字符串或注释）时，才配合
-g使用-a - 误用
-a会导致-t 10返回一堆看似不同、实则同源的慢 SQL，浪费排查时间
如何快速过滤出 JOIN 或子查询相关的慢 SQL
用 -g 参数做关键词过滤是最直接的方式，但要注意大小写不敏感、支持简单正则，且匹配的是日志中记录的原始 SQL 文本（不是指纹）。
- 查 JOIN：
mysqldumpslow -g "join" -s at -t 5 /var/log/mysql/slow.log - 查子查询：
mysqldumpslow -g "select.*select" -s t -t 5 /var/log/mysql/slow.log（注意空格和点号需转义） - 查没走索引的全表扫描：
mysqldumpslow -g "Rows_examined.*100000" -s c /var/log/mysql/slow.log（结合日志里Rows_examined字段数值） - 避免过度依赖
-g：它只是预筛选，最终仍需用EXPLAIN验证执行计划
生产环境跑 mysqldumpslow 时最容易卡住的两个点
不是命令写错，而是路径和权限问题。工具本身不连数据库，但它读的是 MySQL 进程有权限写的日志文件，而你执行命令的用户往往没读取权限。
- 日志路径必须用绝对路径，且确保当前用户可读：
sudo -u mysql mysqldumpslow ...或sudo chmod o+r /var/log/mysql/slow.log - MySQL 8.0+ 默认日志可能写在
/var/lib/mysql/hostname-slow.log，而不是配置里写的路径——用SHOW VARIABLES LIKE 'slow_query_log_file';确认真实位置 - 如果日志文件极大（>1GB），
mysqldumpslow会明显变慢，此时应先用tail -n 100000截取最新部分再分析，而非硬扛全量
真实瓶颈常藏在「执行次数 × 平均耗时」这个乘积里，而不是单次耗时数字本身。别被 -s t 带偏节奏，也别让 -a 把同一类问题拆成几十条假象。
