cte不能直接作为update目标，必须通过from子句关联原表；正确写法是with cte定义数据源，update后跟原表名，再from join该cte。
CTE本身不能直接UPDATE，必须配合FROM子句
SQL Server不允许对CTE执行UPDATE语句（哪怕它只引用单表），会报错：Invalid use of side-effecting or time-dependent operator in 'UPDATE' within a CTE。这不是语法写错了，而是引擎限制——CTE在UPDATE中只能当“源”用，不能当“目标”。真正要更新的表必须显式出现在UPDATE关键字后面，而CTE只能放在FROM子句里作为数据源。
正确写法：CTE定义编号逻辑，UPDATE从CTE JOIN原表
核心是把CTE当作带序号的临时结果集，再通过主键或唯一列与原表关联。这样既利用了ROW_NUMBER()的分组/排序能力，又绕过了CTE不可更新的限制。
常见错误是直接写UPDATE cte_name SET ...，这一定失败。正确结构是：
WITH ranked AS (SELECT *, ROW_NUMBER() OVER (ORDER BY created_at DESC) AS rn FROM logs)UPDATE l SET status = 'archived' FROM logs l INNER JOIN ranked r ON l.id = r.id WHERE r.rn
注意两点：一是UPDATE后跟的是原表名logs（或别名l），不是CTE名；二是必须用INNER JOIN明确关联条件，不能省略ON。
多表关联更新时，CTE里不能包含JOIN，否则UPDATE会失败
如果需要根据另一张表的数据来决定更新哪些行（比如只更新有对应订单的用户），CTE里不能提前JOIN目标表。因为SQL Server在解析UPDATE ... FROM时，要求FROM里的源必须是“可寻址的行集”，而含JOIN的CTE可能被优化为不可更新视图。
安全做法是：CTE只做编号，关联逻辑移到UPDATE ... FROM的JOIN部分。例如：
- 错误：
WITH ranked AS (SELECT u.*, ROW_NUMBER() OVER (...) AS rn FROM users u JOIN orders o ON u.id = o.user_id)→ 后续UPDATE大概率报错 - 正确：
WITH ranked AS (SELECT id, ROW_NUMBER() OVER (...) AS rn FROM users)，然后UPDATE u SET flag = 1 FROM users u INNER JOIN ranked r ON u.id = r.id INNER JOIN orders o ON u.id = o.user_id WHERE r.rn
TOP + CTE组合容易忽略的性能陷阱
CTE本身不物化，但ROW_NUMBER()必须扫描并排序全部符合条件的行才能编号。如果你加了WHERE过滤条件（比如WHERE status = 'pending'），一定要确保该字段上有索引。否则即使只想要前10条，SQL Server也可能先扫全表再排序。
另一个坑是ORDER BY字段存在大量重复值时，ROW_NUMBER()的物理排序顺序不确定，导致每次执行返回的“前N条”不一致。解决办法是在ORDER BY末尾加上唯一列，例如：ORDER BY created_at DESC, id DESC。
最后提醒：CTE方式比纯UPDATE ... FROM (SELECT TOP N ...)多一层嵌套，但优势在于逻辑清晰、易调试；若N很大（如上万），优先考虑用TOP (N) WITH TIES配合RANK()，避免编号开销。
