高频低效小SQL比慢SQL更危险，因不触发慢查询日志却持续消耗资源；应关注单位时间总扫描行数和执行频次，结合EXPLAIN分析rows、Extra、type等字段识别隐性开销，并通过精简字段、消除隐式转换、优化索引等手段治理。
高频低效小SQL比单次几秒的慢SQL更危险——它们不触发慢查询日志，却在后台持续消耗CPU、内存和连接数，最终拖垮整个数据库。
为什么long_query_time = 1会漏掉高频小SQL
MySQL默认只记录执行时间超过long_query_time的SQL，而很多问题SQL执行只要20~50ms，远低于阈值。但它们每秒被调用数百次，累计资源开销巨大。这类SQL在慢日志里完全隐身，只会在SHOW GLOBAL STATUS LIKE 'Slow_queries'里显示为“0”，却让Threads_running持续高位、Created_tmp_disk_tables缓慢上涨。
必须换思路：不盯“单次耗时”，而盯“单位时间内的总扫描行数”和“执行频次”。
- 开启
log_queries_not_using_indexes = ON（仅临时启用），抓出所有没走索引的SQL，哪怕它只跑10ms - 配合
min_examined_row_limit = 1000，过滤掉真正小表查询，聚焦扫描行数超千行的“伪快SQL” - 用
mysqldumpslow -s c -t 20按出现次数排序，找出TOP 20高频SQL，再人工筛选其中Rows_examined明显偏高的 - 查
sys.statement_analysis视图（MySQL 8.0+），直接看total_latency和rows_examined_total双高项
EXPLAIN里哪几列暴露了“小SQL大代价”
对高频SQL跑EXPLAIN，重点不是type是否为ALL，而是看它在“轻量级”外表象下隐藏的资源浪费：
-
rows列数值虽不大（比如800），但结合表实际大小（该字段基数仅几百），说明优化器误判了选择性，可能因统计信息过期，需ANALYZE TABLE -
key非NULL但Extra含Using where; Using index condition：说明用了索引但没覆盖，每次都要回表，高频下IO放大效应明显 -
Extra出现Using filesort且rows在百量级：排序本身不重，但每秒执行200次=每秒200次内存排序，累加就是瓶颈 -
type = ref但possible_keys列出多个索引，而key只选了其中一个：说明索引设计冗余或冲突，可能引发锁竞争
优化高频小SQL的三个实操切口
这类SQL通常已在线上稳定运行很久，改动需极谨慎。优先从副作用最小的点切入：
- 把
SELECT *改成明确字段列表，尤其是去掉大字段（TEXT、BLOB），减少网络传输和缓冲区压力；若能命中覆盖索引，直接消除回表 - 检查
WHERE条件中是否存在隐式类型转换，例如user_id = '123'（字段是BIGINT）——高频下这种转换会彻底废掉索引 - 对
ORDER BY字段补单列索引，或扩展为复合索引（如原索引是(status)，高频查WHERE status = ? ORDER BY created_at，就建(status, created_at)） - 避免在高频SQL里用
IN (subquery)或OR连接非索引列，改用UNION ALL或拆成应用层多次查询（前提是业务可接受）
验证时最容易忽略的点
优化后别只测单条SQL耗时，高频场景下真正关键的是稳定性指标：
- 观察
SHOW GLOBAL STATUS LIKE 'Innodb_rows_read'是否显著下降——这是最真实的“扫描量”反馈 - 对比优化前后
Threads_running的P95值，高频SQL改善后，瞬时并发线程数波动会平缓很多 - 上线后紧盯
Performance Schema里的events_statements_summary_by_digest，确认该SQL的avg_timer_wait和sum_rows_examined双降，且没有其他SQL的指标异常上升 - 特别注意
Handler_read_next和Handler_read_rnd的变化：前者降说明顺序扫描减少，后者降说明随机IO（回表）减少
高频小SQL的优化效果往往不体现在“从50ms降到5ms”，而在于“让数据库不再喘不过气”。一旦开始关注Rows_examined_total而非单次Query_time，你就已经踩准了真实瓶颈。
