MySQL IF NOT排除条件超3个时触发器不触发问题咨询

这不是MySQL的固有功能限制，属于代码写法问题。核心触发原因是空值判断逻辑错误，叠加判断逻辑不符合追踪需求，才会出现排除判断条件超过3个时触发器停止触发的现象。

• 空值判断逻辑不兼容NULL场景：MySQL中<>运算符无法正确处理NULL值。当比较的两边任意一边为NULL时，a <> b的返回结果不是布尔值FALSE/TRUE，而是NULL。在IF判断中NULL会被当做FALSE处理。你新增的第四个判断字段只要存在NULL值（无论NEW侧、OLD侧单侧为NULL，或是两侧均为NULL），整个OR表达式的计算结果就会偏离预期，最终导致IF条件不成立，触发器内的记录逻辑不执行。你添加的排除列越多，测试时碰到字段含NULL的概率越高，就会表现为“超过3个条件就失效”的现象。
• 判断逻辑存在设计缺陷：你当前的判断规则是IF NOT (任意排除列被修改)，等价于「只要任意一个排除列被修改，就不记录日志」，这和你预期的「仅当修改的列全是排除列时才不记录」完全不符。如果一次更新同时修改了排除列和需要追踪的业务列，现有逻辑会直接跳过记录，导致日志漏记。这个问题和条件数量无关，从你写3个以内排除条件的时候就已经存在，只是之前测试时没有碰到同时修改两类列的场景。

• 替换NULL不安全的比较运算符：判断列值是否发生变化时，使用MySQL提供的NULL安全等值运算符<=>，判断列值不同写为NOT (NEW.col <=> OLD.col)，可以兼容字段为NULL的场景，排除列可以任意新增，没有数量限制。
• 调整判断逻辑：如果要实现“仅当所有修改都集中在排除列时才跳过记录”，不要通过判断排除列是否被修改来决定是否记录，应该反过来判断「是否存在需要追踪的业务列被修改」，只要有任意一个业务列发生变更就记录日志，从根源上避免漏记。

修复NULL问题后的触发器参考代码 #

DROP TRIGGER IF EXISTS sample_table_log_update;
DELIMITER |
CREATE TRIGGER sample_table_log_update 
BEFORE UPDATE ON `sample_table`
FOR EACH ROW
BEGIN
    -- 注意：当前逻辑仅解决了NULL判断问题，仍存在“同时修改排除列和业务列时漏记”的缺陷
    -- 生产环境建议替换为判断业务列是否变更的逻辑
    IF NOT (
        NOT (NEW.excluded <=> OLD.excluded)
        OR NOT (NEW.reserved <=> OLD.reserved)
        OR NOT (NEW.healthy <=> OLD.healthy)
        OR NOT (NEW.router <=> OLD.router)
    ) THEN
        DECLARE original_query VARCHAR(1024);
        SET original_query = (SELECT info FROM INFORMATION_SCHEMA.PROCESSLIST WHERE id = CONNECTION_ID());
        INSERT INTO `ChangesTracker`(
            `table_name`, `timestamp`, `operation`, 
            `tracking_query`, `tracking_user_id`, `uuid`
        ) VALUES (
            'sample_table', CURRENT_TIMESTAMP, 'Update', 
            original_query, CURRENT_USER, old.uuid
        );
    END IF;
END
|
DELIMITER ;

补充说明：通过INFORMATION_SCHEMA.PROCESSLIST获取执行SQL的方式可靠性较低，长度超过系统配置performance_schema_max_sql_text_length的SQL会被截断，连接处于空闲状态时也无法获取到对应语句。如果需要完整可靠的变更审计，优先使用审计插件或binlog解析方案。

内容的提问来源于stack exchange，提问作者Eric Winkelbauer