postgresql和sql server支持with+update，mysql 8.0+不支持，oracle需用merge替代；cte能否用于update取决于数据库类型及语法合规性。
CTE 能不能直接用于 UPDATE？先看数据库支持情况
PostgreSQL 和 SQL Server 支持 WITH + UPDATE 的组合，MySQL 8.0+ 不支持；Oracle 需用 MERGE 替代。别在 MySQL 里写 WITH ... UPDATE，会直接报错 ERROR 1064 (42000)。
关键判断点：不是“能不能写”，而是“你用的是哪个数据库”。执行前务必确认版本和语法兼容性。
- PostgreSQL：支持
WITH ... UPDATE ... FROM，可安全引用 CTE 结果做更新依据 - SQL Server：支持
WITH ... UPDATE ... FROM cte_name，但 CTE 必须是可更新的（不能含聚合、DISTINCT、窗口函数等） - MySQL：不支持，必须改用临时表或子查询重写
PostgreSQL 中用 CTE 做带条件的批量 UPDATE
典型场景：根据部门平均薪资，把所有高于该均值的员工薪资上调 5%。中间要算一次部门均薪，再关联员工表更新——这正是 CTE 最适合的模式。
错误写法是把 AVG(salary) OVER (PARTITION BY dept_id) 直接塞进 UPDATE 的 SET 或 WHERE，会导致每行都重算均值，性能差且逻辑易错。
正确写法如下：
WITH dept_avg AS ( SELECT dept_id, AVG(salary) AS avg_salary FROM employees GROUP BY dept_id ) UPDATE employees e SET salary = e.salary * 1.05 FROM dept_avg d WHERE e.dept_id = d.dept_id AND e.salary > d.avg_salary;
注意点：
-
UPDATE ... FROM是 PostgreSQL 特有语法，FROM后只能跟一个 CTE 或表，不能写多个逗号分隔的 CTE - CTE 中不能出现
ORDER BY、LIMIT，否则报错ERROR: ORDER BY in a WITH clause is not allowed - 若需更新多张表（如同时更新
employees和salary_history），得拆成两个独立语句，CTE 无法跨语句复用
SQL Server 中 CTE UPDATE 的硬限制
SQL Server 允许 WITH 定义后紧跟 UPDATE，但 CTE 必须满足“可更新性”：不能含聚合函数、DISTINCT、GROUP BY、窗口函数、子查询，也不能是多表 JOIN 的结果集（除非指定唯一键）。
所以这个写法会失败：
WITH dept_avg AS ( SELECT dept_id, AVG(salary) AS avg_salary FROM employees GROUP BY dept_id ) UPDATE e SET salary = salary * 1.05 FROM employees e INNER JOIN dept_avg d ON e.dept_id = d.dept_id WHERE e.salary > d.avg_salary;
报错：Invalid column name 'avg_salary'，因为 CTE 含 AVG()，不可更新。
可行替代方案：
- 用视图封装聚合逻辑，再在
UPDATE中JOIN视图（视图需满足可更新条件） - 改用临时表：
SELECT dept_id, AVG(salary) INTO #dept_avg FROM employees GROUP BY dept_id，再UPDATE ... JOIN #dept_avg - 把聚合逻辑移到
UPDATE的WHERE子句中，用相关子查询（但性能风险高，慎用）
为什么不能把 CTE 当成“中间缓存”来用？
CTE 默认不物化，尤其在多次引用时。比如你在同一个 UPDATE 里想两次 JOIN 同一个 CTE，PostgreSQL 可能重复扫描基表——这不是 bug，是设计使然。
验证方式：加 EXPLAIN ANALYZE 看执行计划里是否出现多个 Seq Scan on employees。若出现，说明 CTE 被展开而非复用。
解决办法有限：
- PostgreSQL 12+ 可加
MATERIALIZED提示：WITH dept_avg AS MATERIALIZED (SELECT ...)，强制物化 - SQL Server 没等效机制，只能靠临时表
- 别指望 CTE 自动优化性能，它只管逻辑清晰；执行效率仍取决于索引、数据分布和实际执行路径
最常被忽略的一点：CTE 的“临时性”是双刃剑——它不会残留数据，但也意味着每次查询都要重新计算。当业务逻辑需要跨语句复用中间结果时，CTE 就不再是最佳选择。
