级联删除必须在建表或修改表结构时通过on delete cascade显式声明外键约束，无法在delete语句运行时临时启用；mysql仅支持cascade、restrict、set null，不支持set default，且该行为由ddl定义、运行时自动执行。
级联删除必须靠外键定义，不是DELETE语句能直接控制的
SQL标准里没有“在DELETE时临时开启级联”的语法。ON DELETE CASCADE 是外键约束的一部分，必须建表或修改表结构时显式声明。运行时执行 DELETE FROM parent，数据库才按该约束自动删子记录；否则默认报错（FOREIGN KEY constraint failed）或拒绝操作（取决于DBMS严格模式）。
常见误区是以为加个选项或提示就能触发级联——不行。MySQL、PostgreSQL、SQLite 都要求这个行为写死在 DDL 里。
PostgreSQL 和 MySQL 的 ON DELETE 行为差异明显
PostgreSQL 支持完整五种动作：NO ACTION（默认，检查时机晚）、RESTRICT（立即拒绝）、CASCADE、SET NULL、SET DEFAULT。MySQL 只支持 CASCADE、RESTRICT、SET NULL（且要求字段允许NULL），不支持 SET DEFAULT（即使字段有DEFAULT也不行）。
实操建议：
- 跨库迁移前检查外键定义，MySQL 的
SET NULL在 PostgreSQL 中可能需改写为SET DEFAULT或手动处理 - PostgreSQL 的
NO ACTION实际等价于RESTRICT（多数情况），但语义上它把检查推迟到事务结尾，可能引发意外交互 - MySQL 8.0+ 支持
FOREIGN_KEY_CHECKS=0临时禁用外键，但这是危险操作，删完必须立刻恢复，且不解决根本影响范围问题
想限制级联影响范围？只能靠 WHERE + 显式分批删除
外键级联是“全有或全无”的：一旦触发，会递归删掉所有满足外键路径的子记录，无法指定只删某几层或加条件过滤。要控制范围，必须绕开级联，自己动手。
典型做法是分步操作：
- 先查出目标父记录的ID集合：
SELECT id FROM orders WHERE status = 'canceled' AND created_at - 用这些ID批量删子表（如 order_items）：
DELETE FROM order_items WHERE order_id IN (…) - 再删父表：
DELETE FROM orders WHERE id IN (…)
这样做还能加索引优化、加事务包裹、加日志记录——而原生级联做不到这些。SQLite 的 PRAGMA foreign_keys = ON 开启后也一样，级联深度不可控。
软删除比级联删除更可控，但需重构查询逻辑
真正想“控制影响范围”，往往说明业务需要留痕或可逆。这时硬删+级联反而有害。改用软删除（加 is_deleted 或 deleted_at 字段）是更常见的解法。
代价很实在：
- 所有读查询都得补
WHERE is_deleted = 0（或用视图/生成列封装） - 唯一索引需改成函数索引（如 PostgreSQL 的
CREATE UNIQUE INDEX ON users (email) WHERE is_deleted = false） - 外键约束依然存在，但级联动作失效——你得靠应用层或触发器模拟“逻辑级联”
级联删除本身很简单，难的是删之前知道删多少、为什么删、删了能不能回滚。这些从来不在 ON DELETE CASCADE 的职责范围内。
