IN 子句里嵌套子查询时，为什么 DELETE 会报错“You can't specify target table for update in FROM clause”？
先捋一下问题的根因，这个报错很经典。
MySQL 怕的不是"语法不对"，而是你在这条语句中，对同一种表既想读又想删。一旦把目标表同时放在 DELETE 和子查询的 FROM 里，MySQL 直接拒掉，不给解释机会。
这个限制，主要是历史包袱——MySQL 的优化器在解析阶段会严格区分读和写操作，不像 PostgreSQL、SQL Server 那么"大度"。所以 MySQL 用户就得绕一下。
最稳妥的解法，套一层派生表。意思就是先把子查询存成临时结果集，再对这个临时结果做 IN 判断。
- 具体写法：
DELETE FROM users WHERE id IN (SELECT * FROM (SELECT user_id FROM logs WHERE created_at < '2023-01-01') AS tmp) - 别忘了给外层子查询起别名，比如
AS tmp，否则 MySQL 8.0+ 仍然报错 - 另一个风险藏在 NULL 值本身。如果子查询里返回了一个
NULL，那么整个id IN (1, 2, NULL)结果恒为 FALSE——因为 SQL 语义里，NULL 跟任何值比较都不是 TRUE。所以在子查询里加个WHERE user_id IS NOT NULL是安全的
用 JOIN 替代 IN + 子查询，更适合大表删除且能规避 NULL 陷阱
如果待删的记录很多，或者关联的表数据量上来了，IN 就暴露短板了。性能支棱不起来，而且索引利用率不高。
换成 JOIN，不仅快，还顺便把 NULL 问题给解决了。
- 对等写法：
DELETE u FROM users u INNER JOIN logs l ON u.id = l.user_id WHERE l.created_at < '2023-01-01' - INNER JOIN 自动过滤掉无匹配的记录，天然不会有 NULL 干扰
- 但前提是
logs.user_id必须有索引，否则 JOIN 对全表展开，删几千行能把数据库拖垮 - 如果只想删主表里无日志的那部分用户，可以用
LEFT JOIN + IS NULL反向筛选
批量删除前必须验证子查询结果，否则删错没法回滚
执行 DELETE 之前，永远先跑一遍对应的 SELECT。这步不能跳过。
- 把 DELETE 先换成
SELECT COUNT(*)或者SELECT id, name FROM ...看一眼规模 - 特别当子查询跨库、跨实例时，某些数据库（比如 TiDB）对这类场景支持有限，有可能静默返回空结果——这不是 bug，是行为差异
- 如果子查询里用了聚合函数或窗口函数（比如
ROW_NUMBER()），MySQL 5.7 是跑不了的，得升级版本或改写逻辑 - 测试时给子查询加个
LIMIT 10，比如(SELECT user_id FROM logs LIMIT 10)，能在几乎无风险的情况下验证逻辑
WHERE 条件里 IN 子查询返回空结果集时，DELETE 会什么也不做
这其实是个容易被忽略的"安全假象"。
- 如果子查询没返回任何行，整条 DELETE 就像没发生过一样，返回 "0 rows affected"，但日志里看不出任何异常
- 这是因为
IN (empty_set)恒为 FALSE，SQL 标准行为就是这样 - 如果业务要求”至少删 N 条”，就不能一步到位，得拆分：先 SELECT 计数，判断有没有数据，再跑 DELETE
- 某些 ORM（比如 Django ORM）生成的子查询可能隐式加了
WHERE 1=0条件，导致空结果，必须检查实际生成的原始 SQL - 线上操作建议搭配监控：执行后查
SELECT ROW_COUNT()，确保影响行数跟预期一致
实际删数据时候，最麻烦的从来不是语法，而是子查询跑出来的结果跟你"以为"的不一样。尤其当它关联了状态表、时间分区表或者带了一堆 OR 条件，就很容易漏掉边界情况。
