第三讲：常见异常类型概览
审计日志里的异常，说白了就那几类。我做了这么多年数据库运维，见过的坑基本都跳不出这个圈。你想想看，攻击者想搞破坏，无非就是想办法进来、拖数据、或者让系统瘫掉。咱们今天就把这六类最常见的异常摸透。
1. 异常登录
这是最直接的入侵信号。我经历过一家电商公司，某天凌晨审计日志突然出现同一个IP对 root 账号连刷了三千次失败记录——这就是典型的暴力破解。
- 关键特征：短时间内大量 AUTHENTICATION_FAILED，源 IP 集中但用户名轮换，或者用户名固定但 IP 轮换。
- 触发条件：超过了正常的登录频率基线。建议设置每分钟同一 IP 超过 5 次失败就告警。
- 排查优先级：极高。一旦攻破，后续就是权限提升和数据窃取。
我个人习惯：把登录失败日志单独抽出来做个实时看板。不是说非要盯着，但持续 30 秒内超过 10 次失败一定要去看看发生了啥。
2. 慢查询
慢查询不一定是攻击，但很可能是程序写的烂 SQL。不过也有恶意场景——攻击者故意构造大范围扫描来拖垮数据库。
- 关键特征：执行时间远超平均值，比如平时 20ms 的查询突然飙到 5s，且不带索引提示。
- 触发条件：缺少合理过滤条件的 SELECT，或者嵌套子查询里做了笛卡尔积。
-- 一个典型的恶意慢查询例子
SELECT * FROM orders o
JOIN order_items oi ON o.id = oi.order_id
WHERE oi.product_name LIKE '%drop%'
ORDER BY o.created_at DESC;
注意：慢查询一旦堆叠，很快就会吃满 CPU 和 IO。我在项目中遇到过因为一个全表扫描的联表查询，直接把生产库拖挂了半小时。
3. 死锁
死锁是并发事务互锁的结果。SQL 日志里会清晰记录被 kill 的事务 ID 和回滚信息。
- 关键特征：日志中出现“Deadlock found”错误，伴随 LOCK WAIT 超时或事务回滚。
- 触发条件：两个事务以不同顺序操作同一组资源。比如事务 A 更新 row1 再更新 row2，而事务 B 更新 row2 再更新 row1。
- 排查方向：检查应用层的加锁顺序是否一致。我建议在审计日志里过滤“DEADLOCK”关键字。
4. 权限提升
这是攻击链的关键一步。攻击者进来之后，第一件事就是想办法拿到更高的权限。
- 关键特征：审计日志出现意外的 GRANT、CREATE USER、ALTER USER 等 DDL 语句，且执行用户是低权限账号。
- 触发条件：比如一个只读账号突然执行了 GRANT ALL。
- 排查优先级：一旦发现，需要立即隔离该账号并回滚变更。
我曾经处理过一起案例：某个应用账号被注入了恶意参数，导致其在调用存储过程时暗中执行了 GRANT SELECT ON *.* TO 'evil'@'%'。审计日志里捕捉的正是这条 SQL。
5. 数据泄露
数据泄露的审计特征很明显——大量 SELECT 或导出操作集中在非工作时间。
- 关键特征：单表全量 SELECT、SELECT * 频繁出现、导出命令（如 mysqldump）异常启动。
- 触发条件：对敏感表（user、payment、backup_config）的密集查询。
- 排查建议：设置行数阈值告警，单次 SELECT 超过 10000 行就触发复查。
-- 一条可疑的泄露查询
SELECT * FROM credit_card_info WHERE 1=1;6. 批量操作
批量操作需要和其他类型交叉分析。正常的批量任务（如 ETL、清理）和恶意操作有时只在 SQL 内容上差一个条件。
| 特征 | 正常维护 | 恶意操作 |
|---|---|---|
| 时间模式 | 固定窗口期 | 随机或非工作时间 |
| SQL 模式 | 有限制条件 | 全表 DELETE / UPDATE |
| 来源账号 | 预设的维护账号 | 非预期或临时账号 |
| 日志密度 | 持续稳定 | 突发密集 |
我曾经见过一个案例：某 DBA 半夜跑了个脚本，忘了加 WHERE 条件，直接把订单表 200 万条数据清空了。审计日志里记录的就是一条没有 WHERE 的 DELETE。所以，对没有 WHERE 或者 WHERE 中全是 1=1 的语句要格外警惕。
7. 异常 SQL 模式
这部分主要靠正则和模式匹配。攻击者经常使用特殊字符串绕过检测。
- 关键特征：SQL 中出现 UNION SELECT、INTO OUTFILE、LOAD_FILE()，或者注入大量注释符 /*！*/、恒等式 OR 1=1。
- 触发条件：注入点被探测成功，攻击语句生效。
- 排查方法：对非预期的关键字做拦截。我个人习惯在审计日志输入端就把 UNION、INTO 等标记为高风险。
-- 注入检测特征
/admin/product?id=1 OR 1=1--
/login?user=admin' UNION SELECT 1,2,3,4,5--这张图你多看两眼。六种异常不是孤立存在的，它们往往是层层递进的关系。攻击者从“异常登录”进来，接着“权限提升”，然后开始“数据泄露”或者触发“异常 SQL 模式”。你排查的时候，如果能顺着这条线看日志，效率会高很多。