触发器中不能直接用 UPDATE ... JOIN 跨表更新软删除状态，必须拆分为多个单表 UPDATE 并加 WHERE is_deleted = 0 防重复；需确保外键字段有独立索引、禁用 ON DELETE CASCADE、避免递归调用，并注意下游缓存同步。
触发器里不能直接用 UPDATE ... JOIN 跨表更新软删除状态
MySQL 5.7+ 和 PostgreSQL 都不支持在 BEFORE 或 AFTER 触发器中写带 JOIN 的多表 UPDATE（会报错 Can't update table 'xxx' in stored function/trigger）。你试图让主表 users 软删时，自动把 orders 和 profiles 表的 is_deleted = 1，但直觉写的语句会失败。
真正可行的路径是：用子查询或游标逐条更新，或者拆成多个独立 UPDATE。推荐后者——清晰、可调试、避免锁表时间过长。
- 用
UPDATE orders SET is_deleted = 1 WHERE user_id = OLD.id AND is_deleted = 0，加AND is_deleted = 0防止重复更新 - 同理更新
profiles，不要省略WHERE is_deleted = 0，否则可能覆盖人工恢复的数据 - PostgreSQL 中可考虑用
UPDATE ... FROM语法，但它仍受限于触发器对“被修改表”的只读限制，所以依然得走单表更新
软删除级联必须检查外键约束与索引有效性
如果 orders.user_id 没有索引，UPDATE ... WHERE user_id = OLD.id 会全表扫描，主表一删，从表更新卡住几秒甚至超时。更隐蔽的问题是：当 users 表本身用了逻辑删除（如 is_deleted = 1），而外键定义仍是 ON DELETE CASCADE，那物理删除触发器还没跑，数据库就先报外键冲突了。
- 确认所有被级联的字段（如
user_id）都建了普通 B-tree 索引，别依赖联合索引的前缀 - 禁用真实外键的
ON DELETE CASCADE，改用触发器控制；否则软删和外键行为会打架 - 若用
deleted_at时间戳，注意比较时用IS NULL而非= 0，避免隐式类型转换失效索引
触发器中避免递归调用导致死循环
假设你在 orders 上也写了软删触发器，去级联更新 order_items；而 users 触发器又去更新 orders —— 这时 orders 的触发器会被再次激活，形成递归。MySQL 默认禁止，PostgreSQL 则可能栈溢出或无限执行。
- 给每个触发器加守卫变量，例如在
users触发器开头设@in_user_soft_delete := TRUE，orders触发器开头加IF @in_user_soft_delete THEN LEAVE proc_label; END IF; - 更稳妥的做法是：只在最顶层主表（如
users）放级联逻辑，下游表（orders,profiles）的触发器不主动级联，仅负责自身业务逻辑 - 测试时用
SELECT @@max_sp_recursion_depth（MySQL）确认递归深度，生产环境建议设为 0 禁用递归
PostgreSQL 用 EXECUTE 动态 SQL 更灵活但代价高
PG 中无法在触发器函数里直接写多表操作，但可以用 EXECUTE 拼接并运行动态 SQL。它能绕过静态解析限制，比如根据 OLD.table_name 字段决定更新哪张子表。不过每次拼串 + 解析 + 执行，比静态 UPDATE 慢 3–5 倍，且无法被计划缓存复用。
- 只在“级联目标表不确定”场景用，比如通用软删框架；固定结构下硬编码更稳
- 务必用
quote_literal(OLD.id)而不是字符串拼接，防 SQL 注入（即使触发器由 DBA 控制，也要防数据污染） - 动态 SQL 报错时堆栈不友好，建议在
EXCEPTION块里RAISE NOTICE输出完整拼出的语句，方便定位
跨表软删不是靠一个华丽的 SQL 实现的，而是靠索引是否到位、触发器是否守界、级联方向是否单向可控。最容易被忽略的是：你以为更新了 orders.is_deleted 就完事了，但下游视图、物化视图或应用缓存可能还拿着旧状态——这些不在触发器管辖范围，得另外设计同步机制。
