MySQL触发器无法自动完成历史数据归档，仅能单行捕获快照，归档动作需显式编写、结构严格对齐，否则易因锁或类型不匹配导致静默失败。
MySQL触发器不能自动完成“历史数据归档”，它只能在单行变更时帮你捕获快照，但归档动作本身必须显式写入、结构严格对齐、且极易因锁或类型不匹配导致静默失败。
BEFORE UPDATE / DELETE 才能拿到完整 OLD 数据
想归档变更前的整行数据，必须用 BEFORE UPDATE 或 BEFORE DELETE 触发器。AFTER 触发器里的 OLD 在 MySQL 中已不可靠——尤其含 JSON、TEXT 或启用了 innodb_strict_mode 时，字段可能为 NULL 或被截断。
实操建议：
- 用
SELECT OLD.id, OLD.content IS NOT NULL, LENGTH(OLD.content) FROM DUAL在触发器里快速验证关键字段是否可读 - 避免在触发器里拼接
OLD.json_col->"$.field"，改用JSON_EXTRACT(OLD.json_col, "$.field")更稳妥 - DELETE 场景下，如果业务允许软删（加
is_deleted字段），反而比硬删 + BEFORE DELETE 更可控
归档表结构必须和主表字段级一致
哪怕只差一个字符集或 TINYINT(1) 和 BOOLEAN 的语义差异，插入都会静默截断或转成默认值（如 0000-00-00 00:00:00），日志看起来成功，实际丢数据。
实操建议：
- 建归档表优先用
CREATE TABLE orders_archive LIKE orders，再手动调整主键和新增字段 - 主表有自增
id，归档表对应字段必须改为普通INT NOT NULL，否则INSERT INTO ... SELECT OLD.*会冲突 - 追加
archived_at DATETIME字段时，别依赖DEFAULT CURRENT_TIMESTAMP，应在触发器里显式赋值：archived_at = NOW() - 用
SHOW CREATE TABLE orders和SHOW CREATE TABLE orders_archive逐字段比对，重点关注CHARACTER SET、COLLATE、ENUM值顺序、JSON类型声明
触发器内禁止 INSERT SELECT 批量归档
在触发器里写 INSERT INTO archive_table SELECT * FROM main_table WHERE ... 是高危操作：它会锁住被查表、拖慢主表写入、甚至引发死锁。触发器本就运行在主事务上下文中，没有独立事务控制能力。
实操建议：
- 归档逻辑必须限于单行：只插
OLD.*或NEW.*，且目标表与主表同库同实例 - 如果要归档关联数据（比如订单+订单项），不要在触发器里连表查，改用应用层异步补全
- 高并发更新场景下，
BEFORE UPDATE插入归档表会延长原表行锁持有时间，观察INFORMATION_SCHEMA.INNODB_TRX中的TRX_ROWS_LOCKED是否异常增长 - 归档表务必在
archived_at和原主键（如order_id）上建联合索引，否则后续按时间范围查历史会全表扫
UPDATE 触发器必须用 NULL 安全比较
判断字段是否真变了，不能写 IF OLD.status != NEW.status THEN。只要任意一边是 NULL，整个表达式结果就是 NULL（逻辑假），导致归档被跳过。
实操建议：
- 统一用
NOT (OLD.status NEW.status)，这是 MySQL 原生的 NULL 安全等于运算符 - 只监控关键字段变动，比如只对
status、amount、updated_by做归档，别无脑比对所有字段 - 归档表加
change_type ENUM('INSERT','UPDATE','DELETE')字段，方便后续快速筛选归档来源 - 如果主表有大文本字段（如
TEXT），考虑在触发器里只存摘要（SUBSTR(OLD.content, 1, 200)）或哈希（SHA2(OLD.content, 256)），避免 I/O 拖累
最常被忽略的一点：触发器里插入归档表失败，默认不会回滚主表操作。MySQL 不会自动中止 UPDATE 或 DELETE，你得手动检查 ROW_COUNT() 并用 SIGNAL 抛异常，否则就是“删了没归档”——数据静默丢失。
