MySQL触发器无法防止绕过，真正起效的是DEFINER+SQL SECURITY DEFINER组合配合权限隔离；必须回收用户对基表的DML权限、使用专用低权限DEFINER账号、显式声明SQL SECURITY DEFINER、禁用动态SQL，并严控对象级访问。
MySQL 触发器本身无法防止用户绕过限制——它不提供访问控制能力，只响应数据变更。真正起作用的是 DEFINER 和 SQL SECURITY DEFINER 的组合，配合权限隔离才能封住绕过路径。
为什么直接给用户表权限就等于失效
触发器运行时以 DEFINER 身份执行，但用户仍可绕过触发器逻辑，直接操作底层表。比如你建了个 AFTER INSERT 触发器用于审计，但如果用户有对原表的 INSERT 权限，他就能跳过所有触发器前检查，甚至用 INSERT ... SELECT 批量写入绕过单行校验。
- 必须显式回收用户对触发器关联表的 DML 权限：
REVOKE INSERT, UPDATE, DELETE ON mydb.target_table FROM 'user'@'%' - 只保留对其所依赖日志表、审计表等辅助表的最小权限（如果需要）
- 检查残留权限：
SHOW GRANTS FOR 'user'@'%'，确保输出里没有target_table相关项 - MySQL 8.0+ 中
TRIGGER权限不再包含在ALL PRIVILEGES里，单独授予时也要确认用户没被意外赋予ALTER或DROP表权限
DEFINER 账户必须是专用低权限账号
很多人把 DEFINER = 'root'@'%' 当成省事方案，结果触发器一执行就提权——这是最典型的越权入口。DEFINER 账户不该是高权限账号，而应是仅具备触发器内语句所需权限的专用账号。
- 创建专用账户：
CREATE USER 'trg_runner'@'localhost' IDENTIFIED BY 'xxx'; - 只授必要权限：
GRANT SELECT, UPDATE ON mydb.audit_log TO 'trg_runner'@'localhost';（根据触发器实际 SQL 精确匹配） - 绝不能授予
mysql库、information_schema或跨库权限 - 检查现有触发器定义：
SELECT TRIGGER_NAME, DEFINER, EVENT_MANIPULATION FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA = 'mydb';
SQL SECURITY DEFINER 是强制执行上下文的关键
如果不显式声明 SQL SECURITY DEFINER，MySQL 默认就是它，但显式写出能避免被忽略或误设为 INVOKER。一旦设成 INVOKER，触发器就退化成“按调用者权限跑”，等于没加锁。
- 创建时必须带声明：
CREATE DEFINER = 'trg_runner'@'localhost' SQL SECURITY DEFINER TRIGGER ... -
SQL SECURITY INVOKER在触发器中基本无意义：用户已有表权限时它不增强安全；没权限时它让触发器直接失败，起不到保护作用 - 注意 MySQL 5.7 与 8.0 对
DEFINER用户存在性检查更严格：若DEFINER账号不存在，即使SQL SECURITY DEFINER也没法执行
触发器里别碰动态 SQL 和用户输入
触发器内部拼接字符串 + EXECUTE IMMEDIATE（或 MySQL 的 PREPARE）是高危操作，会把注入风险从应用层带到数据库内核层，且因 DEFINER 权限过高，后果比普通 SQL 注入更严重。
- 禁止这种写法：
SET @sql = CONCAT('UPDATE users SET status = ''', NEW.status, ''' WHERE id = ', NEW.user_id); PREPARE stmt FROM @sql; - 所有值必须用参数化方式传入，或直接写死条件（如固定更新某字段）
- 如果真需根据条件分支执行不同逻辑，改用
CASE WHEN或拆成多个触发器，而不是拼 SQL - 触发器中调用存储函数可以，但该函数也必须是
SQL SECURITY DEFINER，且内部不能含SELECT以外的危险操作（如无限制的子查询）
最常被忽略的一点：触发器不会阻止用户删表、清空表或用 TRUNCATE 绕过所有行级逻辑。防御边界不在触发器本身，而在权限收口和对象访问控制——DEFINER 账号越干净、用户对基表权限越窄、触发器逻辑越静态，绕过可能性就越低。
