不能。触发器在SQL解析完成、权限校验通过后才执行，仅处理已解析的NEW值，无法拦截改变语句结构的SQL注入；它不接收原始SQL字符串，既易误杀正常数据（如“O’Reilly”），又无法防御参数化绕过或拼接型注入，真正防护应靠应用层参数化查询与最小权限原则。
SQL触发器不能用于防御SQL注入
直接说结论：CREATE TRIGGER 无法阻止SQL注入。触发器在数据写入表时才执行，而SQL注入发生在查询拼接阶段——也就是SELECT、INSERT语句构造时，远早于触发器的触发时机。你还没走到“插入”那步，恶意SQL已经让数据库执行了非预期操作（比如删库、读取系统表），触发器根本没机会介入。
为什么有人误以为触发器能防注入
常见误解来源有两类：
- 混淆了「输入校验」和「数据入库校验」：前端或应用层未过滤的恶意字符串（如
' OR 1=1 --）被拼进SQL后直接执行，根本不会走到INSERT INTO users这一步；哪怕你给users表加了触发器，它对SELECT * FROM users WHERE name = 'admin' OR 1=1 --'这类语句完全无感 - 把触发器当成了「SQL语句防火墙」：触发器只能响应
INSERT/UPDATE/DELETE事件，且仅作用于目标表的数据变更；它既不能拦截、重写、拒绝原始SQL语句，也无法访问当前执行的SQL文本（MySQL不暴露QUERY_STRING，PostgreSQL需配合pg_stat_statements配合外部监控）
真正该用的地方：事后审计与异常数据拦截
触发器唯一可行的防御相关用途，是作为最后一道数据清洗/阻断环节，但仅限于明确知道字段格式的场景，例如：
-
phone字段必须为 11 位数字：触发器中用REGEXP '^[0-9]{11}$'校验，不匹配则SIGNAL SQLSTATE '45000'报错 - 禁止在
username中存入admin、root等保留字：触发器里用IF NEW.username IN ('admin', 'root') THEN ... END IF - 自动转义存储内容（不推荐）：如将输入中的单引号替换成两个单引号（
REPLACE(NEW.content, "'", "''")），但这只对后续拼接安全，不解决原始注入问题
注意：这类逻辑必须搭配应用层参数化查询使用，否则触发器本身可能被绕过（比如通过 INSERT ... SELECT 从另一张已污染的表导入数据）。
绕过触发器校验的典型方式
只要攻击者能控制任意一条可写入的SQL路径，触发器就形同虚设：
- 利用
UPDATE修改其他字段，再通过业务逻辑间接触发敏感操作（如改is_admin=1） - 用
INSERT INTO ... SELECT绕过单字段校验：比如触发器只检查name，但攻击者构造INSERT INTO logs SELECT password FROM users，根本不经过触发器约束的表 - 高权限账号直连数据库执行命令（如 MySQL 的
LOAD_FILE()、INTO OUTFILE），完全跳过应用层和触发器
最易被忽略的一点：触发器错误处理本身可能泄露信息。比如 SIGNAL 报错时返回的错误消息若含表名、字段名或正则模式，反而帮攻击者反推过滤规则。
