是，触发器以定义者权限运行，绕过应用层权限校验；可能使低权限用户间接执行高危操作，如通过日志表INSERT触发薪资UPDATE，形成权限后门。

触发器是否绕过了应用层权限校验

这是最常被忽略的高危点。触发器以定义者权限运行，不是调用者权限。

如果 CREATE TRIGGER 是用 db_owner 或 sa 账户执行的，那任何能写入触发表的低权限用户，都可能间接触发高权限操作。

典型现象：日志表 audit_log 可被普通用户 INSERT，但其触发器里却执行了 UPDATE employees SET salary = ...。这等于给了用户修改薪资的后门。

• 检查触发器定义中的 EXECUTE AS（SQL Server）或 DEFINER（MySQL），确认是否显式降权
• 禁止在触发器中更新非关联的敏感表，如 users、config、permissions
• 上线前用最小权限账户做 DML 测试，观察是否意外修改了不该动的表

触发器是否引入隐式跨表写入或递归

一旦触发器修改了自身监听的表，或修改了另一张也带触发器的表，就极易陷入无限递归或事务死锁。

这类问题常在批量操作时爆发，但单条测试时往往看不出异常。

一个典型场景是：在 AFTER INSERT ON orders 触发器里继续执行 INSERT INTO order_items，而 order_items 这张表上自己也挂了触发器。

再比如，触发器内部又去 UPDATE 同一张 orders 表，例如重新计算状态字段。

• 用 SELECT * FROM sys.triggers（SQL Server）或 SHOW TRIGGERS（MySQL）列出所有触发器，人工画出依赖图
• 在触发器开头加硬性防护：IF @@NESTLEVEL > 2 RETURN（SQL Server）或 IF (SELECT COUNT(*) FROM information_schema.triggers WHERE event_object_table = 'orders') > 1（MySQL 粗略判断）
• 禁用间接递归：ALTER DATABASE ... SET RECURSIVE_TRIGGERS OFF（SQL Server）

触发器逻辑是否可被业务代码绕过

很多团队把触发器当“兜底逻辑”，但实际运行中，ORM 批量更新、直连 JDBC 的后台脚本、甚至 MySQL 的 LOAD DATA INFILE 都可能不触发它。

一旦如此，数据一致性会瞬间崩塌。

很常见的情况是：订单状态原本靠触发器同步到 order_summary，但如果运营后台直接执行 UPDATE orders SET status = 'shipped' WHERE id IN (...)，绕开了应用层，这条同步链路就等于被截断了。

结果就是 summary 表会一直不同步。

• 明确触发器适用边界：只对走标准业务路径的 DML 有效，不覆盖运维/ETL/迁移等场景
• 关键一致性逻辑（如库存扣减、余额更新）必须由应用层显式控制，触发器仅作审计或强校验（RAISERROR 中断非法操作）
• 若必须用触发器保一致性，需配套检查机制：定时比对主从表差异，报警而非静默容忍

触发器是否放大了批量操作的性能损耗

触发器是逐行（FOR EACH ROW）执行的。

10 万条记录的 INSERT，会触发 10 万次触发器逻辑。哪怕只是简单 INSERT INTO log，也可能因索引维护、锁竞争拖慢整体耗时 10 倍以上。

典型症状是：日常单条插入毫秒级，批量导入时数据库 CPU 持续 95%、慢查询日志里全是触发器相关语句。

• 用 EXPLAIN 或 SET STATISTICS IO ON 查看触发器内 SQL 的实际执行计划，确认无全表扫描
• 避免在触发器里做聚合计算（如 SUM()）、JOIN 大表、或调用函数（尤其是标量函数）
• 批量场景优先改用应用层批处理 + 异步消息（如 Kafka），触发器只留最简日志记录

容易被忽视的隐藏风险

真正难评估的不是触发器写了什么，而是它没写什么。

比如没处理事务回滚后的清理、没兼容 ORM 的乐观锁字段、没考虑主从延迟下读取 NEW/OLD 值的时序问题。

这些点通常不会直接报错，但会在特定负载或配置下突然失效。

《夸克》非常好用的免费AI浏览器

下载APP查看