MySQL触发器不能实现按需归档老数据，因其仅响应INSERT/UPDATE/DELETE事件，无法主动扫描时间条件或批量迁移；定时归档须依赖EVENT或应用层任务，并需分批处理、建索引、避免锁表。
MySQL触发器不能实现“按需归档老数据”——它压根不支持基于时间条件的主动扫描和批量迁移。所谓“按需”，如果是指“当某条记录满足 created_at
为什么触发器不适合做老数据归档
触发器只响应三类语句：INSERT、UPDATE、DELETE。它不会主动查表、不会遍历历史数据、也不会定时醒来干活。你无法在触发器里写 SELECT * FROM orders WHERE created_at 然后批量插入归档表——这违反执行模型，会报错或静默失败。
- 试图在
AFTER DELETE中归档被删行？可以，但只能处理“刚删的那一行”，不是“所有超期的老数据” - 在
BEFORE INSERT里检查新数据是否该归档？没意义，新数据显然不老 - 用
UPDATE触发器去轮询旧记录？不行，UPDATE 不会自动发生，没人调它就不会执行 - 最危险的做法：在触发器里调用存储过程，再让过程去扫全表归档——这会导致主表写入卡死、锁等待、事务超时
真正能“按需归档老数据”的只有 EVENT 或应用层任务
如果你需要的是“每天凌晨把 90 天前的订单挪到 orders_archive”，必须用外部驱动机制：
-
EVENT是 MySQL 原生方案，适合轻量场景：先确认SHOW VARIABLES LIKE 'event_scheduler'返回ON，再建事件调用存储过程 - 应用层脚本（Python/Shell）+
cron更可控：能加重试、限流、监控、跨库协调，还能在归档前校验关联状态 - 别把 EVENT 当万能药：它默认以
DEFINER用户权限运行，若该用户对归档表无INSERT权限，归档会静默失败——务必用SELECT * FROM information_schema.EVENTS查LAST_EXECUTED和LAST_ERROR
如果非要从触发器“借力”，只能做轻量标记
触发器唯一靠谱的归档辅助角色，是快速落一条轻量日志，把归档任务“排队”出去：
- 在
BEFORE DELETE中往archive_queue表插一行：INSERT INTO archive_queue (table_name, pk_id, archived_at) VALUES ('orders', OLD.id, NOW()) - 注意用
BEFORE而非AFTER：确保OLD字段完整可读，尤其含TEXT、JSON字段时 -
archive_queue表要建好索引（如(table_name, archived_at)），供后续定时任务高效消费 - 真正的归档动作由外部脚本完成：
SELECT * FROM archive_queue WHERE processed = 0 LIMIT 1000→ 分批INSERT IGNORE INTO orders_archive SELECT * FROM orders WHERE id = ?→ 标记为已处理
归档 SQL 本身容易踩的坑
哪怕驱动机制选对了，归档语句写错照样翻车：
- 别写
DELETE FROM orders WHERE created_at 之后再 <code>INSERT INTO ... SELECT：顺序反了，数据就丢了；必须先INSERT成功，再DELETE - 避免
INSERT ... SELECT ... WHERE NOT EXISTS (SELECT 1 FROM archive_table)：每次插入都全表扫归档表，百万级就卡死；改用INSERT IGNORE或ON DUPLICATE KEY UPDATE，前提是归档表有唯一键（如UNIQUE KEY (id)） - 分批必须用主键范围，别依赖
LIMIT：WHERE id BETWEEN 100000 AND 100999 AND created_at 比 <code>LIMIT 1000更稳定，不会漏数据 - 归档前先建索引：
CREATE INDEX idx_orders_created ON orders(created_at)，否则每次归档都在全表扫描
归档不是写个触发器点一下就完事的事。核心矛盾在于：触发器是“被动响应”，而老数据归档是“主动扫描”。强行把后者塞进前者，就像让门铃自己去翻抽屉找过期文件——它没这个功能，也不该有。
