MySQL触发器的触发时机不可动态控制，只能在触发器体内用IF判断业务条件；需避免使用变量控制逻辑，推荐通过配置表+SELECT INTO读取开关标志，并注意OLD/NEW字段访问限制与安全比较方式。
触发器里不能用变量或参数控制触发逻辑
MySQL 触发器的触发条件（BEFORE INSERT、AFTER UPDATE 等）是静态定义的，运行时无法根据业务状态动态切换。你没法在触发器内部写 IF @enable_audit THEN ... END IF; 这类逻辑来“开关”行为——因为会话变量、用户变量、存储过程变量在触发器中不可靠，且不被允许用于控制是否执行整个触发动作。
常见错误现象：ERROR 1442 (HY000): Can't update table 'xxx' in stored function/trigger because it is already used by statement which invoked this stored function/trigger，往往就源于试图在触发器里读取或修改影响当前语句的变量或表，还误以为能靠它绕过逻辑。
- 触发器本质是事件响应机制，不是条件调度器；它的“条件”只在 SQL 语句层面（如
INSERT INTO t1是否命中该表），不支持运行时策略分支 - 真正需要“动态逻辑”的场景（比如仅对
status = 'paid'的订单记录审计），必须把判断逻辑写进触发器体内部，而不是试图改变触发时机本身 - 不要尝试用
SELECT @flag := 1 FROM config WHERE key = 'audit_enabled'来控制，这个值可能被并发覆盖，且 MySQL 8.0+ 明确禁止在触发器中赋值用户变量
用 IF + 条件表达式在触发器体内做逻辑分流
动态逻辑的实际落点，是在触发器 BEGIN ... END 块里写 IF 判断。例如：同一张订单表，有时要记录操作日志，有时只在特定字段变更时才记——就得在 AFTER UPDATE 触发器里检查 OLD.status != NEW.status 或 NEW.amount > 10000。
使用场景：支付系统中，只有当 order_status 从 'pending' 变为 'shipped' 才调用外部通知接口（通过写入消息表模拟）；其他状态流转不触发。
IF OLD.status = 'pending' AND NEW.status = 'shipped' THEN INSERT INTO notify_queue (...) VALUES (...); END IF;- 注意比较 NULL：用
OLD.field NEW.field替代!=，避免NULL != 'x'返回NULL导致条件失效 - 避免在
IF中嵌套复杂查询——触发器内查大表或连表极易拖慢主 DML，应只查轻量配置表（如单行config表），且务必加主键等高效索引
配置表驱动的触发逻辑开关（安全可行的方式）
如果业务要求“随时关闭某触发器行为”，又不想反复删改触发器定义，可以用一张极简配置表，让触发器每次执行时读取一个标志位。这是唯一被 MySQL 允许且稳定的“动态”手段。
示例结构：CREATE TABLE trigger_config (name VARCHAR(64) PRIMARY KEY, enabled TINYINT DEFAULT 1); INSERT INTO trigger_config VALUES ('order_audit', 1);
- 在触发器中写：
DECLARE v_enabled TINYINT DEFAULT 0; SELECT enabled INTO v_enabled FROM trigger_config WHERE name = 'order_audit'; IF v_enabled = 1 THEN ... END IF; - 必须给
trigger_config加唯一索引（主键即可），否则SELECT INTO可能报错或返回多行 - 不要用
SELECT @enabled := enabled FROM ...——变量作用域混乱，高并发下值不可信；始终用DECLARE + SELECT INTO - 该方式有轻微性能开销（每次 DML 多一次主键查询），但比硬编码或停用触发器更可控；若对延迟极度敏感，可考虑用应用层开关替代
UPDATE 触发器中 OLD/NEW 字段访问的边界问题
触发器里看似能自由访问 OLD 和 NEW，但实际受语句类型严格限制：在 INSERT 触发器中读 OLD 会报错，在 DELETE 中读 NEW 同样不行。而 UPDATE 是唯一能同时访问两者的场景，但仍有陷阱。
常见错误现象：Unknown column 'OLD.updated_at' in 'field list'，其实是因为该字段在表定义中允许为 NULL，但触发器里没判空就直接参与计算；或字段名拼错（比如把 created_at 写成 create_at）。
-
OLD和NEW是只读别名，不能赋值（SET OLD.id = 123语法错误） - 字段变更检测慎用
!=：当字段类型是VARCHAR且含前导空格、或 collation 不同，OLD.name != NEW.name可能误判；优先用NOT (OLD.name NEW.name) - 对
JSON字段做变更判断需额外函数，如JSON_CONTAINS_PATH(NEW.data, 'one', '$.user_id')，不能直接OLD.data != NEW.data（MySQL 5.7+ 对 JSON 比较行为特殊）
