SQL触发器无法防止SQL注入。注入发生在应用拼接SQL阶段，触发器仅在语句解析执行后才运行，既看不到原始SQL，也无法拦截已执行的恶意操作；真正防护须依赖应用层参数化查询与数据库最小权限控制。
SQL触发器根本无法防止SQL注入攻击
直接说结论：CREATE TRIGGER 对 SQL 注入完全无效。注入发生在应用拼接 SQL 字符串阶段（比如 PHP 中 "SELECT * FROM users WHERE name = '" . $_GET['name'] . "'"），而触发器只在语句已通过语法解析、权限校验、准备执行时才被调用——此时恶意查询早已执行完毕，删库、读取 information_schema 或调用 load_file() 都已完成，触发器连“看一眼原始语句”的机会都没有。
为什么有人在触发器里写 IF NEW.role LIKE '%admin%' 还是挡不住权限篡改
这类逻辑看似在“拦输入”，实则存在三类硬伤：
- 触发器只响应
INSERT/UPDATE事件，而权限提升常通过SELECT注入完成（如UNION SELECT password FROM mysql.user），压根不触发表变更 - 攻击者可用
INSERT INTO permissions SELECT 'admin', user_id FROM logs WHERE id = 123绕过目标表的触发器——只要源表logs没触发器，数据就干净入库 -
NEW.role是最终值，不是原始输入；若应用层已把' OR 1=1 --拼进 role 字段再哈希存储，触发器看到的只是哈希串，无法还原攻击意图
真正该拦截权限变更的位置：应用层 + 数据库权限体系
防止核心权限被篡改，必须分两层堵死：
- 应用层强制使用参数化查询：
pg.query("UPDATE users SET role = $1 WHERE id = $2", [role, id])，杜绝任何字符串拼接 - 数据库层收缩权限：
GRANT UPDATE (role) ON users TO app_user，禁用UPDATE users SET *全字段更新能力 - 对高危字段加
CHECK约束而非触发器：ALTER TABLE users ADD CONSTRAINT valid_role CHECK (role IN ('user', 'editor', 'admin'))，更轻量且不可绕过
如果非要用触发器做辅助，必须避开这些坑
仅限极少数审计合规场景（如“所有 is_admin 变更必须记录操作人”），但要注意：
-
SIGNAL SQLSTATE '45000'在 MySQL 5.5 以下版本不支持，低版本只能写日志后放行，起不到阻断作用 - 触发器以定义者权限运行，若用
DEFINER = root@localhost，可能被诱导执行越权操作（如写系统表） - 动态 SQL（
EXEC sp_executesql @sql）出现在触发器内是高危行为，用户输入一旦进入@sql字符串，立刻引发二次注入
最常被忽略的一点：触发器不校验 INSERT ... SELECT 的源数据合法性，只要攻击者能往任意一张中间表写入恶意值，就能借触发器信任链污染核心权限字段。
