文章目录
- 一、为什么需要 CTE？
- 1.1 传统复杂查询的痛点
- 1.2 CTE 的核心优势
- 1.3 CTE vs 临时表 vs 视图
- 1.4 CTE 的核心价值
- 二、CTE 基础语法
- 2.1 多 CTE 链式组合
- 三、实战场景
- 3.1 场景1：计算用户活跃度指标（替代嵌套子查询，提升可读性）
- 3.2 场景2：多维度聚合分析，避免重复计算（性能优化）
- 3.3 场景3：组织架构查询（树形结构），递归 CTE（处理层次数据）
- 3.4 场景4：物料清单（BOM）展开
- 3.5 场景5：会话化用户行为日志，数据清洗与预处理
- 四、PostgreSQL 12+ 高级特性：控制 CTE 物化
- 4.1 默认行为（PostgreSQL 12 前）
- 4.2 新增控制选项（PostgreSQL 12+）
- 4.3 性能对比示例
- 五、常见陷阱与最佳实践
- 5.1 陷阱 1：CTE 中的 DML（数据修改）
- 5.2 陷阱 2：递归 CTE 无限循环
- 5.3 最佳实践总结
- 六、综合案例：电商漏斗分析
- 6.1 表结构
- 6.2 CTE 实现
适用版本：PostgreSQL 9.4+（推荐 12+，支持并行 CTE）
目标读者：数据分析师、后端开发、DBA
核心价值：化繁为简，用声明式 SQL 替代过程式代码，提升可读性与性能
一、为什么需要 CTE？
1.1 传统复杂查询的痛点
-- 嵌套子查询地狱（难以阅读、调试、复用）SELECTu.name,(SELECTCOUNT(*)FROMorders oWHEREo.user_id=u.idANDo.status='paid')ASpaid_orders,(SELECTSUM(o.amount)FROMorders oWHEREo.user_id=u.idANDo.status='paid')AStotal_spentFROMusers uWHEREu.idIN(SELECTDISTINCTuser_idFROMordersWHEREcreated_at>'2023-01-01'ANDuser_idIN(SELECTidFROMusersWHEREcountry='US'));问题：
- 重复扫描
orders表 3 次 - 逻辑分散，难以维护
- 无法复用中间结果
1.2 CTE 的核心优势
可读性：将复杂逻辑拆分为命名步骤
可维护性：修改单个 CTE 即可影响全局
性能优化：PostgreSQL 12+ 支持MATERIALIZED / NOT MATERIALIZED控制物化
递归能力：处理树形/图结构数据（如组织架构、BOM）
逻辑复用：同一 CTE 可被多次引用
1.3 CTE vs 临时表 vs 视图
| 特性 | CTE | 临时表 | 视图 |
|---|---|---|---|
| 生命周期 | 单次查询 | 会话级 | 永久 |
| 存储 | 内存/临时文件 | 临时文件 | 无（逻辑定义） |
| 索引 | 不支持 | 支持 | 不支持（但基表索引可用） |
| 递归 | 支持 | 不支持 | 不支持 |
| 适用场景 | 复杂查询分解 | 大数据量中间结果 | 通用逻辑封装 |
选择建议：
- 单次查询复杂逻辑 →CTE
- 多次查询复用中间结果 →临时表
- 全局通用逻辑 →视图
1.4 CTE 的核心价值
| 维度 | 价值 |
|---|---|
| 可读性 | 将“意大利面条式 SQL”变为“乐高积木式逻辑” |
| 可维护性 | 修改单点，影响全局 |
| 性能 | 避免重复计算，PostgreSQL 12+ 支持智能物化 |
| 能力扩展 | 递归查询解锁树形/图数据处理能力 |
| 工程化 | 使 SQL 成为真正的“声明式编程语言” |
🚀行动建议：
下次遇到复杂查询时，先问自己：
“能否用 3~5 个 CTE 步骤清晰表达逻辑？”
如果答案是 Yes —— 你已经掌握了现代 SQL 的精髓！
二、CTE 基础语法
WITHcte_nameAS(-- 子查询SELECT...)SELECT...FROMcte_name;2.1 多 CTE 链式组合
WITHstep1AS(SELECT...),step2AS(SELECT...FROMstep1),step3AS(SELECT...FROMstep2)SELECT*FROMstep3;注意：CTE 按顺序定义，后续 CTE 可引用前面的 CTE
三、实战场景
3.1 场景1：计算用户活跃度指标（替代嵌套子查询，提升可读性）
需求：
- 找出 2023 年注册的美国用户
- 统计其支付订单数、总消费额
- 筛选高价值用户（消费 > $1000）
1、传统写法（嵌套地狱）
SELECTu.name,paid_orders,total_spentFROMusers uJOIN(SELECTuser_id,COUNT(*)ASpaid_orders,SUM(amount)AStotal_spentFROMordersWHEREstatus='paid'GROUPBYuser_idHAVINGSUM(amount)>1000)oONu.id=o.user_idWHEREu.country='US'ANDu.created_at>='2023-01-01';2、CTE 写法（清晰分步）
WITHnew_us_usersAS(SELECTid,nameFROMusersWHEREcountry='US'ANDcreated_at>='2023-01-01'),user_spendingAS(SELECTuser_id,COUNT(*)ASpaid_orders,SUM(amount)AStotal_spentFROMordersWHEREstatus='paid'GROUPBYuser_idHAVINGSUM(amount)>1000)SELECTu.name,s.paid_orders,s.total_spentFROMnew_us_users uJOINuser_spending sONu.id=s.user_id;优势：
- 逻辑分层：先筛选用户，再计算消费
- 中间结果命名清晰（
new_us_users,user_spending） - 易于单独测试每个 CTE
3.2 场景2：多维度聚合分析，避免重复计算（性能优化）
需求：
- 计算每个产品的月度销售额
- 同时输出：当月排名、累计销售额、环比增长率
1、错误写法（重复扫描）
SELECTproduct_id,month,sales,RANK()OVER(PARTITIONBYmonthORDERBYsalesDESC)ASmonthly_rank,SUM(sales)OVER(ORDERBYmonthROWSUNBOUNDEDPRECEDING)AScum_sales,(sales-LAG(sales)OVER(PARTITIONBYproduct_idORDERBYmonth))/NULLIF(LAG(sales)OVER(PARTITIONBYproduct_idORDERBYmonth),0)ASmom_growthFROM(SELECTproduct_id,DATE_TRUNC('month',order_date)ASmonth,SUM(amount)ASsalesFROMordersGROUPBYproduct_id,DATE_TRUNC('month',order_date))t;⚠️ 虽然只扫描一次，但窗口函数逻辑混杂，难以扩展
2、CTE 写法（分步计算）
WITHmonthly_salesAS(SELECTproduct_id,DATE_TRUNC('month',order_date)::DATEASmonth,SUM(amount)ASsalesFROMordersGROUPBYproduct_id,DATE_TRUNC('month',order_date)),ranked_salesAS(SELECT*,RANK()OVER(PARTITIONBYmonthORDERBYsalesDESC)ASmonthly_rankFROMmonthly_sales),cumulative_salesAS(SELECT*,SUM(sales)OVER(ORDERBYmonthROWSUNBOUNDEDPRECEDING)AScum_salesFROMranked_sales)SELECTproduct_id,month,sales,monthly_rank,cum_sales,(sales-LAG(sales)OVER(PARTITIONBYproduct_idORDERBYmonth))/NULLIF(LAG(sales)OVER(PARTITIONBYproduct_idORDERBYmonth),0)ASmom_growthFROMcumulative_salesORDERBYproduct_id,month;优势：
- 每个 CTE 聚焦单一职责
- 后续步骤可直接使用前序结果（如
cumulative_sales基于ranked_sales） - 添加新指标只需新增 CTE，不影响原有逻辑
3.3 场景3：组织架构查询（树形结构），递归 CTE（处理层次数据）
表结构：
CREATETABLEemployees(idINTPRIMARYKEY,nameVARCHAR(100),manager_idINTREFERENCESemployees(id));1、需求 1：查询某员工的所有下属（递归向下）
WITHRECURSIVE subordinatesAS(-- Anchor: 起始节点（CEO）SELECTid,name,manager_id,1ASlevelFROMemployeesWHEREid=1-- CEO IDUNIONALL-- Recursive: 逐级展开下属SELECTe.id,e.name,e.manager_id,s.level+1FROMemployees eJOINsubordinates sONe.manager_id=s.id)SELECT*FROMsubordinates;2、需求 2：查询某员工的完整汇报路径（递归向上）
WITHRECURSIVE reporting_lineAS(-- Anchor: 目标员工SELECTid,name,manager_id,1ASdepthFROMemployeesWHEREid=10-- 目标员工IDUNIONALL-- Recursive: 向上找经理SELECTe.id,e.name,e.manager_id,rl.depth+1FROMemployees eJOINreporting_line rlONe.id=rl.manager_idWHERErl.manager_idISNOTNULL-- 防止无限循环)SELECT*FROMreporting_line;关键点：
RECURSIVE关键字启用递归UNION ALL连接锚点与递归部分- 必须有终止条件（如
manager_id IS NOT NULL）
3.4 场景4：物料清单（BOM）展开
表结构：
CREATETABLEbom(parent_partVARCHAR(50),child_partVARCHAR(50),quantityINT);查询产品 ‘CAR’ 的所有子部件及总用量：
WITHRECURSIVE exploded_bomAS(-- Anchor: 最终产品SELECTparent_partAStop_part,child_part,quantity,1ASlevelFROMbomWHEREparent_part='CAR'UNIONALL-- Recursive: 展开子部件SELECTeb.top_part,b.child_part,eb.quantity*b.quantity,-- 累计用量eb.level+1FROMbom bJOINexploded_bom ebONb.parent_part=eb.child_part)SELECTtop_part,child_part,SUM(quantity)AStotal_quantityFROMexploded_bomGROUPBYtop_part,child_partORDERBYtotal_quantityDESC;3.5 场景5：会话化用户行为日志，数据清洗与预处理
原始数据：user_events (user_id, event_time, event_type)
需求：将连续事件（间隔 < 30 分钟）划分为同一会话
1、CTE 分步实现
WITHordered_eventsAS(-- 按用户和时间排序SELECTuser_id,event_time,LAG(event_time)OVER(PARTITIONBYuser_idORDERBYevent_time)ASprev_timeFROMuser_events),session_flagsAS(-- 标记新会话起点（当前事件与上一事件间隔 > 30 分钟）SELECTuser_id,event_time,CASEWHENprev_timeISNULLOREXTRACT(EPOCHFROM(event_time-prev_time))>1800-- 30分钟=1800秒THEN1ELSE0ENDASis_new_sessionFROMordered_events),session_idsAS(-- 累计求和生成会话IDSELECTuser_id,event_time,SUM(is_new_session)OVER(PARTITIONBYuser_idORDERBYevent_timeROWSUNBOUNDEDPRECEDING)ASsession_idFROMsession_flags)SELECTuser_id,session_id,MIN(event_time)ASsession_start,MAX(event_time)ASsession_end,COUNT(*)ASevents_countFROMsession_idsGROUPBYuser_id,session_idORDERBYuser_id,session_start;优势：
- 将复杂逻辑拆解为：排序 → 标记 → 累计 → 聚合
- 每步可独立验证（如检查
is_new_session是否正确）
四、PostgreSQL 12+ 高级特性：控制 CTE 物化
4.1 默认行为（PostgreSQL 12 前）
- CTE总是物化（Materialized）：先执行 CTE 存入临时表，再供外层查询使用
- 优点：避免重复计算
- 缺点：可能浪费 I/O（如果外层只取少量数据）
4.2 新增控制选项（PostgreSQL 12+）
-- 强制物化（兼容旧版行为）WITHcte_nameASMATERIALIZED(...)-- 禁止物化（内联展开，类似子查询）WITHcte_nameASNOTMATERIALIZED(...)4.3 性能对比示例
-- 场景：CTE 返回 100 万行，但外层只取 10 行-- MATERIALIZED：先写 100 万行到临时表（慢）WITHlarge_cteASMATERIALIZED(SELECT*FROMhuge_table)SELECT*FROMlarge_cteLIMIT10;-- NOT MATERIALIZED：优化器可能只取 10 行（快）WITHlarge_cteASNOTMATERIALIZED(SELECT*FROMhuge_table)SELECT*FROMlarge_cteLIMIT10;💡建议：
- 默认不加关键字（让优化器自动选择）
- 当 CTE 被多次引用 → 用
MATERIALIZED- 当 CTE 数据量大但外层只取少量 → 用
NOT MATERIALIZED
五、常见陷阱与最佳实践
5.1 陷阱 1：CTE 中的 DML（数据修改）
PostgreSQL 允许在 CTE 中执行INSERT/UPDATE/DELETE（称为“Writeable CTE”）：
-- 删除过期订单，并返回删除数量WITHdeleted_ordersAS(DELETEFROMordersWHEREcreated_at<'2020-01-01'RETURNINGid)SELECTCOUNT(*)FROMdeleted_orders;风险：
- 逻辑隐蔽，易被忽略
- 可能导致意外数据修改
建议：
- 仅在必要时使用（如批量清理）
- 添加明确注释
- 避免在业务查询中混用 DML
5.2 陷阱 2：递归 CTE 无限循环
-- 错误：缺少终止条件WITHRECURSIVE infinite_loopAS(SELECT1ASnUNIONALLSELECTn+1FROMinfinite_loop)SELECT*FROMinfinite_loop;-- 永不停止！防护措施：
- 设置最大递归深度：
SETmax_recursive_iterations=1000; - 在递归条件中加入终止逻辑（如
level < 10）
5.3 最佳实践总结
- 命名规范：CTE 名称应清晰表达其作用（如
active_users,monthly_revenue） - 单一职责：每个 CTE 只做一件事
- 避免过度嵌套：超过 5 层 CTE 时考虑拆分为多个查询
- 性能监控：用
EXPLAIN ANALYZE检查 CTE 执行计划 - 递归谨慎：确保有明确终止条件
六、综合案例：电商漏斗分析
需求：计算从浏览 → 加购 → 下单 → 支付的转化率
6.1 表结构
page_views (user_id, product_id, view_time)cart_adds (user_id, product_id, add_time)orders (user_id, order_id, create_time)payments (order_id, pay_time)
6.2 CTE 实现
WITHstep1_viewAS(SELECTDISTINCTuser_idFROMpage_viewsWHEREview_time>='2023-10-01'),step2_cartAS(SELECTDISTINCTca.user_idFROMcart_adds caJOINstep1_view svONca.user_id=sv.user_idWHEREca.add_time>='2023-10-01'),step3_orderAS(SELECTDISTINCTo.user_idFROMorders oJOINstep2_cart scONo.user_id=sc.user_idWHEREo.create_time>='2023-10-01'),step4_payAS(SELECTDISTINCTo.user_idFROMorders oJOINpayments pONo.order_id=p.order_idJOINstep3_order soONo.user_id=so.user_idWHEREp.pay_time>='2023-10-01')SELECT(SELECTCOUNT(*)FROMstep1_view)ASview_users,(SELECTCOUNT(*)FROMstep2_cart)AScart_users,(SELECTCOUNT(*)FROMstep3_order)ASorder_users,(SELECTCOUNT(*)FROMstep4_pay)ASpay_users,ROUND(100.0*(SELECTCOUNT(*)FROMstep2_cart)/(SELECTCOUNT(*)FROMstep1_view),2)ASview_to_cart_rate,ROUND(100.0*(SELECTCOUNT(*)FROMstep4_pay)/(SELECTCOUNT(*)FROMstep1_view),2)ASoverall_conversion;输出：
view_users | cart_users | order_users | pay_users | view_to_cart_rate | overall_conversion -----------|------------|-------------|-----------|-------------------|------------------- 10000 | 2500 | 1200 | 900 | 25.00 | 9.00
