嵌套查询做离群点检测效率低、易出错，仅当数据库不支持窗口函数、规则极简单且数据量小并有索引时才可考虑；需警惕null、类型转换及除零问题，推荐优先使用cte+窗口函数。
直接用嵌套查询做离群点检测，效率低、易出错，不推荐作为主力方案——除非你受限于数据库版本（如 MySQL 5.7）不支持窗口函数，且数据量小（
为什么嵌套查询不适合离群点检测
离群点检测本质是「先算全局/分组统计量，再逐行比对」，而嵌套查询在 WHERE 中调用子查询时，每行都可能触发一次独立执行（尤其相关子查询）。比如：
SELECT * FROM sales WHERE amount > (SELECT AVG(amount) * 3 FROM sales);
这段看似简洁，但多数数据库会把它优化成一次子查询；可一旦加了 GROUP BY 或引入外层字段关联，就极易退化为相关子查询，性能断崖式下跌。
- 子查询无法复用中间结果（如均值、标准差），重复计算开销大
- 不能自然表达「按部门分别算各自 IQR」这类分组逻辑
- 遇到标准差为 0（全等值）时，
(x - avg) / 0直接报错，嵌套里难加CASE WHEN容错
真要用嵌套查询，必须满足这三个前提
仅当同时满足以下条件时，才考虑用嵌套查询硬上：
- 数据库不支持
PERCENTILE_CONT、AVG() OVER()等窗口函数（如旧版 MySQL、SQLite） - 离群判定规则极简单：例如「只查全局均值±3σ」或「只查大于某固定阈值的记录」
- 表数据量小，且该字段有索引（避免子查询全表扫描）
示例（安全写法）：
SELECT * FROM user_income WHERE income > ( SELECT AVG(income) + 3 * STDDEV_POP(income) FROM user_income );
注意：STDDEV_POP 必须和 AVG 在同一子查询中计算，否则两次子查询可能因并发写入导致统计值不一致。
嵌套查询中替代 Z-score 的可行方案
若坚持用嵌套、又想避开除零和精度问题，可用四分位法近似代替正态假设：
- 用两个独立子查询分别取
PERCENTILE_CONT(0.25)和PERCENTILE_CONT(0.75)（需数据库支持，PostgreSQL/Oracle 可行） - 更通用的做法：用子查询算出
Q1和Q3，再拼成WHERE income Q3 + 1.5*(Q3-Q1) - 但注意——MySQL 8.0+ 才支持
PERCENTILE_CONT，老版本只能靠(SELECT ... LIMIT 1 OFFSET N)手动逼近，误差大且不可靠
真正稳健的写法仍是 CTE + 窗口函数，嵌套只是兜底手段。
最容易被忽略的坑：NULL 和类型隐式转换
嵌套查询中一旦涉及 NULL，IN、=、比较运算符行为会反直觉：
-
WHERE x IN (SELECT y FROM t WHERE y IS NULL)永远不匹配（IN遇到 NULL 整体判 FALSE） -
WHERE x = (SELECT MAX(y) FROM t)当子查询结果为 NULL 时，整行被过滤（不是返回 NULL，而是逻辑失效） - 若子查询返回多行，
=报错，必须改用IN或加LIMIT 1（但后者掩盖数据问题） - 数值字段和字符串字段混用（如
income = (SELECT '5000' FROM ...)）可能触发隐式转换，索引失效
离群检测本就依赖数值精度，这些细节一错，整个结果集就偏了。
