能做但不推荐：MySQL中AFTER DELETE触发器可实现级联删除，但易掩盖外键语义、引发递归调用或删不净；PostgreSQL用ON DELETE CASCADE更稳妥；SQL Server需注意INSTEAD OF中手动删父表。
MySQL 中用 AFTER DELETE 触发器做级联删除
直接说结论：能做，但不推荐作为主方案。触发器级联删除容易掩盖外键约束语义，且事务异常时难排查。
常见错误现象是子表记录没删干净，或触发器递归调用导致 Stack overflow（尤其在父子双向关联场景）。
- 必须显式声明
DELIMITER $$，否则 MySQL 会把分号当成语句结束，提前报错 - 触发器里不能对原表执行
DELETE（即不能删触发它的那张表），否则报Can't update table 'xxx' in stored function/trigger - 若子表有多个外键指向父表，得在触发器里分别处理，不能只写一个
DELETE FROM child WHERE parent_id = OLD.id
示例（父表 orders，子表 order_items）：
DELIMITER $$ CREATE TRIGGER delete_order_items_after_order AFTER DELETE ON orders FOR EACH ROW BEGIN DELETE FROM order_items WHERE order_id = OLD.id; END$$ DELIMITER ;
PostgreSQL 用 ON DELETE CASCADE 更稳妥
PostgreSQL 原生支持外键级联，比触发器更可靠、性能更好，也符合 ACID。
容易踩的坑是建表时漏加 CASCADE，或者误用 SET NULL 导致数据逻辑断裂。
- 外键定义必须带
ON DELETE CASCADE，仅建索引或普通外键无效 - 如果子表已有数据，先确保
parent_id都合法，否则ADD CONSTRAINT会失败并提示insert or update on table "xxx" violates foreign key constraint - 级联深度无硬限制，但嵌套超过 3 层（如 A→B→C→D）时，
DELETE FROM A可能锁表时间明显变长
建表时写法：
ALTER TABLE order_items ADD CONSTRAINT fk_order_id FOREIGN KEY (order_id) REFERENCES orders(id) ON DELETE CASCADE;
SQL Server 的 INSTEAD OF DELETE 触发器要注意事务边界
SQL Server 里用 INSTEAD OF DELETE 能完全接管删除逻辑，但必须手动补上原表的 DELETE，否则父表记录不会真删掉。
典型错误是只删了子表，忘了 DELETE FROM deleted_table WHERE id IN (SELECT id FROM deleted)，结果看起来“级联”了，其实父表还在。
-
deleted是系统临时表，只在触发器内可见，存着即将被删的行 - 如果子表有触发器，且也用了
INSTEAD OF，需确认是否允许嵌套触发器（默认关闭，要先开sp_configure 'nested triggers', 1） - 不建议在触发器里调用存储过程做删除——堆栈深、调试难、执行计划不可控
跨数据库迁移时，触发器级联几乎必然失效
MySQL 的触发器语法、SQL Server 的 deleted 表、PostgreSQL 的 ON DELETE 行为，三者不兼容。哪怕只是从 MySQL 迁到 MariaDB，也要重新验证触发器是否被禁用（log_bin_trust_function_creators 可能影响）。
真正容易被忽略的是权限问题：触发器执行时用的是定义者权限（DEFINER），不是调用者权限。如果定义者账号被删或密码过期，整个级联逻辑就静默失效，日志里可能只有一句 ERROR 1449 (HY000): The user specified as a definer ('xxx'@'%') does not exist。
