触发器中用 = 比较 NULL 会静默失效，应优先使用 IS NULL / IS NOT NULL 显式判断；多值判断需拆分处理；检测字段变更推荐用 操作符；UPDATE 触发器中防变量残留须主动初始化或用 COALESCE。
触发器里用 = 比较 NULL 会静默失效
在 BEFORE INSERT 或 BEFORE UPDATE 触发器中，直接写 IF NEW.col = 'value' 是危险的——如果 col 是 NULL，整个条件不成立，既不是 TRUE 也不是 FALSE，而是 UNKNOWN，结果就是分支被跳过，连日志都看不到报错。
常见现象包括：
- 本该拦截空邮箱的校验逻辑没生效
-
SET NEW.status = UPPER(NEW.status)对NULL无害，但换成CONCAT('U-', NEW.status)就变成'U-'，悄悄污染数据 - 用
IN判断状态时，IF NEW.status IN ('active', 'pending')遇到NULL直接跳过，后续没兜底就留空
用 IS NULL / IS NOT NULL 显式判断最可靠
触发器里处理可能为 NULL 的字段，优先用标准布尔判断，而不是依赖函数包装或等值比较。
正确写法示例：
IF NEW.phone IS NOT NULL AND NEW.phone != '' THEN SET NEW.phone = TRIM(NEW.phone); END IF;
关键点：
-
IS NULL和IS NOT NULL能走索引（B-tree 支持），且语义清晰、无隐式转换风险 - 不要把多个逻辑塞进一个
IF条件里，比如IF NEW.name = 'admin' OR NEW.name IS NULL—— 这种混合写法容易漏掉边界情况 - 对多值判断，拆成嵌套或并列判断：
IF NEW.status IS NOT NULL THEN ... ELSEIF NEW.status IS NULL THEN ... END IF;
需要值比较时，优先用 而非 IFNULL()
当业务逻辑确实要“把 NULL 当普通值参与相等性判断”（比如同步字段是否变化）， 比 IFNULL() 更安全、更轻量。
例如检测字段是否被修改：
IF NOT OLD.email NEW.email THEN INSERT INTO audit_log (...) VALUES (...); END IF;
对比错误做法：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
IF IFNULL(OLD.email, '') != IFNULL(NEW.email, '')：类型不一致时触发隐式转换，字符串字段和空字符串比还行，但日期或数字字段可能出错 -
IF (OLD.email != NEW.email) OR (OLD.email IS NULL) OR (NEW.email IS NULL)：冗长且易漏条件，一行就覆盖全部 NULL 组合
是 MySQL 原生操作符，不引入函数调用开销，也不影响执行计划。
UPDATE 类型触发器要防变量残留
BEFORE UPDATE 中若用 SELECT ... INTO @var 查关联数据，查不到时 @var 不会变 NULL，而是保持上次值——这在循环或多次触发场景下极易导致脏数据传递。
必须主动初始化：
SET @ref_name = NULL; SELECT name INTO @ref_name FROM users WHERE id = NEW.user_id;
或者更稳妥地用子查询 + COALESCE：
SET NEW.display_name = COALESCE( (SELECT name FROM users WHERE id = NEW.user_id), 'Unknown' );
注意：COALESCE 在这里比 IFNULL 更合适，因为子查询本身可能返回 NULL，而 COALESCE 支持多参数 fallback，语义也更贴近“取第一个有效值”的意图。
真正难处理的不是 NULL 本身，而是它在触发器里不报错、不中断、只默默跳过逻辑——所有判断都要预设“这个值可能是 NULL”，而不是等它出问题再补。
