嵌套查询本身不直接去重，但能明确保留规则并安全删除重复行；通过子查询定义保留逻辑（如max时间），再left join is null定位待删行，避免not in的null风险。
嵌套查询本身不直接“去重”，但它能让你在删除前明确知道“谁该留、谁该删”，避免误操作。关键不在语法多炫，而在逻辑是否可验证、执行是否可回退。
用子查询 + LEFT JOIN IS NULL 安全删除重复行
当表没有主键或业务去重逻辑复杂（比如“同用户只留最新一条”）时，DELETE 不能靠 DISTINCT 或裸 GROUP BY 解决。必须先定义“保留规则”，再反向排除。
- 先写子查询明确每组要保留哪条：
SELECT user_id, MAX(created_at) AS keep_time FROM logs GROUP BY user_id - 再用
LEFT JOIN关联原表，找不匹配的行：ON t1.user_id = t2.user_id AND t1.created_at = t2.keep_time - 最后用
WHERE t2.keep_time IS NULL删除——比NOT IN安全，不怕子查询结果含NULL
用子查询隔离异常值，别急着 UPDATE
清洗异常值（如订单金额 > 均值+3倍标准差）时，直接 UPDATE 风险极高。嵌套查询的价值是“先抽出来看”，而不是“一步到位改”。
- 外层
SELECT只查可疑记录，同时带出统计基准：(SELECT AVG(amount) FROM orders)和(SELECT STDDEV(amount) FROM orders) - 避免在子查询里反复算均值/标准差，可提成 CTE 或临时表，尤其数据量大时
- 确认无误后，再基于这个结果集做
UPDATE，例如：UPDATE orders SET amount = 0 WHERE order_id IN (SELECT order_id FROM (...))
嵌套查询里 DISTINCT 为什么总失效？
不是 DISTINCT 不起作用，而是它被放在了错误位置——它只对最终输出行去重，而内层 JOIN 或子查询已经把一行变多行了。
- 典型陷阱：查用户+订单，写了
SELECT DISTINCT u.id, u.name, o.order_id，但一个用户有 5 个订单，就必然出 5 行 - 如果目标是“每个用户只出一行”，就得换思路：
GROUP BY u.id, u.name配合MAX(o.created_at)或COUNT(o.id) -
EXISTS比IN更适合存在性判断，不拉字段、不膨胀行数，但要注意关联字段是否有索引
真正难的从来不是写出能跑的 SQL，而是说清楚“为什么这条该删”“删完怎么验证没伤到关联数据”。嵌套查询的嵌套深度，应该由业务逻辑的确定性决定，而不是数据库支持几层。越复杂的清洗，越要拆成“识别→导出→评审→执行→核对”五步，别指望一个 DELETE 语句包打天下。
