子查询DELETE前必须单独执行子查询验证，否则可能删空表或零行删除；需检查行数、NULL值、索引使用及执行计划一致性。
子查询 DELETE 前必须单独执行子查询
直接写 DELETE FROM orders WHERE user_id IN (SELECT id FROM users WHERE status = 'deleted') 是高危操作——你根本不知道括号里到底返回多少行。子查询一旦出错（比如字段名拼错、表别名冲突、NULL 值导致逻辑短路），整个 DELETE 可能删空表或一无所获，还查不出原因。
正确做法是把子查询拎出来单独跑一遍：
-
SELECT COUNT(*) FROM users WHERE status = 'deleted'—— 看量级是否合理（预期删 20 行，结果返回 20000？立刻停手） -
SELECT id FROM users WHERE status = 'deleted' LIMIT 10—— 核对这些id是否真在orders表中存在（避免因外键约束缺失或数据不一致导致“删了但没删到”） - 如果子查询含
JOIN或函数（如DATE(created_at)），额外加EXPLAIN看是否走了索引，避免全表扫描拖垮主库
IN 子查询和 EXISTS 子查询的验证方式不同
IN 和 EXISTS 在语义和性能上差异很大，验证方法不能混用：
-
IN子查询必须关注返回值是否含NULL：只要子查询结果里有一行是NULL，整个IN判断就恒为UNKNOWN，DELETE 不匹配任何行——所以验证时得加WHERE id IS NOT NULL -
EXISTS子查询不用数行数，但要确认关联字段类型一致：比如orders.user_id是BIGINT，而子查询里users.id是INT，隐式转换可能让索引失效，验证时得用EXPLAIN SELECT 1 FROM users u WHERE u.id = 1234567890123模拟单值判断 - MySQL 8.0+ 中，
NOT EXISTS比NOT IN更安全，后者遇到NULL直接失效；验证时优先用EXISTS写法重写再测
带 JOIN 的 DELETE 验证必须拆成等价 SELECT
MySQL 支持 DELETE t1 FROM orders t1 JOIN users t2 ON t1.user_id = t2.id WHERE t2.status = 'banned'，但这种写法无法直接看影响行数。它绕过了标准的 ROW_COUNT() 计数逻辑，某些版本甚至返回错误值。
安全验证步骤：
- 先把 DELETE 改成等价 SELECT：
SELECT t1.* FROM orders t1 JOIN users t2 ON t1.user_id = t2.id WHERE t2.status = 'banned' - 加
LIMIT 10快速核对数据合理性（比如user_id是否真对应被封禁用户） - 用
SELECT COUNT(*)替换SELECT t1.*获取精确量级 - 注意 JOIN 条件字段是否都有索引——没索引的
JOIN在 DELETE 时会锁表更久，验证阶段就能暴露
子查询结果被缓存或复用时的陷阱
某些 ORM 或中间件（如 MyBatis、ShardingSphere）会对子查询做自动缓存或参数化重写，导致你本地验证的 SQL 和实际执行的不一致。
排查要点：
- 在数据库命令行里直接执行验证 SQL，不要依赖应用日志里打印的“预编译语句”
- 检查子查询是否被替换成临时表（如
SELECT ... INTO TEMPORARY TABLE _tmp），这种情况下EXPLAIN看不到原表索引使用情况 - PostgreSQL 中，如果子查询用了
MATERIALIZED，验证时得加同样提示，否则统计计划偏差极大 - 最保险的方式：在同事务中先
CREATE TEMP TABLE tmp_ids AS (子查询)，再用SELECT COUNT(*) FROM tmp_ids和DELETE ... WHERE user_id IN (SELECT id FROM tmp_ids)，确保两次执行完全一致
真实线上事故里，子查询误删往往不是语法错，而是验证时没意识到“同一个子查询，在 SELECT 和 DELETE 上下文里，优化器选的执行计划可能完全不同”。尤其当子查询涉及分区表、物化视图或跨库链接时，差一行验证，就差一个回档窗口。
