嵌套查询在清洗重复和异常值时比单层where更可控、可验证；可用子查询+left join ... is null安全去重，或先识别再更新异常值，并注意cte优化、null过滤及执行计划分析。
嵌套查询不是万能的，但在清洗重复和异常值时，它比单层 WHERE 更可控、更可验证。 直接用 DELETE 或 UPDATE 配合子查询，能避免误删主表中本该保留的记录，尤其适合没有主键或复合业务去重逻辑的场景。
用子查询识别并删除重复行（无主键也安全）
当表里没有自增 id 或唯一标识字段时，DISTINCT 无法回写原表，而 GROUP BY + MIN() 又依赖隐式排序假设——这时必须靠子查询明确“留哪一条”。
- 先用子查询标记每组重复数据中要保留的记录（比如按时间最新、分数最高）：
SELECT user_id, MAX(created_at) AS keep_time FROM user_logs GROUP BY user_id
- 再用这个结果反向关联原表，只保留匹配的行：
DELETE t1 FROM user_logs t1 LEFT JOIN ( SELECT user_id, MAX(created_at) AS keep_time FROM user_logs GROUP BY user_id ) t2 ON t1.user_id = t2.user_id AND t1.created_at = t2.keep_time WHERE t2.keep_time IS NULL;
- 关键点：用
LEFT JOIN ... WHERE ... IS NULL实现“排除法”，比NOT IN更安全（后者对NULL敏感，易漏删）
用子查询检测并隔离异常值（不直接改原表）
直接 UPDATE 异常值风险高，尤其当判断逻辑涉及多列统计（如“某用户当日订单量 > 全局均值3倍”）。应先用子查询把可疑记录抽出来单独看。
- 例如，找出订单金额明显偏离的记录：
SELECT order_id, amount, (SELECT AVG(amount) FROM orders) AS avg_amount, (SELECT STDDEV(amount) FROM orders) AS std_amount FROM orders WHERE amount > ( SELECT AVG(amount) + 3 * STDDEV(amount) FROM orders );
- 如果确认要修正，再基于此结果做更新：
UPDATE orders SET amount = ( SELECT AVG(amount) FROM orders WHERE amount IS NOT NULL ) WHERE order_id IN ( SELECT order_id FROM ( SELECT order_id FROM orders WHERE amount > ( SELECT AVG(amount) + 3 * STDDEV(amount) FROM orders ) ) t ); - 注意嵌套层级：MySQL 不允许直接在子查询中更新同一张表，所以外层必须再包一层
(SELECT ...)临时别名
子查询性能与可读性平衡技巧
嵌套过深会让语句难调试，但盲目扁平化又牺牲逻辑清晰度。重点在于让每一层子查询有明确职责。
- 用
WITH（CTE）替代多层括号嵌套，尤其在 PostgreSQL / SQL Server 中：WITH stats AS ( SELECT AVG(amount) AS avg_amt, STDDEV(amount) AS std_amt FROM orders ), outliers AS ( SELECT order_id FROM orders, stats WHERE amount > avg_amt + 3 * std_amt ) UPDATE orders SET amount = (SELECT avg_amt FROM stats) WHERE order_id IN (SELECT order_id FROM outliers);
- MySQL 8.0+ 支持 CTE，但旧版只能靠临时表：
CREATE TEMPORARY TABLE tmp_outliers AS SELECT order_id FROM orders WHERE amount > ( SELECT AVG(amount) + 3 * STDDEV(amount) FROM orders );
- 所有子查询中的聚合（如
AVG、COUNT）必须加WHERE ... IS NOT NULL过滤，否则结果被NULL污染
真正容易被忽略的是子查询的执行顺序：数据库不一定按你写的从内到外执行，尤其是关联子查询会为每一行重复计算。清洗前先 EXPLAIN 看执行计划，确认没出现全表扫描嵌套——否则宁可用中间临时表分步处理。
