MySQL CTE实战：公用表表达式语法、递归查询与避坑指南-代码聚汇网

MySQL CTE实战：公用表表达式语法、递归查询与避坑指南

故小里·2026-09-03·阅读 196 GEO检测（免费）

MySQLCTE公用表表达式

|难度：普通|阅读约 21 分钟

接手过不少老系统的SQL，最头疼的就是那种一眼望不到头的多层嵌套子查询——SELECT套着SELECT，后面还跟着一堆WHERE EXISTS和聚合。每次想改一个条件，得先在脑子里把整个查询倒着演算一遍，不然根本不知道哪里该改。后来MySQL 8.0终于支持了CTE（Common Table Expression，公用表表达式），我才算真正体会到什么叫“SQL写起来像流水线一样顺”。这篇就围绕MySQL里的CTE，把语法、使用场景、递归查询、组合玩法，还有那些不跑一遍根本发现不了的坑，一次性讲透。

这篇内容适合正在做数据统计、报表开发、后台管理的开发同学，也适合准备面试时被问到“你平时是怎么处理复杂SQL”的人。看完之后，你会知道怎么把一团乱麻的嵌套查询拆成一段段有名字的临时查询块，也会知道递归CTE在组织架构、日期补齐、物料清单这类层级数据查询里到底怎么落地。

1. 当年绕来绕去的子查询，现在可以拆成一条流水线

1.1 一个让我决定重构的旧SQL

先看一个最常见又很典型的场景。假设有张订单表，需求是找出每个商品分类下销量最高的那个商品，并且要带出该分类的总销量。

在MySQL 5.7年代，最自然的写法就是用二层甚至三层子查询：

sql复制SELECT
    c.category_name,
    t.product_name,
    t.sale_cnt,
    t.category_total
FROM (
    SELECT
        category_id,
        product_name,
        sale_cnt,
        SUM(sale_cnt) OVER (PARTITION BY category_id) AS category_total,
        ROW_NUMBER() OVER (PARTITION BY category_id ORDER BY sale_cnt DESC) AS rn
    FROM (
        SELECT
            category_id,
            product_name,
            SUM(sale_cnt) AS sale_cnt
        FROM order_detail
        GROUP BY category_id, product_name
    ) d
) t
JOIN category c ON c.category_id = t.category_id
WHERE t.rn = 1;

这段SQL还不算长，但已经有三个问题：

可读性差：从内层小查询到外层大查询，阅读顺序是反着的。别人看代码时得先从最里面一层往外读，逻辑越复杂脑子越乱。
没法分步调试：中间某层结果是不是对的？没法单独抽出来跑，只能靠整段执行后肉眼判断。
复用困难：如果后面同一个外查询还要再次使用中间计算结果，只能再写一遍子查询，SQL体积马上膨胀。

CTE就是冲着这几个痛点来的。它允许你在SELECT、UPDATE、DELETE语句前面先用WITH定义一个或多个“有名字的临时查询块”，主查询再像查普通表一样去引用它。它在逻辑上等价于派生表（Derived Table），但最大的区别是：它把一段复杂计算从“塞在FROM子句里”变成了“提出来放在最前面”。

1.2 WITH语法的基本形态

先看基础语法：

sql复制WITH cte_name (column_list) AS (
    subquery
)
SELECT ...
FROM cte_name;

cte_name是你给这段子查询起的名字，column_list可以省略，省略时直接沿用子查询输出的列名。如果子查询里有重复列名或需要重命名，用column_list会更清晰。一个WITH中可以同时定义多个CTE，用逗号分隔，后面的CTE可以引用前面已经定义好的CTE。

还是刚才那个分类销量Top 1需求，用CTE拆开写：

sql复制WITH
product_sales AS (
    SELECT
        category_id,
        product_name,
        SUM(sale_cnt) AS sale_cnt
    FROM order_detail
    GROUP BY category_id, product_name
),
ranked AS (
    SELECT
        category_id,
        product_name,
        sale_cnt,
        SUM(sale_cnt) OVER (PARTITION BY category_id) AS category_total,
        ROW_NUMBER() OVER (PARTITION BY category_id ORDER BY sale_cnt DESC) AS rn
    FROM product_sales
)
SELECT
    c.category_name,
    t.product_name,
    t.sale_cnt,
    t.category_total
FROM ranked t
JOIN category c ON c.category_id = t.category_id
WHERE t.rn = 1;

我第一次这么写之后的感受是：读这段SQL就像在看一条组装流水线。product_sales负责做最基础的分类汇总，ranked在这个基础上做窗口排序，最后主查询负责关联维表和过滤。每层都有明确的名字和职责，谁出问题查谁就行。

1.3 作用域和可见性

CTE不是临时表，它不会真的在数据库里建一个物理对象。它更像一个“只活在当前这条SQL里的命名查询块”。也就是说：

CTE只在定义它的那条语句内有效，下一条SQL想引用同一个名字？不行，得重新定义。
CTE的作用域是“从定义位置往后”。同一条WITH里，前面定义的CTE能被后面定义的CTE引用，反过来不行。
如果CTE名和真实表名冲突，在同一查询中CTE名优先生效，但建议别这么干，容易把后续维护的人绕晕。

提示：CTE的生命周期只有一条SQL。如果同一个结果要被多条SQL反复使用，那时候该考虑的是视图、临时表或者存储过程，而不是CTE。

把CTE当成“给SQL分段命名”的工具来理解，后面所有的用法都是这个思路的延展。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. CTE让业务SQL从嵌套地狱变成可读的步骤链

2.1 每个中间步骤都可以单独拿出来验证

实际开发里，我重构复杂SQL通常会做这样一件事：把一段特别绕的嵌套查询先按照业务步骤拆成CTE，然后一层一层验证。这里有一个非常实用的调试技巧，CTE真的给了很大的自由度。

比如要统计“每个用户最近一笔订单中金额超过100元的订单，按金额排序后取前三”，按业务拆解应该是这样：

第1步：找出每个用户最近一笔订单；
第2步：从这些订单里过滤掉金额≤100的；
第3步：对过滤后的结果做全量排序。

写出来的CTE结构自然也是这样：

sql复制WITH
latest_order AS (
    SELECT
        user_id,
        order_id,
        order_amount
    FROM (
        SELECT
            user_id,
            order_id,
            order_amount,
            ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY paid_at DESC) AS rn
        FROM orders
    ) t
    WHERE rn = 1
),
big_order AS (
    SELECT
        user_id,
        order_id,
        order_amount
    FROM latest_order
    WHERE order_amount > 100
)
SELECT
    user_id,
    order_id,
    order_amount
FROM big_order
ORDER BY order_amount DESC
LIMIT 3;

眼尖的朋友会发现，latest_order里面我仍然用了一个内层子查询做ROW_NUMBER()过滤。这是因为MySQL的窗口函数不能直接写在WHERE里面，必须先算出来再在外面过滤。这是MySQL这阶段固有的限制，CTE能帮我们把“计算编号”和“过滤编号”拆成两个步骤，但里层不得不套一下。别嫌丑，实际项目里这种写法非常常见。

最关键的是调试过程：如果你怀疑“每个用户最近一笔订单”的结果不对，不需要跑完整段SQL，直接把最后的主查询那三行临时去掉，改成：

sql复制SELECT * FROM latest_order;

先单独验证这一段，确认没问题再跑后面的步骤。这在老写法里根本做不到——老代码的子查询嵌在主查询中间，要单独跑就得复制粘贴出来，有时还得把外层引用到的列名一并处理，麻烦得很。

2.2 同一份业务逻辑只需要定义一次

CTE另一个很实用的能力，是在同一条SQL中把一份业务逻辑定义一次，然后被多个地方引用。

举个报表场景。你想统计“本月已下单用户”里不同注册渠道的用户数，还要同时看看这些用户中又有多少人之前买过某类商品。如果没有CTE，很可能写成这样：先用两个子查询分别圈定本月活跃用户和购买过目标类目的用户，然后在外面做关联。这两个子查询里“本月已下单用户”的筛选逻辑可能写两遍。

用CTE可以把“本月下单用户”这个基础集合作成一个公共起点：

sql复制WITH
active_user AS (
    SELECT DISTINCT user_id
    FROM orders
    WHERE paid_at >= '2025-01-01'
      AND paid_at < '2025-02-01'
)
SELECT
    u.channel,
    COUNT(DISTINCT au.user_id) AS active_user_cnt,
    COUNT(DISTINCT CASE WHEN oi.user_id IS NOT NULL THEN au.user_id END) AS bought_target_cnt
FROM active_user au
JOIN users u ON u.user_id = au.user_id
LEFT JOIN (
    SELECT DISTINCT user_id
    FROM order_item
    WHERE product_id IN (101, 102, 103)
) oi ON oi.user_id = au.user_id
GROUP BY u.channel;

虽然示例里order_item的部分还是子查询，但至少“谁是本月活跃用户”这个业务口径只出现了一次。后期如果口径变化，比如要排除退款用户，只需要在一个地方改，不用满SQL去找。这在实际维护中省下的时间远比想象得多。

2.3 CTE和窗口函数这对组合特别好用

很多复杂统计要用到窗口函数，窗口函数又多用在类似“分组后取前几”“算累计值”“对比上一条记录”的场景。CTE能把这些场景拆成更明确的步骤，很大程度上避免了多层子查询互相包围的困境。

比如要算每个用户“从第一次下单到最近一次下单之间的累计消费额”，可以这样写：

sql复制WITH
user_orders AS (
    SELECT
        user_id,
        order_amount,
        paid_at,
        ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY paid_at ASC)  AS first_rn,
        ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY paid_at DESC) AS last_rn
    FROM orders
),
first_last AS (
    SELECT
        user_id,
        MAX(CASE WHEN first_rn = 1 THEN paid_at END) AS first_paid_at,
        MAX(CASE WHEN last_rn  = 1 THEN paid_at END) AS last_paid_at
    FROM user_orders
    GROUP BY user_id
)
SELECT
    fl.user_id,
    fl.first_paid_at,
    fl.last_paid_at,
    DATEDIFF(fl.last_paid_at, fl.first_paid_at) AS user_active_days,
    SUM(o.order_amount) AS total_amount
FROM first_last fl
LEFT JOIN orders o ON o.user_id = fl.user_id
GROUP BY fl.user_id;

窗口函数负责计算行列内的编号，CTE负责把编号结果暂时命名保存，外层查询再基于这些编号做聚合。步骤拆得越清晰，越不容易出现“算到一半忘了个用户”这种逻辑漏洞。

3. 递归CTE是处理层级和序列的硬核武器

要说CTE最让老MySQL用户惊喜的功能，还得是递归CTE。MySQL 8.0之前，想查一张父子结构的表要一层层在应用里循环，或者用临时表配合存储过程硬算。现在一条递归CTE就能搞定。

3.1 递归CTE的固定结构

先记住递归CTE的基本骨架：

sql复制WITH RECURSIVE cte_name AS (
    -- 1. 锚点成员：初始数据，递归的起点
    SELECT ...
    UNION ALL
    -- 2. 递归成员：引用cte_name自己，每次迭代继续扩展
    SELECT ...
    FROM cte_name
    JOIN ...
)
SELECT * FROM cte_name;

这里必须注意两点：一是要写WITH RECURSIVE，不是WITH；二是递归成员中必须引用CTE自身，同时要有明确的终止条件，否则就成了死循环。

MySQL对递归的默认保护深度是1000层，超过会直接报错。稍后我会单独说这个坑。

3.2 实战场景：组织架构树展开

假设有一张部门表：

sql复制CREATE TABLE department (
    dept_id   INT PRIMARY KEY,
    parent_id INT NULL,
    dept_name VARCHAR(50)
);

插入几行测试数据后，想要查出一棵完整的部门树，并且把每个节点到根节点的完整路径显示出来。老办法要写存储过程或多次JOIN，用递归CTE写就是声明式的：

sql复制WITH RECURSIVE dept_tree AS (
    -- 锚点：根部门
    SELECT
        dept_id,
        parent_id,
        dept_name,
        0 AS depth,
        CAST(dept_name AS CHAR(500)) AS path
    FROM department
    WHERE parent_id IS NULL

    UNION ALL

    -- 递归：关联出每个部门的下级
    SELECT
        d.dept_id,
        d.parent_id,
        d.dept_name,
        t.depth + 1,
        CONCAT(t.path, ' -> ', d.dept_name)
    FROM department d
    JOIN dept_tree t ON d.parent_id = t.dept_id
)
SELECT
    dept_id,
    dept_name,
    depth,
    path
FROM dept_tree
ORDER BY path;

执行后能直接看到类似这样的结果：市场部 -> 品牌组、市场部 -> 投放组。递归部分每次把当前层级的depth加1，再用CONCAT扩展路径。如果表中有坏数据，比如父子互相引用导致环路，这查询会一直递归到报错，后面我会给出应对思路。

3.3 生成连续日期序列，补齐缺失日期

报表开发里还有个高频痛点：某天没有销售数据，但报表依然需要把这个日期补上，销量填0。缺日期时用GROUP BY是不行的，因为本来就没有这一行。常规解法是先生成一张完整的日期序列，再LEFT JOIN业务数据。日期序列用递归CTE生成非常方便：

sql复制WITH RECURSIVE date_range AS (
    -- 锚点：起始日期
    SELECT DATE('2025-01-01') AS sale_date
    UNION ALL
    -- 递归：每天加一天，直到结束日期
    SELECT DATE_ADD(sale_date, INTERVAL 1 DAY)
    FROM date_range
    WHERE sale_date < DATE('2025-01-31')
)
SELECT
    d.sale_date,
    COALESCE(SUM(s.sale_cnt), 0) AS total_sale_cnt
FROM date_range d
LEFT JOIN daily_sales s ON s.sale_date = d.sale_date
GROUP BY d.sale_date
ORDER BY d.sale_date;

这个写法的好处是日期范围完全由递归条件控制，不用去维护一张“万能日期维表”。如果业务里已经有大而全的日期维表，性能当然更好；但只是临时统计、或者要生成近N天的补数脚本时，递归CTE可以说是最轻量的方案。

有人会问：递归生成1万天日期，会不会很慢？实际上MySQL对每日一次的迭代还是有优化空间的，但建议把范围控制好。如果是几万天的跨度，我更倾向于在代码里生成日期数组后传进来，毕竟递归CTE每迭代一层都有开销。

3.4 默认深度1000的坑，以及如何调整

递归CTE默认最大迭代次数是1000。一旦超过，MySQL会直接报错，错误信息类似这样：

text复制Recursive query aborted after 1001 iterations.
Try increasing @@cte_max_recursion_depth to a larger value.

组织架构层级一般不会有那么深，但生成连续日期序列或处理BOM物料多级展开时，超过1000层很容易。要把上限调大，用：

sql复制SET SESSION cte_max_recursion_depth = 100000;

注意这个值是会话级的。如果放在存储过程里，改成过程内SET也可以，但要确认影响范围。我一般只在需要跑长递归的会话里调大，不为整个全局放开。放太大会导致一条写错的递归SQL把数据库CPU跑满，生产环境尤其要小心。

遇到递归CTE性能问题的第一步，永远是先检查递归终止条件写得对不对、连接条件是不是真的能让树收窄。调大深度上限属于“最后一招”，不是第一招。

4. CTE在真实业务场景里的组合玩法

CTE单独拿出来看很简单，但它的价值体现在和窗口函数、DML语句、存储过程等组合使用的时候。

4.1 用CTE做数据清洗，把重复记录删得明明白白

后台系统里经常出现“同一手机号注册了多账号”“同一订单号重复写入明细”这类脏数据。去重要保留哪一条？业务上一般保留ID最小的那条。用CTE可以先把重复行标记出来，再配合DELETE JOIN精确删除。

如下清理一张member表里手机号重复的记录，保留每个手机号中id最小的那条：

sql复制WITH dup_member AS (
    SELECT
        id,
        ROW_NUMBER() OVER (PARTITION BY phone ORDER BY id) AS rn
    FROM member
)
DELETE m
FROM member m
JOIN dup_member d ON m.id = d.id
WHERE d.rn > 1;

执行前先把DELETE临时改成SELECT验证一下：

sql复制WITH dup_member AS (
    SELECT
        id,
        ROW_NUMBER() OVER (PARTITION BY phone ORDER BY id) AS rn
    FROM member
)
SELECT *
FROM member m
JOIN dup_member d ON m.id = d.id
WHERE d.rn > 1;

跑一下，看到的结果正好是要被删的那些垃圾记录，再切回DELETE执行就很有底气。这也是我特别推荐的做法——生产环境动手删数据之前，先干跑一遍SELECT。

注意：CTE本身不能作为多表DELETE的目标表，但在DELETE语句中让它作为关联条件是完全合法的。记住你是要删主表m的行，不是删CTE，别写成DELETE FROM dup_member。

4.2 链式CTE完成统计报表的层层加工

做后台报表的读者应该都有这种经历：需求方要的指标往往不是一步能算出来的，通常需要“先圈范围 → 再算明细指标 → 再按维度汇总 → 最后对比”。每一步都写子查询会太长，用链式CTE能形成清晰的加工链路。

假设要出一张“各渠道本月转化率”的报表，第一步得到“渠道本月新增用户数”，第二步得到“这些用户中下单的人数”，第三步计算转化率。代码如下：

sql复制WITH
new_user AS (
    SELECT
        u.channel,
        COUNT(DISTINCT u.user_id) AS new_user_cnt
    FROM users u
    WHERE u.created_at >= '2025-01-01'
      AND u.created_at < '2025-02-01'
    GROUP BY u.channel
),
order_user AS (
    SELECT
        u.channel,
        COUNT(DISTINCT o.user_id) AS order_user_cnt
    FROM orders o
    JOIN users u ON u.user_id = o.user_id
    WHERE o.paid_at >= '2025-01-01'
      AND o.paid_at < '2025-02-01'
    GROUP BY u.channel
)
SELECT
    n.channel,
    n.new_user_cnt,
    o.order_user_cnt,
    ROUND(o.order_user_cnt / n.new_user_cnt * 100, 2) AS conversion_rate
FROM new_user n
LEFT JOIN order_user o ON o.channel = n.channel
ORDER BY conversion_rate DESC;

这样写，每个CTE的名字本身就是报表指标的说明书。new_user是新增用户，order_user是下单用户，后面主查询只做JOIN和除法。后期如果“下单用户”的口径要改成“支付成功且未退款用户”，只需要修改order_user里WHERE条件，主查询一行都不用变。

4.3 CTE不只是SELECT的专利：也可以参与UPDATE

CTE能出现在UPDATE或DELETE语句之前，这在同步“汇总表”“状态表”时很省事。比如有一张user_order_summary表，每天需要回写每个用户最近一笔订单的last_order_id。用CTE先算出最近一笔订单，再关联UPDATE：

sql复制WITH latest_order AS (
    SELECT
        user_id,
        order_id,
        ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY paid_at DESC) AS rn
    FROM orders
)
UPDATE user_order_summary s
JOIN latest_order l ON s.user_id = l.user_id
SET s.last_order_id = l.order_id
WHERE l.rn = 1;

这个例子里有两个关键点：

CTE中ROW_NUMBER()已经把每个用户的所有订单都排了序，外部关联时加上WHERE l.rn = 1只取每个用户的第一行。
UPDATE语句前直接可以放WITH，但CTE中不能出现对同一张表的写操作，而这里latest_order只是读取orders，所以没问题。

很多同步任务以前要靠存储过程或应用层分批循环来完成，现在一条SQL就能表达清楚，既减少了代码量，也保证了数据口径和应用层逻辑完全一致。

4.4 视图和存储过程里配合使用

CTE没有持久性，所以如果需要长期复用同一条复杂查询，把它封装成视图是更好的方式。视图定义里也能用CTE：

sql复制CREATE VIEW v_user_order_rank AS
WITH user_order_rank AS (
    SELECT
        user_id,
        order_id,
        order_amount,
        ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_amount DESC) AS rn
    FROM orders
)
SELECT *
FROM user_order_rank;

在存储过程中也可以直接使用CTE，只要注意递归深度设置要放在过程内部的会话范围内。不过有一点要提醒：如果一条复杂CTE要在一个事务里被多次调用，并且数据量很大，MySQL不会自动帮你物化缓存结果，所以不要过分依赖“同一个CTE反复引用不耗性能”的错觉。这个在下面一节展开说。

5. 别把CTE当万能：几个必须避开的坑

5.1 CTE不是临时表，别指望它一定能提速

CTE和派生表在逻辑上等价，但优化器可能选择物化，也可能选择合并到外层SQL。MySQL的优化器会基于成本判断。如果你的CTE写得特别复杂，同时在外层被引用了两三次，优化器有时会物化成一张内部临时表，有时不会，这导致很多人困惑：为什么我的CTE会这么慢？

一个更糟糕的情况是：你把一个计算量很大的CTE在同一个查询里引用两次，MySQL可能真的计算两次。因为CTE只是一个“命名的子查询”，不代表它天然只执行一次。

提示：如果某个中间结果数据量特别大，并且后续多条查询都要用到，我更建议你用CREATE TEMPORARY TABLE手动建临时表，然后在需要的列上建索引。临时表能确定性地控制执行计划，CTE做不到这一点。

我在实际项目中就遇到过：一段带窗口函数的CTE被引用两次后，EXPLAIN ANALYZE显示被物化两次，整个查询跑了十几秒。改成临时表后只物化一次，并且临时表的关联列上加了索引，查询耗时降到几百毫秒。所以CTE的价值主要在逻辑可读性和开发效率上，性能问题还是得靠执行计划来判断。

5.2 递归CTE没加终止条件或条件写错，就是一场灾难

递归条件如果写错，最常见的现象是：查询一直跑不停，直到触达cte_max_recursion_depth报错，或事务把临时空间跑满。组织架构表中如果存在环路数据，比如A的parent是B、B的parent又是A，那么递归永远无法到达“叶子节点”，查询会一直膨胀。

应对思路有两种：

第一种，洗数据：要么修掉环路，要么在递归成员中增加未访问节点判断。MySQL的递归CTE没有SQL Server里那种CYCLE子句，所以环路判断只能自己写历史路径判断。
第二种，限制层数：在递归成员WHERE里加上t.depth < 20这类的硬限制，至少保证查询不会无限膨胀。

比如查找某个部门的完整下级树，同时做深度保护：

sql复制WITH RECURSIVE dept_tree AS (
    SELECT dept_id, parent_id, dept_name, 0 AS depth
    FROM department
    WHERE dept_id = 1

    UNION ALL

    SELECT d.dept_id, d.parent_id, d.dept_name, t.depth + 1
    FROM department d
    JOIN dept_tree t ON d.parent_id = t.dept_id
    WHERE t.depth < 20  -- 最多展开20层，防环路
)
SELECT * FROM dept_tree;

这个t.depth < 20在正常树形结构下永远不会触发，只有环路数据才会被限制住。我之前处理一个混乱的历史数据表时，就是靠这个条件先把树查出来，再辅助定位是哪两条数据构成了环路。

5.3 过滤条件放错位置，递归性能天差地别

递归CTE的写法很讲究“剪枝”的时机。如果只是想把部门树中特定层级以下的数据统计出来，绝对不要在递归结束后才在WHERE里过滤，比如：

sql复制-- 不推荐的写法
WITH RECURSIVE dept_tree AS (
    SELECT dept_id, parent_id, dept_name, 0 AS depth
    FROM department
    WHERE parent_id IS NULL

    UNION ALL

    SELECT d.dept_id, d.parent_id, d.dept_name, t.depth + 1
    FROM department d
    JOIN dept_tree t ON d.parent_id = t.dept_id
)
SELECT *
FROM dept_tree
WHERE depth <= 3;

这种写法会老老实实地把整棵树全部展开。如果部门只有几百个，影响不大；如果有几十万级节点，递归全展开后再过滤就很浪费。更好的做法是在递归过程中就把不需要的分支剪掉：

sql复制WITH RECURSIVE dept_tree AS (
    SELECT dept_id, parent_id, dept_name, 0 AS depth
    FROM department
    WHERE parent_id IS NULL

    UNION ALL

    SELECT d.dept_id, d.parent_id, d.dept_name, t.depth + 1
    FROM department d
    JOIN dept_tree t ON d.parent_id = t.dept_id
    WHERE t.depth < 3  -- 递归过程中直接限制层数
)
SELECT *
FROM dept_tree;

两者结果一样，但第二种写法在递归过程中就做了剪枝，参与迭代的数据量大幅减少。凡是层级特别深、节点特别多的递归，都要养成“过滤条件下推”的习惯。

5.4 MySQL 5.7及更老版本不支持CTE

这一点看起来像废话，但在公司里尤其容易踩：开发库是MySQL 8.0，线上还是5.7，或反过来。WITH语法在5.7里直接报语法错误。写了一堆CTE，最后上线前才发现数据库版本不支持，整个排查链路白废。

上线之前先跑一下SELECT VERSION();确认版本，或者在本地准备一个和线上一致的MySQL实例。值得一说的是，MySQL的8.0版本也分阶段演进，8.0.14之后有些派生表优化逻辑还变化过。所以别只看大版本，尽量确认小版本号。如果公司有标准装机镜像，直接按镜像来。

如果是5.7并一直想用CTE，也不是完全无解——可以用派生表临时顶上，或者把复杂逻辑下沉到存储过程里。但这些都只是妥协方案，该升级数据库还是得升级，毕竟8.0不只是多了个CTE，窗口函数、CHECK约束、UNION的改进都是实打实的。

5.5 CTE的调试技巧：一步步把中间结果捞出来看

面对一个多层CTE，最实用的调试方法就是“分段验证”。我自己的操作步骤一般是这样的：

先跑最基础的第一个CTE，末尾临时执行SELECT * FROM 第一个CTE;看看数据长什么样。
确认第一段没问题后，跑第二个CTE，并且从第二个CTE反查第一个CTE的结果引用是否正确。
全程不报错后，再跑完整查询，观察最后输出是否符合预期。
最后用EXPLAIN ANALYZE看执行计划，找出哪一步产生了临时表、哪一步扫描行数最多。

sql复制-- 调试第一步：只看新用户子集
WITH new_user AS (
    SELECT user_id, channel
    FROM users
    WHERE created_at >= '2025-01-01'
)
SELECT * FROM new_user;

调试完记得把这句临时SELECT去掉，恢复成完整业务SQL。老手可能觉得多此一举，但很多新人在写CTE时一旦最终结果不对，根本不知道是哪段出了问题。分步验证是排错成本最低的方式。

也顺便提一下：如果最终结果和预期不一致，优先检查有没有UNION ALL导致的重复行、JOIN有没有一对多翻倍、窗口函数PARTITION BY的字段是否正确。CTE本身不会放大这类逻辑错误，但它让错误的源头更好定位了。

我在实际开发和维护中，逐渐养成了一种“先思考SQL的步骤，再动手写SQL”的习惯。CTE的出现不只是语法上多了一种写法，它让SQL的表达逻辑更接近人脑的思考方式：先圈定范围、再加工指标、最后聚合输出。以前看着就头大的三层嵌套子查询，现在很多都能用一段带名字的CTE链清晰地替代。

尤其是递归CTE，它把“层级数据查询”从“应用层循环+多次SQL”硬生生拉回了SQL声明式的范畴。组织架构、BOM展开、连续日期补齐，这些场景用递归CTE写出来后，维护成本是肉眼可见地下降。当然，CTE不是银弹，复杂计算重复引用时照样有可能慢，该上临时表时不要犹豫。用的时候多跑几次EXPLAIN ANALYZE，留意递归深度限制，把过滤条件下推到递归内部，基本上就能避开绝大多数问题。