MySQL 必须用 BEFORE DELETE 触发器清理子表，AFTER 会因 ERROR 1442 失败；PostgreSQL 和 SQL Server 更推荐外键 ON DELETE CASCADE 或 INSTEAD OF 触发器，避免手动逻辑踩坑、难维护。
可以，但必须用 BEFORE DELETE，且仅限于 MySQL 中需手动补逻辑的场景；PostgreSQL 和 SQL Server 更推荐用外键 ON DELETE CASCADE 或 INSTEAD OF 触发器——不是不能做，而是容易踩坑、难维护。
MySQL 必须用 BEFORE DELETE，AFTER 会报 ERROR 1442
MySQL 在 AFTER DELETE 触发器里禁止对原表做任何读写操作（包括 SELECT 或 JOIN），否则直接抛出 ERROR 1442 (HY000)。因为行已物理删除，OLD.id 虽然还能访问，但无法安全定位子表关联数据（尤其当子表字段类型不一致时可能漏删）。
-
BEFORE DELETE才能可靠拿到OLD.id，并执行DELETE FROM child WHERE parent_id = OLD.id - 必须加
DELIMITER $$包裹触发器体，否则分号会让 MySQL 提前结束语句 - 触发器内不能写
COMMIT或START TRANSACTION，MySQL 不允许显式事务控制 - 如果子表已有外键
ON DELETE CASCADE，就根本不需要这个触发器——先查约束是否存在
PostgreSQL 优先用外键 CASCADE，触发器只用于复杂逻辑
PostgreSQL 原生支持 ON DELETE CASCADE，性能好、原子性强、可预测。触发器（如 BEFORE DELETE + 函数）只应在需要条件判断、日志记录或跨 schema 清理时才介入。
- 建外键必须显式写
ON DELETE CASCADE，光有REFERENCES不生效 - 若子表数据已存在，添加约束前要确保所有
parent_id都指向真实父记录，否则ADD CONSTRAINT会失败并提示violates foreign key constraint - 级联深度无硬限制，但嵌套超 3 层（如 A→B→C→D）时，
DELETE FROM A可能锁表数秒，需评估业务容忍度
SQL Server 的 INSTEAD OF 触发器必须手动删父表
SQL Server 的 INSTEAD OF DELETE 会完全接管删除动作，但有个致命陷阱：它不会自动删父表本身——你得在触发器里显式写 DELETE FROM parent_table WHERE id IN (SELECT id FROM deleted)，否则看起来“级联”了，其实父表还在。
-
deleted是只读临时表，仅在触发器内可见，存着本次将被删的行 - 若子表也有
INSTEAD OF触发器，需确认是否开启嵌套触发器：sp_configure 'nested triggers', 1 - 多个子表清理建议用
JOIN或分步DELETE，避免单条语句锁表太久
真正麻烦的不是写法，而是递归调用和隐式类型转换——比如主表 id 是 BIGINT UNSIGNED，子表 parent_id 是 INT，MySQL 会隐式转成有符号整型，导致索引失效、漏删；又或者父子表双向外键，触发器一触发就死循环。这些细节不跑通测试根本看不出来。
