慢查询告警需构建“采集—分析—告警—闭环”四层体系：采集层按数据库差异稳定获取真实慢sql；分析层通过指纹化、白名单过滤和上下文关联精准识别问题；告警层分级推送并附执行计划等关键信息；闭环层自动归档、效果验证并生成月度治理报告。
慢查询告警不是简单加个阈值就完事，核心是“及时发现 + 准确定位 + 可追溯分析”。关键在于把数据库的原始慢日志、性能指标和业务上下文串起来，避免告警泛滥或漏报。
采集层：稳定获取真实慢SQL
不同数据库采集方式差异大，不能一刀切：
- MySQL：优先开启 slow_query_log，设置 long_query_time=1（根据业务调整），并确保 log_output='FILE,TABLE' 或写入表（如 mysql.slow_log）便于程序拉取；禁用 log_queries_not_using_indexes 避免干扰
- PostgreSQL：配置 log_min_duration_statement = 1000（毫秒），配合 log_line_prefix 加入 %p %u %d %t（进程ID、用户、库名、时间戳），方便后续解析关联
- Oracle：依赖 AWR 报告或直接查 DBA_HIST_SQLSTAT 和 V$SQL，重点过滤 ELAPSED_TIME / EXECUTIONS > 1000000（即单次执行超1秒）且 PARSE_CALLS > 0 的活跃语句
分析层：过滤噪声、提取关键特征
原始日志里大量重复、低危害SQL会淹没真正问题，需结构化清洗：
- 统一SQL指纹化：去除换行、空格、常量值（如 WHERE id = 123 → WHERE id = ?），归并同类慢查询
- 排除已知白名单：跳过定时统计任务、DBA诊断语句、测试环境SQL等，通过 application_name、host 或注释（如 /* NOALERT */）识别
- 叠加运行时上下文：关联该SQL执行期间的 QPS突增、CPU使用率>90%、InnoDB Row Lock Time 等指标，判断是SQL本身问题还是系统瓶颈
告警层：分级推送+带上下文信息
告警消息必须让人一眼看懂“谁、在哪儿、干了啥、有多糟”：
- 按严重程度分三级：WARN（单次耗时 1~5s）、ERROR（>5s 或 1分钟内重复出现3次）、CRITICAL（阻塞其他事务、全表扫描且扫描行数 > 100万）
- 每条告警附带最小必要信息：数据库实例标识、执行用户、库名、表名（可从SQL解析出）、执行计划摘要（如 type=ALL, rows=2.4M, Extra=Using filesort）、最近3次平均耗时趋势图链接
- 推送渠道差异化：CRITICAL 发企业微信/钉钉+电话；ERROR 推送群+创建工单；WARN 仅推内部看板，不打扰
闭环层：自动归档与效果反馈
告警不能只发出去就结束，要形成处理记录和优化验证：
- 所有告警自动生成唯一ID，存入 alert_history 表，字段含：SQL指纹、首次触发时间、处理状态（待认领/已优化/误报）、负责人、解决时间、优化后耗时对比
- 对标记为“已优化”的SQL，自动开启7天观察期：若相同指纹SQL平均耗时下降 ≥ 80% 且无新告警，则关闭工单；否则提醒复核
- 每月生成《慢SQL治理报告》，统计TOP 5高频慢SQL、优化收益（如减少锁等待2.3h/天）、未闭环项原因（如依赖第三方接口超时）
