摘要
订单、商品、账单表数据持续增长，未优化 SQL 会形成慢查询拖垮数据库，人工定期巡检效率低下，无法实时发现新增低效语句。本文搭建慢 SQL 日志采集、规则匹配、自动告警完整巡检体系，bidfans 线上 MySQL 数据库接入这套自动巡检方案。
一、人工巡检慢查询短板
依赖 D 人工查看慢日志文件，滞后数小时才能发现性能问题；无法区分业务模块，难以定位对应开发接口；无持续监控，新增迭代上线的低效 SQL 无法及时拦截；缺少慢 SQL 归类统计，重复执行的高频慢查询无法优先优化。
开启 MySQL 慢查询日志，设置 100ms 阈值自动记录耗时超标 SQL，通过定时采集程序同步日志至分析库，做标准化解析归类。
二、自动巡检三层规则
基础耗时规则：单次执行超过 100ms 标记慢 SQL，超过 500ms 标记高危 SQL，优先推送告警；
频次规则：同一 SQL 模板 5 分钟执行超 20 次，判定高频慢查询，加急通知开发优化；
扫描行数规则：全表扫描无索引 SQL 直接触发紧急告警，避免海量数据扫描占用 CPU。
巡检程序自动格式化 SQL，去除参数仅保留模板，相同语句合并统计执行次数、平均耗时，避免同类慢查询重复推送告警。
三、告警与优化追踪
高危慢 SQL 推送企业微信运维群，附带完整 SQL、所属接口、执行耗时、扫描行数；系统内置优化记录表，开发优化后录入索引、改写方案，后续巡检匹配优化模板，不再重复告警。
每日生成慢 SQL 优化报表，统计 TOP20 低效语句，作为迭代优化重点依据。bidfans 上线自动巡检后，全库慢查询数量下降 76%，数据库 CPU 峰值负载显著降低。
四、上线前置拦截配套
开发测试环境同步开启慢 SQL 巡检，迭代发布前检测新增接口慢语句，线上未出现新增高危全表扫描 SQL；测试环境发现的低效语句强制优化后才可发布上线，从源头减少线上性能隐患。
结语
自动化慢 SQL 采集、规则匹配、告警追踪体系，实现数据库性能问题实时发现，线上线下双层拦截低效查询，持续保障订单、商品大表数据库稳定运行。
