触发器中禁止大数据量INSERT...SELECT归档，须异步化；AFTER DELETE无法读取完整OLD字段，应改用BEFORE DELETE；归档表字段类型须与主表严格一致；调用存储过程需显式授权EXECUTE权限。
触发器里不能用 INSERT ... SELECT 往归档表写大数据量
MySQL 触发器执行时处于原事务上下文中，如果在 BEFORE INSERT 或 AFTER INSERT 里直接对大表做 INSERT INTO archive_table SELECT * FROM main_table WHERE ...，极易触发锁等待、超时甚至死锁。更麻烦的是，归档逻辑本身会拖慢主表写入，违背“归档不该影响业务”的前提。
- 归档动作必须异步化，触发器只负责标记或落简单日志（比如往
archive_queue表插一条table_name、min_id、max_id记录） - 真正归档由外部定时任务（如
mysqldump+LOAD DATA INFILE，或 Python 脚本分批SELECT ... LIMIT+INSERT IGNORE）完成 - 若坚持在触发器内操作，仅限单行小数据：比如只把刚插入的
id和created_at写进log_archive_buffer表，后续再批量消费
AFTER DELETE 触发器里读不到被删行的完整字段
MySQL 的 AFTER DELETE 触发器中，OLD 只保留能用于条件判断的字段值，但某些场景下（比如字段含 JSON、TEXT、或启用了 innodb_strict_mode），OLD.column_name 可能返回 NULL 或截断内容——不是 bug，是 InnoDB 在删除阶段已释放部分内存结构。
- 必须归档整行数据时，改用
BEFORE DELETE触发器，此时OLD完整可用 - 避免在
AFTER DELETE中对OLD做复杂计算或拼接，尤其别依赖OLD.json_col->"$.field" - 归档前先检查：
SELECT OLD.id, OLD.content IS NOT NULL, LENGTH(OLD.content) FROM DUAL;确认字段可读性
归档表字段类型不匹配导致触发器静默失败
常见错误是归档表用 VARCHAR(255) 接主表的 TEXT 字段，或用 DATETIME 接带毫秒的 TIMESTAMP(6)。触发器执行时不会报错，但数据被截断或转成 0000-00-00 00:00:00，日志看起来“成功”了，实际丢数据。
- 归档表字段定义必须和主表严格一致：包括类型、长度、是否允许
NULL、字符集、排序规则 - 用
SHOW CREATE TABLE main_table对比SHOW CREATE TABLE archive_table，逐字段核对CREATE语句输出 - 特别注意
TINYINT(1)和布尔语义、ENUM值列表顺序、SET成员是否完全相同
触发器调用存储过程归档时权限不足
触发器内调用 CALL archive_procedure() 是常见做法，但 MySQL 默认禁止触发器调用需要额外权限的存储过程。即使你用 root 创建了过程，触发器以当前连接用户权限运行，而该用户往往没被显式授予 EXECUTE 权限。
- 显式授权：
GRANT EXECUTE ON PROCEDURE db.archive_procedure TO 'app_user'@'%'; - 存储过程内部若涉及跨库操作（如写到
log_db.archive_log），还需对应库级权限：GRANT INSERT ON log_db.* TO 'app_user'@'%'; - 测试方法：用业务账号登录，手动执行
CALL archive_procedure();，确认无ERROR 1370 (42000): execute command denied
归档逻辑越靠近业务写入路径，就越容易因权限、锁、字段兼容性这些细节崩掉。真要稳，触发器只做轻量标记，重活交给独立进程——这点很多人一开始不愿接受，但线上跑三个月后基本都切过去了。
