数据库慢查询日志突然从每天几十条涨到几千条，很多维护人员的第一反应是“数据库是不是出问题了”。但慢查询日志暴增，更像是一个提醒信号：某些语句的执行方式或访问模式发生了变化，数据库本身未必已经不可用。真正要做的，是从大量日志里快速分辨出哪些语句需要优先处理，哪些只是偶发波动。
慢查询通常集中在三类来源。第一类是缺少合适索引的查询，数据量小的时候看不出异常，一旦表内记录增长，扫描成本就会明显上升。第二类是数据量增长后出现的全表扫描，常见于统计、导出、模糊匹配等场景，语句本身没变，但执行代价会随着数据规模放大。第三类是并发高峰下的锁等待，语句执行时间变长，不一定是因为它本身复杂，而是被其他事务阻塞，日志里往往表现为等待时间占比偏高。
排查时建议按固定顺序推进。先看执行时间的分布，把日志按耗时区间归类，区分是整体变慢，还是少数语句极端耗时。再看扫描行数，扫描行数远大于返回行数，通常意味着索引利用不充分。最后结合锁等待和连接数变化判断，如果慢查询集中出现在同一时间段，并且伴随连接数上升，就要优先怀疑锁竞争或连接池配置问题。这个顺序能避免一上来就盯着最长的语句，却忽略了真正的诱因。
处理时要区分临时措施和长期优化。临时重启数据库或直接杀掉慢查询，只能短暂缓解，日志很快会再次堆积。盲目加索引同样有风险，索引会增加写入负担，也可能因为选择度低而效果有限。更稳妥的做法是先保留现场，记录慢查询的语句特征、出现时段和关联业务，再判断是改语句、调索引，还是调整访问频率。
长期来看，慢查询日志的价值在于持续观察，而不是一次性清理。可以固定每周或每月做一次复盘，对比语句类型和数量变化，形成自己的记录习惯。像it数运在网站维护中强调的流程思路一样，把日志观察、原因归类和处理记录分开管理，下次再遇到暴增时就能更快判断方向。数据库慢查询并不可怕，可怕的是每次都从头猜起。
