是，触发器以定义者权限运行，绕过应用层权限校验；可能使低权限用户间接执行高危操作，如通过日志表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 值的时序问题。这些点不会报错，但会在特定负载或配置下突然失效。
