after delete触发器不适合删关联缓存表，因存在三限制：外键约束报错、不参与事务回滚、可能引发嵌套死循环；无外键时虽可用但需索引、存在性校验及避免跨表操作；推荐应用层事务统一处理，或权宜使用before delete+innodb+索引。
为什么AFTER DELETE触发器不适合删关联缓存表
直接在 AFTER DELETE 触发器里执行 DELETE FROM cache_table WHERE ref_id = OLD.id 看似可行，但会面临三个硬性限制：一是 MySQL 5.7+ 默认禁止在触发器中修改被外键约束的表（哪怕只是缓存表），报错 Can't update table 'cache_table' in stored function/trigger...；二是该操作不参与外层事务回滚——父表删除失败回滚后，缓存记录已永久丢失；三是若缓存表本身也定义了 AFTER DELETE 触发器，可能引发嵌套调用甚至死循环。
缓存表没外键时，AFTER DELETE能用但必须加防护
如果 cache_table 和主表之间纯属逻辑关联、无外键约束，AFTER DELETE 触发器可以执行，但需满足以下条件：
- 子表必须有索引支撑
WHERE ref_id = OLD.id，否则全表扫描拖慢主删操作 - 触发器内必须先
SELECT COUNT(*) FROM cache_table WHERE ref_id = OLD.id验证存在性，避免误删（比如触发器被批量脚本非预期调用） - 不能依赖
OLD字段做跨表关联以外的操作，例如UPDATE users SET last_cache_clean = NOW() WHERE id = OLD.user_id会触发递归报错 - 若缓存表是 MyISAM 引擎，删失败不会回滚，得靠应用层定时巡检补删
更稳妥的做法：把缓存清理移到应用层事务中
真正可控、可回滚、易监控的方式，是放弃触发器，改由应用代码在同一个事务里完成：
- 先
DELETE FROM main_table WHERE id = ? - 再
DELETE FROM cache_table WHERE ref_id = ? - 最后
COMMIT或ROLLBACK
这样缓存清理和主数据删除共享同一事务上下文，原子性强；出错时 DBA 可直接查 binlog 定位哪一步卡住；还能在删前加日志、打监控埋点、或对大缓存分页删（比如 LIMIT 1000）避免锁表太久。
真要用触发器，优先选 BEFORE DELETE + 显式事务控制
如果业务强依赖数据库端自动清理（如遗留系统无法改应用），唯一较稳路径是：
- 用
BEFORE DELETE触发器，确保缓存删在主记录消失前 - 缓存表必须是 InnoDB，否则无事务保障
- 触发器内只做
DELETE FROM cache_table WHERE ref_id = OLD.id，不涉及任何其他表或函数调用 - 务必确认
cache_table.ref_id有索引，否则SHOW CREATE TABLE cache_table会暴露缺失
注意：这仍是权宜之计。一旦缓存表需要二级联动（比如删缓存后还要清 Redis），触发器就彻底无能为力——那部分逻辑只能交还给应用层。
