先说几个核心判断：数据库里跑的那些查询，看着简单，可一旦慢起来，真的能把整个系统拖成“蜗牛”。特别是订单、商品、账单这种大表，数据量一天天涨，SQL性能问题就暴露得格外明显。
传统做法是什么呢？全靠DBA人工盯着慢日志文件看，白天出问题，晚上才能发现，滞后好几个小时都算快的。更头疼的是，根本分不清是哪个业务模块、哪个接口出的问题。而且没有持续监控，新上线的迭代一发布，低效SQL就悄悄溜进去了。更麻烦的是，没有慢查询归类统计，那些重复执行上百次的高频慢查询，反而没人优先处理。
要解决这个问题，首先得让MySQL自己把慢查询记下来。把阈值设到100毫秒，超过这个线的SQL全自动记录。然后搞一个定时采集程序，把这些日志同步到分析库里，做标准化解析和归类。
一、人工巡检慢查询短板
依赖D人工查看慢日志文件，滞后数小时才能发现性能问题；无法区分业务模块，难以定位对应开发接口；无持续监控，新增迭代上线的低效SQL无法及时拦截；缺少慢SQL归类统计，重复执行的高频慢查询无法优先优化。
开启MySQL慢查询日志，设置100ms阈值自动记录耗时超标SQL，通过定时采集程序同步日志至分析库，做标准化解析归类。
二、自动巡检三层规则
针对这些问题，行业里通常怎么搭自动巡检体系？核心在三个层面。
基础耗时规则
单次执行超过100毫秒的，直接标记为慢SQL；超过500毫秒的，直接打上高危标签，优先推送告警。
频次规则
同一个SQL模板，5分钟内执行超过20次，就会判定为高频慢查询。这种必须加急通知开发优化，因为它对系统的影响是持续性的。
扫描行数规则
更严重的来了——全表扫描、没索引的SQL，直接触发紧急告警。避免海量数据扫描吃掉CPU资源，这才是关键所在。
巡检程序会把SQL自动格式化，去掉参数，只保留模板。相同语句合并统计执行次数、平均耗时，这样就不会出现同类慢查询重复推送告警的情况。
三、告警与优化追踪
告警出来了，也不能白忙活。高危慢SQL会直接推送企业微信运维群，完整SQL、所属接口、执行耗时、扫描行数一个不少。系统还内置了优化记录表，开发人员优化后要录入索引或改写方案。下一次巡检时，匹配到这个优化模板，就不再重复告警。
每天还会自动生成慢SQL优化报表，统计TOP20低效语句，作为迭代优化重点依据。上线这套体系以后，全库慢查询数量下降了76%，数据库CPU峰值负载明显降低。
四、上线前置拦截配套
这套体系不只在线上跑，开发测试环节也得跟上。开发测试环境也同步开启慢SQL巡检，迭代发布前就能检测到新增接口的慢语句。线上没再出现新增的高危全表扫描SQL。测试环境发现的低效语句，必须强制优化后才允许发布上线，从源头就减少了线上性能隐患。
结语
自动化慢SQL采集、规则匹配、告警追踪体系，实现了数据库性能问题的实时发现。线上线下双层拦截低效查询，持续保障订单、商品大表数据库的稳定运行。
