不能直接用CTE更新只读视图，因CTE不改变视图不可更新的语义本质；只读视图含聚合、DISTINCT、JOIN等结构导致数据库无法反向定位基表行，故UPDATE+WITH必报错，正确做法是用CTE生成条件集后显式更新基表。
不能直接用公用表表达式（CTE）更新只读视图——这是 SQL 标准和主流数据库（PostgreSQL、SQL Server、Oracle）的硬性限制，不是语法写法问题，而是语义层面不被允许。
为什么 UPDATE + WITH 对只读视图会失败
CTE 本身只是查询的临时命名结果集，不改变底层对象的可更新性。而只读视图通常由以下原因导致不可更新：
- 包含聚合函数（
COUNT()、SUM()）、DISTINCT、GROUP BY、HAVING - 视图定义中含多个基表的
JOIN（尤其无明确键映射时） - 数据库显式设置了
WITH READ ONLY（Oracle）或未满足可更新视图规则（PostgreSQL 要求单表、无复杂表达式等） -
UPDATE语句试图通过 CTE 引用视图时，优化器无法反向解析出唯一、无歧义的基表行定位方式
此时哪怕 CTE 写得再“干净”，执行 UPDATE my_view_cte SET ... 仍会报错，例如 PostgreSQL 报 ERROR: cannot update a view，SQL Server 报 View or function 'xxx' is not updatable。
绕过限制的可行路径：用 CTE 做安全校验，再更新基表
真正能落地的做法是：把 CTE 当作「条件计算器」或「行筛选器」，只用于生成要更新的主键/唯一标识集合，然后在 UPDATE 中显式指向基表，并用该集合约束范围。
例如有只读视图 v_active_users（基于 users 表过滤 status = 'active'），想禁用其中邮箱重复的用户：
WITH dup_emails AS ( SELECT email FROM v_active_users GROUP BY email HAVING COUNT(*) > 1 ) UPDATE users SET status = 'disabled' WHERE email IN (SELECT email FROM dup_emails) AND status = 'active';
关键点：
- CTE
dup_emails不参与更新，只提供安全的条件子集 -
UPDATE直接操作基表users，绕过视图限制 - WHERE 中叠加
status = 'active'是必须的——防止误更新已变更状态的行（CTE 查询快照和 UPDATE 执行存在时间差） - 若基表无主键或唯一约束，需额外加
LIMIT 1（PostgreSQL）或TOP 1（SQL Server）防意外多更
MySQL 用户注意：WITH 在 UPDATE 中的特殊行为
MySQL 8.0+ 支持 WITH 与 UPDATE 结合，但仅限于 CTE 引用**可更新的表或视图**。对只读视图仍会拒绝：
WITH bad AS (SELECT id FROM v_readonly) UPDATE bad SET x = 1; -- ERROR 1288: The target table bad of the UPDATE is not updatable
所以 MySQL 下同样不能跳过基表。更稳妥的方式是用派生表替代 CTE：
UPDATE users
SET status = 'disabled'
WHERE id IN (
SELECT id FROM (
SELECT u1.id
FROM users u1
JOIN users u2 ON u1.email = u2.email AND u1.id < u2.id
) AS dups
);这种写法兼容所有 MySQL 版本，且明确避开视图层。
最易被忽略的是 CTE 的事务隔离级别影响：如果 CTE 查询和后续 UPDATE 分属不同快照（如在 READ COMMITTED 级别），中间可能有其他事务修改了数据，导致“查到的要更新”和“实际更新的”不一致。生产环境务必把整套逻辑包在事务里，并考虑加锁（如 SELECT ... FOR UPDATE 在支持的数据库中）。
