触发器不能防止SQL注入。注入发生在应用拼接SQL阶段，而触发器仅在语句执行阶段触发，无法拦截已构造的恶意查询；真正防护须在应用层使用参数化查询。
触发器不能防止 SQL 注入
直接说结论：CREATE TRIGGER 对 SQL 注入毫无防御能力。注入发生在应用拼接 SQL 阶段，而触发器只在语句通过语法检查、进入执行阶段后才被调用——此时恶意逻辑早已落地，甚至数据已被篡改或脱库。
常见错误现象：有人在 INSERT 触发器里加 IF NEW.content LIKE '%<script>%' THEN SIGNAL SQLSTATE '45000' ...</script>，以为能拦住 XSS 式输入；结果发现 SELECT * FROM users WHERE name = 'admin' OR 1=1 -- ' 这类注入根本不会触发任何 INSERT/UPDATE 触发器，更别提绕过权限直接读取系统表的联合查询。
真正该拦截的位置：应用层预处理
SQL 注入必须在语句构造前就切断。数据库触发器不是防火墙，PreparedStatement 才是。
使用场景明确：只要用字符串拼接生成 SQL（比如 Python 的 "SELECT * FROM user WHERE id = " + user_id），就已处在高危状态。
实操建议：
- Java 用
PreparedStatement，参数一律走setString()等方法，别碰Statement - Python 用
cursor.execute("SELECT * FROM t WHERE x = %s", [value])，禁用.format()或f""拼接 SQL - PHP 用
PDO::prepare()+bindValue()，不用mysql_query("...$var...") - Node.js 用
pg.query("SELECT * FROM u WHERE id = $1", [id])，不写`SELECT ... ${id}`
如果硬要用触发器做辅助校验，注意这三点
极少数合规场景（如审计要求“所有敏感字段变更必须留痕”）可能需触发器配合，但它只是补丁，不是防线。
容易踩的坑：
-
SIGNAL在 MySQL 5.5+ 才支持，低版本只能靠INSERT INTO error_log记录后任其执行，起不到拦截作用 - 触发器无法访问原始 SQL 语句，
NEW和OLD只反映最终值——攻击者用UPDATE users SET password = MD5('x') WHERE id = 1绕过内容检测，触发器看到的只是哈希后的password字段，无法还原意图 - 性能影响真实存在：每个
INSERT都多一次条件判断和可能的SIGNAL抛出，QPS 高时延迟明显上升，尤其在分库分表后跨节点触发器不可用
为什么 DBA 有时会配触发器？不是防注入，是防误操作
生产库上常见的 BEFORE UPDATE 触发器，目的其实是阻止全表更新：IF ROW_COUNT() = 0 AND NOT (NEW.updated_at OLD.updated_at) THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Unsafe UPDATE without WHERE';
这类配置和 SQL 注入无关，它针对的是开发人员忘记写 WHERE 条件导致整张表被覆盖。真正的注入防护，永远得从应用代码里把 user_input 和 SQL 结构彻底隔开——触发器连这个边界都摸不到。
最常被忽略的一点：哪怕你给所有表都加上触发器，只要应用还用 mysqli_query($conn, "SELECT * FROM $table WHERE id = $id")，注入就稳稳成立。数据库层面没有银弹，只有代码里的那一个 ? 或 $1 是真·防线。
