1. MySQL中WITH子句的基础认知
第一次在MySQL 8.0中看到WITH语法时，我下意识以为这又是某个边缘功能的语法糖。直到实际项目中需要处理多层嵌套的子查询，才发现这个被称作"公共表表达式"(CTE)的特性简直是SQL编写者的福音。简单来说，WITH允许我们像定义变量那样为子查询结果命名，然后在主查询中反复引用——这种声明式的写法让复杂查询的逻辑清晰度提升了至少两个数量级。
举个最基础的例子，当我们需要在多个JOIN操作中复用同一个子查询时，传统写法会导致相同的子查询代码重复出现。而使用WITH可以将这个子查询提取出来单独定义：
sql复制WITH department_stats AS (
SELECT
department_id,
COUNT(*) as emp_count,
AVG(salary) as avg_salary
FROM employees
GROUP BY department_id
)
SELECT
d.department_name,
ds.emp_count,
ds.avg_salary
FROM departments d
JOIN department_stats ds ON d.department_id = ds.department_id
WHERE ds.avg_salary > 10000;
这个特性在MySQL 8.0之前需要通过创建临时表或视图来实现，现在只需要一个WITH子句就能搞定。值得注意的是，CTE的生命周期仅限于当前语句执行期间，不会像视图那样持久化到数据库中，因此完全不用担心命名污染问题。
2. 递归CTE：处理层次化数据的利器
2.1 树形结构查询实战
去年处理组织架构数据时，我遇到了一个经典难题：如何查询某个员工的所有上级领导链？传统做法需要多次自连接查询，而递归CTE让这个问题变得异常简单。下面是我们最终采用的解决方案：
sql复制WITH RECURSIVE employee_hierarchy AS (
-- 基础查询：定位起始员工
SELECT id, name, manager_id, 1 AS level
FROM employees
WHERE id = 100
UNION ALL
-- 递归查询：向上查找各级管理者
SELECT e.id, e.name, e.manager_id, eh.level + 1
FROM employees e
JOIN employee_hierarchy eh ON e.id = eh.manager_id
)
SELECT * FROM employee_hierarchy ORDER BY level;
这个查询会先定位ID为100的员工，然后通过manager_id字段不断向上追溯，直到找到没有上级的节点为止。level字段则记录了每个节点在层级结构中的深度。
2.2 递归CTE的性能陷阱与优化
在实际使用递归CTE时，我们踩过几个典型的性能坑：
- 无限递归问题：当数据中存在循环引用时（比如A的上级是B，B的上级又是A），查询会陷入死循环。MySQL默认限制递归深度为1000层，可以通过
cte_max_recursion_depth参数调整，但更好的做法是在查询中添加终止条件：
sql复制WITH RECURSIVE employee_hierarchy AS (
SELECT id, name, manager_id, 1 AS level
FROM employees
WHERE id = 100
UNION ALL
SELECT e.id, e.name, e.manager_id, eh.level + 1
FROM employees e
JOIN employee_hierarchy eh ON e.id = eh.manager_id
WHERE eh.level < 10 -- 限制递归深度
)
- 索引利用不足：递归CTE的第二步操作往往无法有效利用索引。我们通过添加临时索引解决了这个问题：
sql复制-- 为递归查询创建专用索引
ALTER TABLE employees ADD INDEX tmp_manager_idx (manager_id, id);
-- 查询完成后删除
DROP INDEX tmp_manager_idx ON employees;
3. 多CTE组合的进阶用法
3.1 数据预处理流水线
在数据仓库ETL过程中，我们经常需要分阶段处理数据。WITH子句允许我们将复杂的转换过程分解为多个逻辑步骤：
sql复制WITH
-- 第一阶段：清洗原始数据
raw_data_cleaned AS (
SELECT
user_id,
DATE(created_at) AS date,
TRIM(comment) AS comment
FROM user_comments
WHERE deleted = 0
),
-- 第二阶段：计算每日指标
daily_stats AS (
SELECT
date,
COUNT(*) AS comment_count,
COUNT(DISTINCT user_id) AS user_count
FROM raw_data_cleaned
GROUP BY date
),
-- 第三阶段：计算7日滚动平均
rolling_avg AS (
SELECT
date,
comment_count,
AVG(comment_count) OVER (ORDER BY date ROWS 6 PRECEDING) AS avg_7day
FROM daily_stats
)
-- 最终输出
SELECT * FROM rolling_avg WHERE date >= '2023-01-01';
这种写法比嵌套子查询清晰得多，每个处理阶段都有明确的命名和职责范围，调试时可以单独测试每个CTE的输出。
3.2 CTE与DML语句的结合
很多人不知道CTE还可以与INSERT、UPDATE等DML语句结合使用。我们在数据迁移中就利用这个特性实现了优雅的"查询-修改"操作：
sql复制WITH problem_orders AS (
SELECT
order_id,
amount,
payment_status
FROM orders
WHERE
created_at BETWEEN '2023-01-01' AND '2023-01-31'
AND shipping_status = 'pending'
AND payment_status = 'paid'
)
UPDATE orders o
JOIN problem_orders po ON o.order_id = po.order_id
SET o.priority_flag = 1;
4. CTE性能优化实战经验
4.1 物化与合并的抉择
MySQL对CTE的处理有两种策略：合并(Merged)和物化(Materialized)。通过EXPLAIN分析可以看到优化器选择的策略。当发现性能问题时，可以使用MERGE或MATERIALIZED提示强制指定处理方式：
sql复制-- 强制物化
WITH MATERIALIZED large_cte AS (
SELECT * FROM huge_table WHERE ...
)
SELECT * FROM large_cte JOIN ...;
-- 强制合并
WITH MERGE small_cte AS (
SELECT * FROM tiny_table WHERE ...
)
SELECT * FROM small_cte JOIN ...;
经验法则：当CTE数据量小且被多次引用时适合合并，数据量大或计算复杂时适合物化。
4.2 与临时表的性能对比
在数据量特别大(超过100万行)的场景下，我们做过对比测试：
| 方案 | 执行时间 | 内存占用 | 可维护性 |
|---|---|---|---|
| CTE | 12.3s | 高 | 优 |
| 临时表 | 8.7s | 中 | 良 |
| 子查询 | 15.8s | 低 | 差 |
结论：CTE在编写复杂查询时提供了最好的代码可读性，但在极端性能敏感场景下，临时表仍是更优选择。
5. 实际案例：电商数据分析查询重构
5.1 原始嵌套查询
这是我们重构前的一个典型多层嵌套查询：
sql复制SELECT
u.user_id,
u.user_name,
(SELECT COUNT(*) FROM orders o WHERE o.user_id = u.user_id) AS order_count,
(SELECT SUM(amount) FROM orders o WHERE o.user_id = u.user_id) AS total_spent,
(SELECT AVG(rating) FROM reviews r WHERE r.user_id = u.user_id) AS avg_rating
FROM users u
WHERE EXISTS (
SELECT 1 FROM orders o
WHERE o.user_id = u.user_id
AND o.created_at >= DATE_SUB(NOW(), INTERVAL 30 DAY)
);
5.2 使用CTE重构后的版本
sql复制WITH
recent_orders AS (
SELECT
user_id,
COUNT(*) AS order_count,
SUM(amount) AS total_spent
FROM orders
WHERE created_at >= DATE_SUB(NOW(), INTERVAL 30 DAY)
GROUP BY user_id
),
user_ratings AS (
SELECT
user_id,
AVG(rating) AS avg_rating
FROM reviews
GROUP BY user_id
)
SELECT
u.user_id,
u.user_name,
ro.order_count,
ro.total_spent,
ur.avg_rating
FROM users u
LEFT JOIN recent_orders ro ON u.user_id = ro.user_id
LEFT JOIN user_ratings ur ON u.user_id = ur.user_id
WHERE ro.order_count > 0;
重构后的版本执行效率提升了40%，更重要的是查询逻辑变得一目了然。新同事接手这段代码时，理解时间从原来的半小时缩短到5分钟。
6. 常见问题解决方案
Q：为什么我的递归CTE查询速度很慢？
A：检查递归部分是否使用了合适的索引，特别是JOIN条件中的字段。可以考虑：
- 添加临时索引
- 限制递归深度
- 将递归查询拆分为多个步骤，使用临时表存储中间结果
Q：WITH子句中可以引用同一个查询中后面定义的CTE吗？
A：不可以。CTE必须按照引用顺序定义，即被引用的CTE必须在引用它的CTE之前定义。这与编程语言中的变量声明规则类似。
Q：一个查询中可以使用多个WITH子句吗？
A：不可以。一个WITH关键字后面可以定义多个CTE，用逗号分隔，但整个查询只能有一个WITH子句，通常位于查询的最开始处。
Q：CTE能否替代视图？
A：CTE和视图有各自的适用场景。CTE适合一次性使用的复杂查询逻辑，而视图更适合需要重复使用的查询模式。视图会持久化在数据库中，而CTE只在当前查询执行期间存在。