SQL 告警过多为何是危险信号？

告警多本质是底层问题批量暴露，如索引缺失、配置不当、架构瓶颈或设计缺陷；重复同类告警预示系统性风险，需根因治理而非临时处置。

不是告警多才危险，而是告警多说明底层问题正在批量暴露

告警背后往往是资源瓶颈或设计缺陷在“连环触发”

比如 seq_scan 告警集中爆发（如 GaussDB 中扫描率 100% 的表扎堆出现），通常不是单个 SQL 写错了，而是这批表共用同一类低效访问模式：没索引、索引失效、统计信息过期、或查询条件始终无法命中索引字段。这时候杀掉几个慢 SQL 只是掩耳盗铃——新请求一来，照样扫全表。

• MySQL 的 CPU 使用率过高 告警常伴随大量 SELECT 或未提交事务，但根源可能是 innodb_buffer_pool_size 配得太小，导致频繁刷盘+重读
• 连接数达到上限 看似是应用层不释放连接，实际常因某条 SQL 执行超时卡住连接，而下游服务又不断重试，形成雪崩式堆积
• SQL Server 出现重复告警（如 DeviceId + AlarmType + AlarmTime 多次插入），表面是业务逻辑没去重，深层是缺乏唯一约束或幂等机制，数据已开始失真

告警噪声会掩盖真正致命的问题

当监控系统每分钟推送几十条 delete 被 kill 或 主从延迟 > 60s，运维和开发会本能地“挑最急的先处理”，结果是反复修同一个表的索引、调同一批参数，却忽略更底层的架构问题：比如定时删除任务没分批、没加限流，或主库写入流量早已超出单实例承载能力。

• 有赞的 sql-killer 工具本意是兜底，但如果它每天自动 kill 掉上百条 DELETE FROM t_log WHERE create_time ，说明归档策略根本没落地
• 查看 /home/ruby/log/adaptor_log/metric_adaptor.log 发现 rds413 告警集中在某个业务库，就该立刻进库查 pg_stat_user_tables，而不是先翻告警平台的聚合图表
• 很多团队把 OOM 当成内存泄漏，其实可能是某条 SQL 的 GROUP BY + ORDER BY 在大表上生成了超大临时结果集，直接吃光 sort_buffer_size

高频告警往往意味着修复成本正在指数级上升

一条慢查询刚出现时，加个索引可能 5 分钟搞定；等它引发连接池耗尽、主从延迟、应用超时雪崩后，就得停业务、切流量、改代码、压测验证——时间成本从分钟级跳到天级。

• GaussDB 的 seq_scan > 10 是个关键阈值，不是“超过 10 次才要管”，而是“连续 10 次扫描没走索引，说明这个访问路径已被业务固化”
• MySQL 的 max_connections 从 200 调到 500 容易，但若真实并发峰值已

  

  达 480，说明你已经没有缓冲余量，下次流量脉冲就是故障
• SQL Server 中用 ROW_NUMBER() OVER (PARTITION BY ...) 清重能救急，但若每天新增百万级告警，UNIQUE 约束建好后必须同步检查历史脏数据，否则约束会直接报错阻断写入

最该警惕的不是某条告警的内容，而是同一类告警在不同时间、不同实例、不同业务模块里反复出现——那说明你正在用创可贴包扎动脉破裂。