跨表批量软删除不能仅加is_deleted字段，必须解决关联更新一致性、索引失效、事务边界和查询穿透四大问题；sql server不支持update join需用merge+cte分表处理，mysql应避免子查询改用临时表+多表update。
软删除不是加个 is_deleted 字段就完事的；跨表批量软删除必须解决关联更新一致性、索引失效、事务边界和查询穿透这四个硬伤。
为什么直接 UPDATE JOIN 在软删除中会出问题
SQL Server 不支持 UPDATE ... JOIN，硬写会报 Incorrect syntax near the keyword 'JOIN'；MySQL 虽支持，但若在软删除场景中用 UPDATE t1 JOIN t2 ON ... SET t1.is_deleted = 1，容易漏掉被外键引用但未显式 JOIN 的下游表（比如订单明细没同步标记），导致后续查询逻辑错乱。
- 软删除本质是状态变更，不是物理移除，所有关联查询必须带
WHERE is_deleted = 0，否则数据“还在却不可见” - 跨表更新时，如果只改主表（如
orders），不改从表（如order_items），就会出现“已取消订单里还有未软删的明细”，破坏业务语义 - MySQL 中用子查询做条件（如
WHERE id IN (SELECT order_id FROM orders WHERE status = 'cancelled')）可能触发全表扫描，尤其当orders表无合适索引时
SQL Server 必须用 MERGE + 显式多层子查询
靠单个 MERGE 无法一次更新多张表，得拆成多个原子操作，并用事务包住。关键是：每个 MERGE 的 USING 子句必须返回完整待更新主键集，不能依赖隐式关联。
- 先用 CTE 汇总所有要软删的根记录 ID（比如满足条件的
orders.id） - 再分别对
orders、order_items、payments执行独立MERGE，USING都指向同一个 CTE，避免多次计算 -
MERGE的WHEN MATCHED后必须加AND target.is_deleted = 0，防止重复软删覆盖真实状态 - 示例片段：
MERGE orders AS t USING (SELECT id FROM @target_ids) AS s ON t.id = s.id WHEN MATCHED AND t.is_deleted = 0 THEN UPDATE SET is_deleted = 1, updated_at = GETDATE();
MySQL 要避开子查询陷阱，优先走临时表 + 多表 UPDATE
别用 UPDATE ... WHERE id IN (SELECT ...)，5.7+ 虽优化为 semi-join，但若子查询结果集大，仍可能退化。正确路径是：把目标 ID 先存进带主键的临时表，再用 UPDATE ... JOIN 多次关联。
- 建临时表：
CREATE TEMPORARY TABLE temp_del_ids (id BIGINT PRIMARY KEY) - 插入目标 ID：
INSERT INTO temp_del_ids SELECT id FROM orders WHERE created_at - 分表更新：
UPDATE orders o JOIN temp_del_ids t ON o.id = t.id SET o.is_deleted = 1, updated_at = NOW() - 同理更新
order_items：UPDATE order_items oi JOIN orders o ON oi.order_id = o.id JOIN temp_del_ids t ON o.id = t.id SET oi.is_deleted = 1 - 临时表自动销毁，不污染元数据
最容易被忽略的三个点
一是所有软删除字段必须加索引，否则 WHERE is_deleted = 0 变成全表扫描；二是跨表更新后，原查询 SQL 若没加 is_deleted 条件，结果就“凭空消失”——这不是 bug，是设计缺陷；三是事务里不能混用 TRUNCATE（它不走事务日志，无法回滚），哪怕只是清空一张中间日志表也得用 DELETE。
