PostgreSQL：如何通过执行计划判断子查询的执行时机？

三个查询案例及执行计划 #

案例1：无排序，直接LIMIT 10 #

EXPLAIN ANALYZE
SELECT 
    * ,
    (
        SELECT COUNT(*) FROM orders 
        WHERE orders.customer_id = customers.id
    ) as orders_count
FROM customers
LIMIT 10

执行计划图：

案例2：按主键id排序后LIMIT 10 #

EXPLAIN ANALYZE
SELECT 
    * ,
    (
        SELECT COUNT(*) FROM orders 
        WHERE orders.customer_id = customers.id
    ) as orders_count
FROM customers
ORDER BY id
LIMIT 10

执行计划图：

案例3：按子查询结果orders_count排序后LIMIT 10 #

EXPLAIN ANALYZE
SELECT 
    * ,
    (
        SELECT COUNT(*) FROM orders 
        WHERE orders.customer_id = customers.id
    ) as orders_count
FROM customers
ORDER BY orders_count
LIMIT 10

执行计划图：

如何判断子查询的计算范围 #

从执行计划可通过以下核心点判断：

• 案例1、2：执行计划中customers表的扫描逻辑会带LIMIT 10（比如Seq Scan/Index Scan后标注LIMIT），且子查询是关联子查询，会跟随主查询的取数逻辑：主查询只获取10条客户记录，子查询就仅为这10条记录执行COUNT计算，不会遍历所有客户行。
• 案例3：由于要按orders_count排序，数据库必须先为所有客户行计算出orders_count才能完成排序，之后再取前10条。执行计划会显示customers表是全表扫描（无提前LIMIT），且存在Sort步骤，这说明子查询被执行了数百万次（对应所有客户）。

优化建议（减少计算次数） #

若要避免全量计算，需注意：

1. 不要按子查询结果字段排序，排序依赖全量数据，必然触发全表计算。
2. 优先让主查询先取数/过滤，再执行子查询：比如案例1、2的写法，仅需为10条客户计算订单数，计算次数仅10次。
3. 可尝试用JOIN+GROUP BY重写，若orders表有customer_id索引，效率更优：

EXPLAIN ANALYZE
SELECT c.*, COALESCE(o.orders_count, 0) as orders_count
FROM customers c
LEFT JOIN (
    SELECT customer_id, COUNT(*) as orders_count
    FROM orders
    GROUP BY customer_id
) o ON c.id = o.customer_id
ORDER BY c.id
LIMIT 10;

不过仅需前10条客户时，案例2的关联子查询写法更高效，因为只触发10次COUNT计算。

内容的提问来源于stack exchange，提问作者Ivan