慢查询背后的安全面

发布时间:2026-06-25 17:38

## 匿名化案例 某站点的数据库监控连续数日报告慢查询，集中在一张用户表的全表扫描上，时段蹊跷，多在后半夜。开发的第一反应是索引缺失，补了索引仍有零星慢查询。安全侧同事介入后，把慢查询日志里的原始语句拉出来逐条翻看，发现若干构造异常的查询：条件里带着成对的引号与恒真表达式，明显不是正常业务代码能产生的形态，数据库正在被人尝试注入探测。 ## 根因分析 注入探测的原理是向输入点提交带 SQL 片段的内容，观察返回与报错差异来推断库表结构。这类探测查询常常命中没有索引的判断分支，执行计划劣化，于是先以慢查询的身份出现在监控里，而不是先触发安全告警。案例中问题的复合性在于：应用确实存在拼接 SQL 的旧代码，同时那张表也确实缺索引，两个问题叠加，让团队一开始只看到性能面。慢查询日志因此具有双重价值，它既是性能台账，也是一份免费的安全线索源。 ## 修复过程 修复分三线并行。代码线把拼接 SQL 改为参数化查询，输入不再进入语句结构。网络线收紧来源，通过防火墙规则对异常高频的来源做限制，并对可疑输入特征加监控。数据库线补齐索引，消除正常查询的全表扫描。三线完成后，慢查询曲线回落，异常语句从日志中消失。顺云的监控告警保留了整个事件的指标曲线，事后复盘有完整依据。 ## 复盘要点 这次事件的教训有三条。慢查询日志要有人定期看原始语句，而不是只看汇总指标，异常形态藏在原文里。性能问题与安全问题常常同源，排查性能时保持安全敏感，能把发现提前数日。参数化查询是结构性防御，索引只是性能补丁，两者不能相互替代。