不能直接在AFTER DELETE触发器中删除关联表记录，因MySQL 5.7+默认禁止递归访问外键关联表，会报“Can't update table”错误；唯一安全高效方案是使用外键ON DELETE CASCADE，由引擎原生保障原子性与一致性。
触发器里不能直接删关联表的记录？
不是不能，而是 MySQL 5.7+ 默认禁止在 AFTER DELETE 触发器中修改（包括 DELETE）**同一张表**或其外键关联的表——这会触发 “Can’t update table ‘xxx’ in stored function/trigger because it is already used by statement which invoked this stored function/trigger” 错误。关键点在于：触发器执行时，原表仍处于语句上下文中，MySQL 认为这是“递归访问”，直接拦掉。
常见错误写法：
CREATE TRIGGER tr_after_delete_user AFTER DELETE ON users FOR EACH ROW DELETE FROM orders WHERE user_id = OLD.id;
这段代码在大多数 MySQL 配置下会报错，哪怕 orders 是另一张表——只要它和 users 存在外键约束（尤其 ON DELETE RESTRICT 或未显式设为 NO ACTION），MySQL 就可能拒绝执行。
真正能用的替代方案：用 BEFORE DELETE + 外键级联
想让删除用户时自动清空订单，最稳、最符合 MySQL 设计哲学的方式是放弃触发器，改用外键的 ON DELETE CASCADE。它由存储引擎原生支持，原子、高效、无需额外逻辑。
操作步骤：
- 确认
orders.user_id是外键，且引用users(id) - 如果还没建外键，先删掉旧索引（如有），再重建带级联的外键：
ALTER TABLE orders DROP FOREIGN KEY fk_orders_user_id; ALTER TABLE orders ADD CONSTRAINT fk_orders_user_id FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE;
之后执行 DELETE FROM users WHERE id = 123;，orders 中对应记录会自动消失，无触发器、无报错、无事务风险。
注意：ON DELETE CASCADE 对性能有隐含影响——大表批量删主表记录时，MySQL 会逐行扫描并删子表，可能锁表较久；若子表无 user_id 索引，还会全表扫描，务必检查 SHOW CREATE TABLE orders; 确认索引存在。
非用触发器不可？那只能选 BEFORE DELETE + INSERT INTO … SELECT
极少数场景（比如要清理多层关联、或需条件过滤、或外键被禁用），才考虑触发器。此时必须用 BEFORE DELETE，且不能直接 DELETE 关联表，而得把待删 ID 暂存到临时表或内存表，再在触发器外处理——但 MySQL 触发器不支持事务控制外的异步动作，所以更现实的做法是：用 BEFORE DELETE 把 ID 写入一张轻量日志表，再由外部定时任务清理。
最小可行示例（仅作示意，生产慎用）：
CREATE TABLE delete_log (
table_name VARCHAR(64),
pk_value BIGINT,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
DELIMITER $$
CREATE TRIGGER tr_before_delete_user
BEFORE DELETE ON users
FOR EACH ROW
BEGIN
INSERT INTO delete_log(table_name, pk_value) VALUES ('users', OLD.id);
END$$
DELIMITER ;
然后另起一个脚本（如 Python 或 Shell）定期查 delete_log，执行 DELETE FROM orders WHERE user_id IN (SELECT pk_value FROM delete_log WHERE table_name = 'users');，再清空日志。这样绕开了触发器限制，但也引入了延迟和运维复杂度。
为什么不用存储过程封装 DELETE + 关联清理？
有人会想：写个存储过程，里面先 DELETE FROM orders，再 DELETE FROM users，不就绕开了？可以，但要注意两点：
- 调用者必须显式开启事务（
BEGIN; CALL cleanup_user(123); COMMIT;），否则任一语句失败会导致数据不一致 - 该过程无法被 ORM 自动识别，所有删除操作都得走这个入口，容易遗漏
- 若
orders表很大，DELETE可能锁表几十秒，阻塞其他读写，而外键级联同样有这问题，但至少是声明式的、可预期的
真正难处理的从来不是“怎么删”，而是“删的时候别人正在读写关联数据”。外键级联和显式事务都能保证一致性，但前者更轻量、后者更可控——选哪个，取决于你对运维透明度和故障恢复速度的要求。
触发器自动清理听着省事，实际埋的坑比写的代码还多；真要自动化，优先配好外键，再配好索引，剩下的交给 MySQL 自己算。
