CTE是分步拆解与验证复杂查询的思维工具，非语法糖；应先逻辑拆解再写CTE，命名需语义明确；中间结果可复用、可独立验证；避免过度拆分，仅当需多次引用、需解释或含重逻辑时才用；递归CTE须设终止条件与层级限制。
CTE（Common Table Expression）不是语法糖，而是把复杂查询“分步写、分步验”的思维工具。用得好，能大幅降低逻辑混乱和调试成本。
先想清楚每一步要算什么，再写 CTE
别一上来就堆 WITH。先在纸上或注释里拆解业务逻辑：比如“查上月销售额 Top 10 的客户，再看他们今年复购率”。这天然就是两步——第一步筛出 Top 10 客户，第二步关联今年订单算复购。每个步骤对应一个 CTE，名字要见名知意（如 last_month_top10、rebuy_stats），不追求短，追求一读就懂。
把“中间结果”当成临时视图来用
CTE 的核心价值是让中间结果可复用、可验证。比如计算用户生命周期价值（LTV）时，常需：用户首单时间、总消费、最近下单时间、订单频次。把这些分别写成独立 CTE，不仅主查询更清爽，还能单独执行某一个 CTE 查数据是否合理：
- first_order：按 user_id 取 min(order_date)
- total_spend：按 user_id 求 sum(amount)
- last_order：按 user_id 取 max(order_date)
- order_count：按 user_id 计数
这样改逻辑时，只动对应 CTE，不影响其他部分；查问题时，也能快速定位是哪一步数据异常。
避免嵌套过深，该用 JOIN 就用 JOIN
CTE 不是万能嵌套器。如果某个 CTE 只被引用一次，且逻辑简单（比如只是加个 is_vip 标志），直接写在主查询里更直观。过度拆分会拉长代码、增加阅读跳转成本。判断标准很简单：这个结果后续是否会被多次引用？是否需要独立命名和解释？是否涉及多表聚合/过滤等较重逻辑？满足任一，才值得单独提成 CTE。
递归 CTE 要明确终止条件，先画执行路径
处理树形结构（如部门上下级、BOM 物料清单）时，递归 CTE 很有用，但容易陷入无限循环。动手前先确认：起始层是谁？怎么向下找下级？什么时候停止？ 比如查某部门的所有子部门，锚点 CTE 是该部门本身，递归部分 JOIN dept 表找 parent_id = 上层 dept_id，终止条件隐含在 JOIN 不匹配时自动结束。务必在递归 CTE 中加上层级字段（level）和防止死循环的限制（如 MAXRECURSION 在 SQL Server 中，或 LIMIT 在某些方言中）。
