ON DELETE CASCADE是唯一真正级联机制，需建表或ALTER TABLE时显式声明，由引擎自动触发，非SQL语句实现；DELETE JOIN仅为MySQL语法糖，不保障数据一致性，且PostgreSQL/SQLite不支持。
级联删除不是“写一条 DELETE 就完事”，而是靠外键约束声明行为，MySQL/PostgreSQL 都不支持在 DELETE 语句里用 JOIN 实现真正的级联逻辑——那是语法糖，不是数据一致性保障。
ON DELETE CASCADE 是唯一真正级联的机制
它由数据库引擎在执行主表 DELETE 时自动触发，不是 SQL 语句写的，是表结构定义的一部分。
-
ON DELETE CASCADE必须在建表或ALTER TABLE时显式声明，运行时不会动态生效 - 只对被删主表行的直接子表生效，不会穿透到孙子表（比如 orders → order_items → item_logs，后者不会被自动删）
- MySQL InnoDB 和 PostgreSQL 都支持，但 SQLite 不支持（会忽略该关键字）
- 执行时不可中断、不可回滚单个子表操作——整个事务要么全成功，要么全失败
DELETE + JOIN 不是级联，只是多表联合筛选删除
很多人把 DELETE t1, t2 FROM t1 JOIN t2 ON t1.id = t2.ref_id 当成级联，其实它既不检查外键，也不保证顺序，更不处理缺失关联。
-
DELETE t1, t2 FROM orders t1 JOIN order_items t2 ON t1.id = t2.order_id只删那些“既有订单又有明细”的组合，漏掉无明细的订单 - 如果
order_items.order_id没索引，JOIN 会全表扫描，10 万行 × 10 万行 = 100 亿次比对 - 若
order_items上有FOREIGN KEY ... ON DELETE RESTRICT，这条语句仍能执行，但删完orders后留下孤立order_items行 - PostgreSQL 和 SQLite 直接报错：
syntax error near JOIN，因为根本不认这种写法
跨多层关联时，级联必须分层设计
真要删订单+明细+物流记录，不能指望一个 ON DELETE CASCADE 覆盖全部，得逐层加约束。
- 先确保
order_items.order_id有外键指向orders.id并带ON DELETE CASCADE - 再在
shipments.item_id上加外键指向order_items.id，同样配ON DELETE CASCADE - 中间任意一层缺约束或设成
ON DELETE NO ACTION，链就断了 - 注意循环依赖：比如
users和profiles互指外键，MySQL 会拒绝建表；PostgreSQL 允许但删时可能死锁
级联删除后空间不释放，这点常被忽略
删完 orders 表，SELECT COUNT(*) 少了，但磁盘占用没变——InnoDB 只标记删除，不立即回收空间。
- MySQL：删完立刻跑
OPTIMIZE TABLE orders（小表）或ALTER TABLE orders ENGINE=InnoDB（中大表） - PostgreSQL：必须手动
VACUUM orders清理死亡元组；要缩文件大小得VACUUM FULL orders（锁表，别在高峰期跑） - 没做这步，buffer pool 命中率下降、MVCC 版本链膨胀、后续查询变慢，问题会延迟暴露
