mysql触发器无防篡改机制，防护依赖sql security definer配合专用定义者账号与权限最小化：创建account lock账号、仅授必要dml权限、触发器调用definer函数并限制alter routine权限。
MySQL 触发器本身没有“防篡改”机制，DROP TRIGGER 和 ALTER TRIGGER 的权限控制完全依赖于用户是否拥有 TRIGGER 权限——而该权限一旦授予，就等同于允许创建、修改、删除。真正能落地的防护，靠的是 SQL SECURITY 配合权限隔离与执行上下文约束，不是靠锁住触发器代码本身。
为什么 SQL SECURITY DEFINER 不能防止篡改，但能限制执行副作用
SQL SECURITY 只影响触发器体内的语句以谁的身份执行（DEFINER 或 INVOKER），不控制谁可以 ALTER 它。但它能避免“低权限用户通过高权限触发器越权操作”：比如一个 DEFINER = 'dba'@'%' 的触发器，即使由 'app'@'%' 用户触发，内部的 INSERT INTO audit_log 也按 dba 权限检查——所以你必须确保 dba 对 audit_log 有 INSERT 权限，而 app 用户没有。
- 默认是
SQL SECURITY DEFINER，即按定义者权限执行；显式写SQL SECURITY INVOKER才按调用者权限 - 若未指定
DEFINER子句，MySQL 自动设为当前用户，容易造成权限意外提升 -
DEFINER用户必须存在且拥有触发器内所有操作所需的权限，否则触发时直接报错（如ERROR 1442或ERROR 1142） - 复制环境里，从库回放触发器时仍会校验
DEFINER用户是否存在及权限是否匹配
如何用 DEFINER + 权限最小化堵住“借壳越权”路径
恶意用户无法直接改触发器，但可能利用已有触发器做坏事——比如在自己能写的表上挂一个 DEFINER = 'root'@'%' 的触发器，然后通过插入数据间接执行高危操作。堵住这个口子的关键是：定义者账户必须是专用、无交互登录能力、权限精确收敛的账号。
- 创建专用定义者账号：
CREATE USER 'trigger_definer'@'localhost' IDENTIFIED BY 'xxx' ACCOUNT LOCK;（ACCOUNT LOCK禁止登录） - 只授必要权限：
GRANT INSERT ON sys.audit_log TO 'trigger_definer'@'localhost';，不给SELECT、DROP、GRANT OPTION - 建触发器时显式指定：
CREATE DEFINER = 'trigger_definer'@'localhost' TRIGGER ... - 禁止普通用户对
mysql.proc或information_schema.TRIGGERS的写访问——虽然他们本来也不能写，但得确认没被误开UPDATE权限
ALTER TRIGGER 无法禁用，但可让修改失效
MySQL 没有 READ ONLY TRIGGER 选项。但你可以让 ALTER TRIGGER 变得“改了也白改”：把触发器逻辑抽成函数，再让触发器只调用该函数，并将函数设为 SQL SECURITY DEFINER。这样，即使有人 ALTER TRIGGER，只要没动函数体，核心逻辑就不变。
- 函数必须显式授权
EXECUTE：GRANT EXECUTE ON FUNCTION mydb.enforce_policy TO 'trigger_definer'@'localhost'; - 触发器内只保留调用：
CALL mydb.enforce_policy(NEW.id);，不写业务逻辑 - 函数本身用
DEFINER账号创建，且该账号无ALTER ROUTINE权限——这样连函数都改不了 - 注意：函数若含
INSERT/UPDATE，仍需确保DEFINER对目标表有对应 DML 权限
最易被忽略的一点：DEFINER 用户被 DROP USER 后，所有以其定义的触发器不会立即失效，但首次触发时会报 ERROR 1449 (HY000): The user specified as a definer ('x'@'y') does not exist。所以定义者账号不能随便删，也不该复用生产管理员账号。
