cte能替代重复子查询，是最直接有效的方法；只要子查询逻辑固定且不依赖外部参数，用with定义一次即可多次引用，但需注意定义顺序、生命周期限制及数据库版本兼容性。
CTE 能不能替代重复的子查询
能，而且是最直接有效的办法。只要子查询逻辑固定、不依赖外部参数变化，用 WITH 定义一次，后面可以反复引用，SQL 里就不用复制粘贴三遍 SELECT user_id, COUNT(*) FROM orders GROUP BY user_id 这种块了。
常见错误是把 CTE 当成视图或临时表来用：比如在同一个 WITH 块里定义了 active_users，又想在另一个 CTE 里用它做 JOIN 却写错顺序——CTE 必须按定义顺序引用，后定义的不能提前被前一个引用。
- CTE 只在当前查询生命周期有效，不能跨语句复用（想跨语句得建视图或临时表）
- 嵌套太深时（比如 5 层 CTE 套着写），可读性反而下降，不如拆成两个独立查询
- PostgreSQL 和 SQL Server 支持递归 CTE，MySQL 8.0+ 才支持；老版本 MySQL 直接报错
ERROR 1235 (42000): This version of MySQL doesn't yet support 'CTE'
多个 CTE 之间怎么共享中间结果
靠定义顺序和名字引用。第一个 CTE 的结果可以直接被第二个 CTE 的 FROM 或 JOIN 引用，第二个又能被第三个用，但不能倒过来。
典型场景是清洗+聚合两步走：先过滤出有效订单，再按用户统计金额。如果硬写成一层子查询，括号容易数错；用 CTE 就清晰得多：
WITH valid_orders AS ( SELECT * FROM orders WHERE status = 'paid' AND created_at > '2024-01-01' ), user_summary AS ( SELECT user_id, SUM(amount) AS total_spent FROM valid_orders GROUP BY user_id ) SELECT u.name, s.total_spent FROM users u JOIN user_summary s ON u.id = s.user_id;
注意：valid_orders 在 user_summary 里被引用，所以必须定义在前面；如果调换顺序，SQL 会报错 relation "valid_orders" does not exist。
CTE 和内联视图（子查询）性能差多少
多数情况下没差别，现代优化器（如 PostgreSQL 12+、SQL Server 2019+）会把 CTE 当作“可内联的表达式”处理，不会真物化中间结果。但有两个例外要小心：
- 显式加
MATERIALIZED（PostgreSQL 12+）或写成WITH RECURSIVE，会导致强制物化，可能拖慢查询 - 同一个 CTE 被多次引用（比如
SELECT * FROM a JOIN a ON ...），某些数据库（如旧版 SQL Server）可能重复执行，而等价的内联子查询反而只算一次 - MySQL 8.0 对 CTE 默认物化，想避免就得加
/*+ NO_MERGE() */提示，否则EXPLAIN里能看到materialized字样
CTE 复用时参数怎么传进去
CTE 本身不支持参数，这是它和存储过程、函数的本质区别。想让一段逻辑“带参复用”，有三个现实路径：
- 用视图 +
WHERE过滤：把通用逻辑封装进视图，查询时再加条件，比如CREATE VIEW recent_orders AS SELECT * FROM orders WHERE created_at > CURRENT_DATE - INTERVAL '7 days' - 用函数封装（PostgreSQL 支持 SQL 函数返回
TABLE）：写个get_user_stats(start_date DATE)，内部用 CTE 组织逻辑，调用时传参 - 应用层拼接：在 Python/Java 里把 CTE 部分做成模板字符串，用
.format()或参数化注入日期、ID 等，再发给数据库（注意防注入）
硬要在纯 SQL 里“模拟参数”，有人用 SELECT '2024-01-01'::DATE AS start_date 做驱动 CTE，再 JOIN 到主逻辑里，但可读性和维护性很快崩坏，不建议。
真正难的不是写 CTE，而是判断哪里该用、哪里该收手——比如一个 CTE 同时被四个不同业务查询引用，却每次只取其中两列，还加了不同过滤条件，这时候其实该退回去建物化视图或预计算表了。
