cte不能直接update，必须通过update...from（postgresql/sql server）、update...join（mysql 8.0+）或merge/where exists（oracle）作用于基表；cte仅作定位行的可读性辅助。
CTE本身不能直接UPDATE，必须配合其他语法
SQL标准中，WITH定义的CTE只是临时结果集，不支持独立执行UPDATE。你写WITH cte AS (...) UPDATE cte SET ...会报错——常见错误信息是"invalid table name in UPDATE"（PostgreSQL）或"The table '<cte_name>' is ambiguous"</cte_name>（SQL Server）。真正能更新的是底层基表，CTE只起定位作用。
实际做法是把CTE当作子查询的“可读性增强层”，在UPDATE语句中用它提供WHERE条件或关联依据：
- PostgreSQL 和 SQL Server 支持
UPDATE ... FROM cte语法（注意不是UPDATE cte） - MySQL 8.0+ 不允许在
UPDATE中直接FROMCTE，需改用JOIN写法 - Oracle 需用
MERGE或把CTE嵌入UPDATE ... WHERE EXISTS
PostgreSQL：用UPDATE ... FROM + CTE定位行
这是最直观的写法。CTE先算出要更新的行标识（如id），再在UPDATE中JOIN它：
WITH target_rows AS ( SELECT id FROM orders WHERE status = 'pending' AND created_at <p>注意点：</p>
-
FROM后的CTE名不能加AS别名，否则报错 - 必须显式写出
WHERE关联条件，否则变成笛卡尔积更新 - 性能上，CTE会被物化（除非设置
ENABLE_SEQSCAN=off等优化），大数据量时留意执行计划中的CTE Scan节点
SQL Server：CTE后接UPDATE，但目标仍是基表
SQL Server允许把CTE和UPDATE写在同一语句块里，但语法上UPDATE的目标必须是基表名，不是CTE名：
WITH overdue_orders AS ( SELECT order_id, status FROM sales.orders WHERE DATEDIFF(day, order_date, GETDATE()) > 30 ) UPDATE o SET status = 'overdue_archived' FROM sales.orders o INNER JOIN overdue_orders c ON o.order_id = c.order_id;
容易踩的坑：
- 误写成
UPDATE overdue_orders SET ...→ 报错"Invalid object name 'overdue_orders'" - CTE里选了重复
order_id，JOIN后导致一行被多次更新（无报错但逻辑错误） - 没加
INNER JOIN而用LEFT JOIN，可能意外更新NULL匹配行
MySQL 8.0+：用JOIN模拟CTE效果，避免FROM子句限制
MySQL不支持UPDATE ... FROM cte，但允许UPDATE ... JOIN cte。关键是把CTE放在JOIN右侧：
WITH target AS ( SELECT id FROM products WHERE stock = 0 AND last_updated <p>这个写法看似和SQL Server类似，但底层行为不同：</p>
- MySQL的CTE在此处是“不可物化”的（默认
MATERIALIZED=NO），优化器可能将CTE内联展开，所以EXPLAIN里看不到独立CTE节点 - 如果CTE里有窗口函数或递归，MySQL要求显式加
/*+ MATERIALIZE */提示，否则报错 - 别名
p和t必须都出现，漏掉任何一个会导致语法错误
复杂点在于：一旦CTE需要多层嵌套或依赖前序CTE结果，就得拆成多个UPDATE语句，或者改用临时表——CTE在这里只是语法糖，不是通用更新引擎。
