子查询扁平化技巧：减少嵌套层级的查询重构

一、从"意大利面式SQL"说起

在电商订单系统的优化实践中，我曾接手过一段执行耗时超过15秒的查询。这个查询包含5层嵌套子查询，像缠绕的意大利面般难以理清。通过执行计划分析发现，最内层的子查询被重复执行了2300次，导致全表扫描成为性能瓶颈。

这类嵌套结构往往源于开发者对业务逻辑的直观映射：

SELECT * FROM orders WHERE user_id IN (
    SELECT id FROM users WHERE region IN (
        SELECT code FROM regions WHERE parent_code IN (
            SELECT code FROM regions WHERE name LIKE '%华东%'
        )
    )
);

当嵌套层级超过3层时，查询不仅难以维护，还会引发：

1. 优化器无法有效选择最优执行路径
2. 重复子查询导致数据多次扫描
3. 临时表空间过度消耗
4. 锁等待时间不可控

二、结构化重构四步法

1. CTE拆解法

将深层嵌套转换为顺序执行的CTE模块：

WITH 
east_regions AS (
    SELECT code FROM regions WHERE name LIKE '%华东%'
),
province_regions AS (
    SELECT code FROM regions 
    WHERE parent_code IN (SELECT code FROM east_regions)
),
target_users AS (
    SELECT id FROM users 
    WHERE region IN (SELECT code FROM province_regions)
)
SELECT * FROM orders 
WHERE user_id IN (SELECT id FROM target_users);

这种重构使执行计划呈现清晰的流水线结构，便于添加索引提示。

2. 半连接转化

将IN子句改写为EXISTS关联：

SELECT * FROM orders o
WHERE EXISTS (
    SELECT 1 FROM users u
    WHERE u.id = o.user_id
    AND EXISTS (
        SELECT 1 FROM regions r
        WHERE r.code = u.region
        AND r.parent_code IN (
            SELECT code FROM regions 
            WHERE name LIKE '%华东%'
        )
    )
);

通过驱动表选择优化，可将嵌套循环改为哈希连接。

3. 物化中间结果

对于重复使用的子查询，创建临时表并建立索引：

CREATE TEMPORARY TABLE temp_regions AS
SELECT code FROM regions 
WHERE parent_code IN (
    SELECT code FROM regions 
    WHERE name LIKE '%华东%'
);

CREATE INDEX idx_temp_regions_code ON temp_regions(code);

-- 后续查询改为：
SELECT * FROM orders 
WHERE user_id IN (
    SELECT id FROM users 
    WHERE region IN (SELECT code FROM temp_regions)
);

4. 窗口函数替代

针对聚合类子查询，使用窗口函数消除嵌套：

-- 原始嵌套查询
SELECT * FROM (
    SELECT *, 
    (SELECT COUNT(*) FROM orders o2 
     WHERE o2.user_id = o1.user_id) AS order_count
    FROM orders o1
) t WHERE order_count > 5;

-- 优化后
SELECT *, COUNT(*) OVER(PARTITION BY user_id) AS order_count
FROM orders
QUALIFY order_count > 5;

三、执行计划验证技巧

在MySQL中使用EXPLAIN FORMAT=JSON观察：

• materialized_subqueries字段显示物化情况
• attached_condition查看条件推下
• rows_examined_per_scan对比扫描行数

PostgreSQL的EXPLAIN ANALYZE需关注：

• Loop节点出现次数
• Hash Cond的内存使用
• SubPlan的执行次数

四、实战案例：促销活动名单生成

在某次双十一大促前，业务方要求实时生成"近30天下单≥5次且所在区域为华东地区"的用户名单。原始SQL包含4层嵌套：

SELECT u.id, u.name 
FROM users u 
WHERE u.id IN (
    SELECT o.user_id 
    FROM (
        SELECT user_id, COUNT(*) cnt 
        FROM orders 
        WHERE create_time > NOW() - INTERVAL 30 DAY 
        GROUP BY user_id
    ) o 
    WHERE o.cnt >= 5
) 
AND EXISTS (
    SELECT 1 
    FROM user_addresses a 
    WHERE a.user_id = u.id 
    AND a.region_code IN (
        SELECT code 
        FROM regions 
        WHERE path LIKE '%华东%'
    )
);

通过执行计划发现：

1. 最内层orders表扫描次数达23次
2. regions表全表扫描导致临时表文件达1.2GB
3. 最终结果集仅返回127条记录

采用混合优化策略：

-- 首先物化高频使用的区域集合
CREATE TEMPORARY TABLE east_regions AS
SELECT code FROM regions 
WHERE path LIKE '%华东%'
UNION ALL
SELECT code FROM regions r
JOIN east_regions er ON r.parent_code = er.code;

-- 创建组合索引
CREATE INDEX idx_orders_user_time ON orders(user_id, create_time);
CLUSTER orders USING idx_orders_user_time;

-- 重构查询结构
WITH 
user_order_stats AS (
    SELECT user_id, COUNT(*) AS order_count
    FROM orders 
    WHERE create_time > NOW() - INTERVAL 30 DAY
    GROUP BY user_id
    HAVING COUNT(*) >= 5
)
SELECT u.id, u.name 
FROM users u
JOIN user_order_stats uos ON u.id = uos.user_id
JOIN east_regions er ON er.code = u.region_code;

优化效果：

• 执行时间从15.2秒降至0.3秒
• 物理IO减少87%
• 临时内存使用降低92%

五、风险控制与验证策略

1. 结果集一致性验证

在重构涉及EXISTS/IN转换时，需特别注意NULL值处理差异：

-- 原始查询可能返回NULL
SELECT * FROM t1 WHERE id IN (SELECT id FROM t2 WHERE ...);

-- 等价改写需显式处理NULL
SELECT * FROM t1 
WHERE id IN (SELECT id FROM t2 WHERE ...) 
OR (id IS NULL AND EXISTS (SELECT 1 FROM t2 WHERE id IS NULL));

2. 锁竞争预防

在OLTP场景中，物化中间结果可能引发锁竞争：

-- 风险写法
CREATE TEMPORARY TABLE temp_data AS 
SELECT * FROM orders WHERE status = 'processing' FOR UPDATE;

-- 优化方案
BEGIN;
CREATE TEMPORARY TABLE temp_data AS 
SELECT * FROM orders WHERE status = 'processing' 
WITH NO DATA MODIFICATION; -- 仅复制结构
INSERT INTO temp_data
SELECT * FROM orders 
WHERE status = 'processing' 
FOR UPDATE NOWAIT; -- 避免长时间锁等待
COMMIT;

3. 执行计划偏差规避

当使用CTE时，PostgreSQL可能提前固化执行计划：

-- 强制Materialization
WITH RECURSIVE 
cte AS MATERIALIZED ( 
    SELECT ... 
)

-- MySQL的优化提示
SELECT /*+ SET_VAR(cte_max_recursion_depth=1000) */ ...

4. 维护成本评估

重构后的查询应满足：

• 新增字段时修改点不超过3处
• 表结构变更影响范围可预判
• 索引调整成本低于原始查询

---

---

---

🌟 让技术经验流动起来

▌▍▎▏ 你的每个互动都在为技术社区蓄能 ▏▎▍▌

✅ 点赞 → 让优质经验被更多人看见

📥 收藏 → 构建你的专属知识库

🔄 转发 → 与技术伙伴共享避坑指南

点赞 ➕ 收藏 ➕ 转发，助力更多小伙伴一起成长！💪

💌 深度连接 ：

点击 「头像」→「+关注」

每周解锁：

🔥 一线架构实录 ｜ 💡 故障排查手册 ｜ 🚀 效能提升秘籍