SQL Server触发器无法真正防止主键ID被恶意篡改，因主键约束校验早于触发器执行，且高权限用户可禁用触发器或修改表结构；有效防护需结合主键设计、最小权限控制与DDL审计。
SQL Server 中触发器被 DISABLE 的常见路径
高权限账号执行 DISABLE TRIGGER 是最直接的绕过方式。只要用户拥有 ALTER TABLE 或 CONTROL 权限，就能让触发器彻底失效——哪怕它逻辑再严密，也根本不会运行。
典型错误做法是把触发器部署在开发账号下，而该账号同时具备 db_owner 角色。一旦该账号被泄露或误用，DISABLE TRIGGER tr_protect ON users 一行命令就清空所有防护。
- 检查当前触发器状态：
SELECT name, is_disabled FROM sys.triggers WHERE parent_id = OBJECT_ID('users') - 禁用触发器不需要 EXECUTE 权限，只需对表有 ALTER 权限——所以不能只靠“不给 EXECUTE”来防
- SQL Server 不会审计
DISABLE TRIGGER操作，默认日志里看不到，必须靠 DDL 触发器捕获
MySQL 触发器因 DEFINER 权限失控导致失效
MySQL 触发器默认以 DEFINER 身份执行，但如果定义者是 'root'@'%'，而攻击者拿到了 root 权限（比如通过弱密码或远程漏洞），就能直接删掉触发器、改写逻辑，甚至用 SET SQL_LOG_BIN = 0 绕过 binlog 记录。
更隐蔽的问题是：用户仍有对基表的 INSERT/UPDATE 权限。此时触发器形同虚设——他根本不用触发器，直接写表。
- 必须回收用户对目标表的 DML 权限：
REVOKE INSERT, UPDATE ON mydb.users FROM 'app_user'@'%' - DEFINER 必须是专用低权限账号，且只授触发器内实际用到的权限（比如仅
INSERT到 audit_log 表） - 显式声明
SQL SECURITY DEFINER，避免被误设为INVOKER——后者会让触发器按调用者权限跑，等于没锁
PostgreSQL 中触发器无法拦截 SET ROLE 或 GRANT
PostgreSQL 触发器只响应 INSERT/UPDATE/DELETE/TRUNCATE，对权限变更类操作完全无感。用户拿到 CREATEROLE 权限后，可以 SET ROLE admin 切换身份，再往敏感表插入数据——触发器看到的只是“admin”写的记录，但无法知道这个 admin 是合法登录还是临时切换来的。
同样，GRANT ALL ON users TO attacker 后，触发器照样运行，但已失去意义：攻击者现在可以直接删表、建函数、导出数据。
- 触发器不能替代 RBAC 设计，必须配合
RLS策略和最小角色权限（比如只给USAGEon schema，不给CREATE） - 若需校验上下文，要用
current_setting('app.role', true)这类会话变量，而非依赖current_user - 系统表（如
pg_authid）不受 RLS 和普通触发器保护，必须靠操作系统级访问控制和连接限制
所有数据库共通的盲区：DDL 触发器本身可被删
有人以为加了 DDL 触发器就能防 DROP TABLE，却忘了 DDL 触发器自己也是数据库对象——只要权限够，DROP TRIGGER tr_block_ddl 就能一键清空防线。
更麻烦的是：SQL Server 的服务器级 DDL 触发器对 DROP INDEX 事件无法提取完整对象名；MySQL 的 information_schema.TRIGGERS 表可能被权限限制查不到；PostgreSQL 的事件触发器（event trigger）虽能监听 ddl_command_start，但不能用 RAISE EXCEPTION 中断事务，只能记录或发通知。
- DDL 触发器必须绑定到最高可用作用域（如
ON DATABASE或ON ALL SERVER），并显式ENABLE - 解析
EVENTDATA()或pg_event_trigger_ddl_commands()时，字段名大小写、XML 节点路径、返回类型都要严格匹配，错一个就漏判 - 真正关键的防护不在触发器本身，而在谁有权创建、修改、删除它——DBA 账号必须隔离，生产库禁止交互式登录
