触发器中不能直接用 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 就完事了，但下游视图、物化视图或应用缓存可能还拿着旧状态——这些不在触发器管辖范围，得另外设计同步机制。