cte本身不能直接update或delete，标准sql中它仅为只读结果集；实际操作需借助cte定位目标行，再通过update...from或子查询作用于底层表，postgresql等少数数据库除外。
CTE 本身不能直接 UPDATE 或 DELETE
SQL 标准中，WITH 定义的 CTE 是只读结果集，不支持在 UPDATE 或 DELETE 语句中直接对 CTE 名称执行写操作（比如 UPDATE cte_name SET ...）。你看到的“用 CTE 更新”其实是借助 CTE 先定位目标行，再通过 UPDATE ... FROM 或子查询方式作用于底层表。
PostgreSQL 中可直接用 WITH + UPDATE/DELETE（带 RETURNING）
PostgreSQL 是少数原生支持在 WITH 后接 UPDATE 或 DELETE 的数据库，且能引用前面定义的 CTE：
WITH stale_orders AS ( SELECT id FROM orders WHERE status = 'pending' AND created_at
- CTE 用于预计算要更新的主键集合，提升可读性与复用性（比如后续还想
INSERT INTO logs记录） -
RETURNING可立即拿到被更新的行，避免再查一遍 - 注意：不能在
UPDATE的FROM子句里直接 JOIN CTE（PostgreSQL 14+ 支持，但语义不同，慎用）
MySQL 和 SQL Server 需用 JOIN 或子查询配合 CTE
MySQL 8.0+ 和 SQL Server 支持 CTE，但不支持 WITH ... UPDATE。必须把 CTE 当作“条件生成器”，嵌入到标准 DML 中：
SQL Server 示例（用 CTE 定义待删用户，再关联删除）：
WITH inactive_users AS ( SELECT user_id FROM users WHERE last_login
- MySQL 不支持
DELETE ... JOIN语法中的 CTE 别名直接参与，得改用子查询：DELETE FROM users WHERE user_id IN (SELECT user_id FROM (CTE definition) AS tmp) - 若 CTE 返回大量行，
IN (SELECT ...)在 MySQL 中可能触发全表扫描，建议确保子查询有索引支撑user_id - SQL Server 的
DELETE ... FROM ... JOIN写法更高效，但需注意别名绑定规则 ——DELETE u中的u必须和FROM中的别名一致
CTE 更新的常见翻车点
不是所有 CTE 都能安全用于 DML 条件构造：
- CTE 包含聚合（
GROUP BY）、窗口函数（ROW_NUMBER()）或去重（DISTINCT）时，可能丢失原始行标识，导致误删/漏更 —— 检查 CTE 输出是否仍保留底层表主键 - 在 PostgreSQL 中对 CTE 做多层嵌套更新（如
WITH a AS ..., b AS (SELECT * FROM a) UPDATE ...），某些版本会报错“relation not found”，建议扁平化或拆成临时表 - Oracle 用户注意：12c+ 支持
WITH ... UPDATE，但仅限单表且 CTE 必须是可更新的（不含聚合、连接等），实际限制比 PostgreSQL 更严
真正容易被忽略的是：CTE 的执行时机。它不是视图，每次被引用都会重新计算 —— 如果你在同一个语句里多次引用同一 CTE（比如先 UPDATE 再 INSERT log），它可能返回不同结果。需要确定性行为时，优先考虑 CREATE TEMP TABLE。
