IQR法通过Q1和Q3动态计算上下界（Q1−1.5×IQR、Q3+1.5×IQR）识别离群值，比AVG/STDDEV更鲁棒；需用两层子查询或CTE先算分位数，避免相关子查询导致性能暴跌。

用子查询计算上下四分位数（IQR）识别离群值

直接用 AVG() 或 STDDEV() 容易被极端值污染，而 IQR 对异常值鲁棒得多。关键不是“查出最大最小”，而是动态算出当前数据集的 Q1 和 Q3，再推导出边界。

多数 SQL 引擎不支持窗口函数嵌套在 WHERE 中，所以得用两层子查询：外层查原始数据，内层用 PERCENTILE_CONT()（PostgreSQL/SQL Server）或变量模拟（MySQL 8.0+）算出 Q1、Q3；MySQL 5.7 则需用自连接或 LIMIT/OFFSET 逼近中位数逻辑。

• PostgreSQL 示例（推荐）：

  SELECT val FROM data_table 
  WHERE val < (
    SELECT PERCENTILE_CONT(0.25) WITHIN GROUP (ORDER BY val) * 1.5 - 
           PERCENTILE_CONT(0.75) WITHIN GROUP (ORDER BY val) * 0.5 
    FROM data_table
  ) OR val > (
    SELECT PERCENTILE_CONT(0.75) WITHIN GROUP (ORDER BY val) * 1.5 - 
           PERCENTILE_CONT(0.25) WITHIN GROUP (ORDER BY val) * 0.5 
    FROM data_table
  );

• MySQL 8.0+ 可用 PERCENT_RANK() 配合 CTE 模拟，但注意 PERCENTILE_CONT 不原生支持，必须手写排序编号逻辑
• SQLite 没有百分位函数，只能用两遍子查询 + (SELECT COUNT(*) FROM ...) 算位置，性能差，慎用于大表

WHERE 中嵌套子查询导致全表扫描的典型陷阱

如果子查询没加索引或依赖外部列（比如相关子查询），数据库可能对主表每行都执行一次子查询，O(n²) 开销瞬间爆炸。

• 错误写法（相关子查询）：WHERE val > (SELECT Q3 * 1.5 FROM (SELECT ... AS Q3) t WHERE t.group_id = data_table.group_id) —— 即使加了 group_id 索引，也大概率触发嵌套循环
• 正确做法：先用 CTE 或派生表一次性算出所有分组的 Q1/Q3，再 JOIN，避免重复计算
• 检查执行计划时重点看 Extra 字段是否含 Using where; Using index，出现 Using temporary; Using filesort 就说明子查询结构拖累了性能

处理 NULL 和空分组时子查询返回空结果的静默失败

当子查询没返回任何行（例如某 group_id 完全为空），WHERE val > (子查询) 整个条件会变成 UNKNOWN，该行被过滤掉——不是报错，而是“消失”，极易误判为“无异常值”。

• 用 COALESCE((SELECT ...), 0) 强制提供默认值，但注意 0 可能成为新离群点，更安全的是用 NULLIF 配合外层 IS NOT NULL 显式判断
• 对分组场景，务必在子查询中加 HAVING COUNT(*) > 0，否则 PERCENTILE_CONT 在空组返回 NULL，外层比较失效
• 测试时故意插入一条 NULL 值和一条超大值，确认两者是否都被捕获；若只有后者出现，说明 NULL 被子查询逻辑吞掉了

用 EXISTS 替代标量子查询提升可读性与稳定性

当目标是“标记是否为离群值”而非“返回离群值本身”，EXISTS 比 val > (SELECT ...) 更可靠：它不依赖标量结果是否为 NULL，只关心是否存在满足条件的记录。

• 示例（标记布尔字段）：

  SELECT val,
         EXISTS(
           SELECT 1 FROM (
             SELECT PERCENTILE_CONT(0.25) WITHIN GROUP (ORDER BY val) AS q1,
                    PERCENTILE_CONT(0.75) WITHIN GROUP (ORDER BY val) AS q3
             FROM data_table
           ) iqr
           WHERE data_table.val < iqr.q1 - 1.5 * (iqr.q3 - iqr.q1)
              OR data_table.val > iqr.q3 + 1.5 * (iqr.q3 - iqr.q1)
         ) AS is_outlier
  FROM data_table;

• EXISTS 天然规避标量子查询返回多行的 Subquery returns more than 1 row 错误
• 部分旧版 MySQL 对 EXISTS 子查询优化不佳，若发现慢，可改用 LEFT JOIN 预计算的 IQR 表

真正麻烦的不是写出嵌套子查询，而是当数据按时间分区、带多级分类、且存在大量稀疏维度时，IQR 必须按组重算——这时子查询得套三层，稍不注意就会把 GROUP BY 漏在最外层，导致全表共用一个 IQR 边界。动手前先用小样本加 EXPLAIN ANALYZE 看清楚子查询执行次数。