DELETE触发器中不可用NEW，仅OLD可用且只读；INSERT/UPDATE触发器中禁止直接修改本表，仅BEFORE中SET NEW字段合法，AFTER中操作本表必报ERROR 1442。
触发器里不能直接用 DELETE + 子查询引用新插入的表
想在 INSERT 触发器里删掉过期记录，最常见错误是写成：
DELETE FROM history_table WHERE created_at < DATE_SUB(NOW(), INTERVAL 7 DAY) AND user_id = NEW.user_id;表面看没问题，但 MySQL 会报错
Can't update table 'history_table' in stored function/trigger because it is already used by statement which invoked this stored function/trigger。这是因为触发器正在操作 history_table（INSERT），又试图在同一个语句上下文中 DELETE 它——MySQL 明确禁止这种“对同一张表的读写并发操作”。
改用 AFTER INSERT + 独立 DELETE 语句（需确保隔离性）
必须把清理逻辑放到 AFTER INSERT 触发器中，并且 DELETE 不能依赖 NEW 的字段做子查询关联（避免隐式读表）。实际可行做法是：先用变量暂存关键值，再执行 DELETE。例如：
DELIMITER $$
CREATE TRIGGER clean_expired_after_insert
AFTER INSERT ON history_table
FOR EACH ROW
BEGIN
DECLARE v_user_id BIGINT DEFAULT NEW.user_id;
DELETE FROM history_table
WHERE user_id = v_user_id
AND created_at < DATE_SUB(NOW(), INTERVAL 7 DAY);
END$$
DELIMITER ;
- 必须用
AFTER INSERT，不能是BEFORE，否则NEW可能未持久化，且无法保证 DELETE 执行时机 -
v_user_id是必须的中间变量，绕过 MySQL 对NEW.user_id在 DELETE WHERE 中直接引用的限制 - 如果历史表数据量大，这个 DELETE 可能锁表或变慢，建议在
user_id和created_at上建联合索引：INDEX idx_user_time (user_id, created_at)
更稳妥的做法：用事件调度器（EVENT）替代触发器清理
触发器内做 DELETE 本质是把业务逻辑和数据变更耦合太紧，容易拖慢插入性能，也难监控失败。生产环境更推荐分离职责：
- 触发器只负责标记或记录清理需求（比如往
cleanup_queue表插一条user_id） - 用 MySQL
EVENT每分钟跑一次批量清理：CREATE EVENT ev_clean_expired_history ON SCHEDULE EVERY 1 MINUTE DO DELETE FROM history_table WHERE created_at < DATE_SUB(NOW(), INTERVAL 7 DAY) LIMIT 1000;
-
LIMIT 1000很关键，防止单次 DELETE 锁太久；可配合ROW_COUNT()判断是否还有剩余，循环执行 - 需要先开启事件调度器：
SET GLOBAL event_scheduler = ON;
注意事务边界与错误处理缺失问题
MySQL 触发器默认在父语句事务中执行，DELETE 失败会导致整个 INSERT 回滚——这未必是你想要的。比如清理失败不应让新数据插不进去。但触发器本身不支持 TRY...CATCH 或忽略错误。所以：
- 不要在触发器里做可能失败的复杂操作（如跨库 DELETE、调用存储过程）
- 如果必须强一致性清理，应把 INSERT 和 DELETE 封装进一个存储过程中统一控制事务
- 所有基于时间的判断（如
NOW()）在复制环境下要注意主从时钟偏差，建议用SYSDATE()并确保 NTP 同步
真正难的不是写那几行 DELETE，而是想清楚：清理动作到底该由谁负责、失败了怎么兜底、数据量上涨后会不会突然卡住写入。这些比语法细节更容易被忽略。
