不能在 BEFORE UPDATE 触发器中计算整行哈希用于防篡改拦截，因 NEW.* 在 BEFORE 中只读且 CONCAT 遇 NULL 返回 NULL 导致 SHA2 失效；可靠方案是用 SET NEW.col = OLD.col 锁定字段、SIGNAL 显式拒绝，或用 GENERATED COLUMN + CHECK 实现完整性校验。
不能在 BEFORE UPDATE 触发器里直接计算整行哈希并用于防篡改拦截。这不是语法限制或版本问题，而是 MySQL 触发器模型本身的设计约束：NEW.* 在 BEFORE 中只读，且 CONCAT(NEW.col1, NEW.col2, ...) + SHA2() 组合在多数场景下会触发 ERROR 1362 或隐式返回 NULL，根本不可靠。
BEFORE UPDATE 里调用 SHA2(CONCAT(NEW.*)) 为什么总报错
常见错误现象是写类似 SET @h = SHA2(CONCAT(NEW.id, NEW.name, NEW.email), 256) 后触发器创建失败，或运行时报 ERROR 1362: Updating of NEW row is not allowed in after trigger（即使写在 BEFORE 里也会误报）。原因有二：
- MySQL 解析器在 BEFORE 触发器中对多字段
NEW.*的深度引用做表达式求值时，内部会尝试“模拟写入”行为，从而触发只读保护 -
CONCAT()遇到任一字段为NULL时整个结果为NULL，导致SHA2(NULL, 256)返回NULL，后续比对失效且无提示 - 即便绕过报错，这种哈希也无法用于“阻止篡改”——你无法在 BEFORE 里用哈希结果决定是否跳过更新，因为没有
SIGNAL之外的中断机制
真正能落地的防篡改方案只有两种
想锁死某些字段不被修改，别碰哈希。直接用语义明确、事务安全的方式：
- 对必须锁定的字段（如
created_at、balance），在 BEFORE UPDATE 里写SET NEW.created_at = OLD.created_at—— 静默还原，零开销 - 若需显式拒绝，用
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'created_at is immutable'—— 立即回滚，客户端可见错误 - PostgreSQL 用户注意：需在 PL/pgSQL 函数中
RETURN OLD实现等效逻辑，MySQL 不支持该写法
如果非要存行哈希，GENERATED COLUMN + CHECK 才是正解
把哈希当作数据完整性断言，而不是运行时拦截手段。MySQL 8.0.16+ 支持如下组合：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
ALTER TABLE users
ADD COLUMN row_hash CHAR(64) AS (
SHA2(CONCAT(
COALESCE(id, ''),
COALESCE(name, ''),
COALESCE(email, ''),
COALESCE(updated_at, '')
), 256)
) STORED,
ADD CONSTRAINT chk_row_hash_valid CHECK (
row_hash = SHA2(CONCAT(
COALESCE(id, ''),
COALESCE(name, ''),
COALESCE(email, ''),
COALESCE(updated_at, '')
), 256)
);关键点：
-
STORED列确保每次 INSERT/UPDATE 都实时计算，CHECK 约束在语句级校验，失败则整个 DML 回滚 - 必须用
COALESCE(col, '')替代裸字段，否则任意NULL都让CONCAT返回NULL - 该方案不依赖触发器，无额外执行开销，且能被
EXPLAIN和优化器识别
AFTER 触发器唯一合理用途：审计比对
行哈希真正的价值在于事后追溯。在 AFTER UPDATE 中写审计表，记录变更前后哈希：
INSERT INTO audit_log (table_name, row_id, old_hash, new_hash, updated_at) VALUES ( 'users', OLD.id, SHA2(CONCAT(COALESCE(OLD.id,''), COALESCE(OLD.name,'')), 256), SHA2(CONCAT(COALESCE(NEW.id,''), COALESCE(NEW.name,'')), 256), NOW() );
注意：
- 这里用
OLD.*和NEW.*是安全的，AFTER 触发器允许只读访问 - 不要试图在 AFTER 里做校验并回滚——事务已提交，无法撤回
- 审计表应单独建索引（如
(table_name, row_id, updated_at)），避免拖慢主业务
哈希不是防篡改的开关，而是数据指纹的快照。真要防，就用 SET NEW.x = OLD.x 或 SIGNAL；真要存，就用 GENERATED COLUMN + CHECK；真要用哈希做审计，就只在 AFTER 里写日志——混用场景、硬塞进 BEFORE、忽略 NULL 处理，这三类操作最容易出 silent failure。
