CTE 不能用于多表 DELETE 关联，仅可作为删除目标（DELETE FROM cte）；需改用 IN/EXISTS 子查询或可更新 CTE（如带 ROW_NUMBER() 的单表删除）。
CTE 不能直接用于多表 DELETE 关联语法
SQL Server 不支持 DELETE t1 FROM t1 JOIN t2 ON ... 这类 ANSI 风格的多表删除写法，更不接受 WITH cte AS (...) DELETE FROM t1 JOIN cte ON ... 的混合结构。你如果写了类似语句，大概率会遇到错误：Incorrect syntax near the keyword 'with' 或 A correlated expression is invalid in the context of a DELETE statement。
根本原因在于：CTE 在 DELETE 语句中只能作为「被删目标」（即 DELETE FROM cte_name），不能充当关联源参与 JOIN 删除主表——哪怕你给它起了别名、加了 SELECT * 也不行。
- ✅ 允许：
WITH cte AS (...) DELETE FROM cte WHERE ...（删 CTE 本身） - ❌ 禁止：
WITH cte AS (...) DELETE t FROM target_table t JOIN cte ON ... - ⚠️ 常见误写：
DELETE FROM t JOIN cte ON ...—— SQL Server 直接报错，不是兼容性问题，是语法不合法
想用 CTE 辅助关联删除，必须转为单表 DELETE + 子查询逻辑
真正可行的路径是：把关联条件“折叠”进 CTE，让 CTE 输出待删主表的 ID 或其它唯一键，再用 IN 或 EXISTS 驱动主表删除。这本质是用 CTE 替代冗长的子查询，提升可读性，而非改变执行模型。
例如要删掉 Students 表中所有有成绩记录且成绩低于 60 的学生：
WITH LowScoreStudents AS ( SELECT DISTINCT s.student_id FROM Students s INNER JOIN Scores sc ON s.student_id = sc.student_id WHERE sc.score
- CTE 必须显式返回主表的主键字段（如
student_id），否则无法安全关联 -
IN对空结果集安全，但若 CTE 返回大量 ID，性能可能不如EXISTS；可改写为：WHERE EXISTS (SELECT 1 FROM LowScoreStudents l WHERE l.student_id = Students.student_id) - 务必确认 CTE 中的
JOIN条件不会因 NULL 值漏匹配（比如外连接未加IS NOT NULL过滤）
CTE 删除的典型适用场景：去重、分组后删旧/删冗余
CTE + ROW_NUMBER() 是 SQL Server 中处理“按某字段分组，保留最新/最早一条”的黄金组合，无需临时表，也避开了 DELETE ... JOIN 的语法限制。
比如删 news 表中重复 url 的旧记录，只留 publishtime 最大的那条：
WITH NewsCTE AS (
SELECT ID,
ROW_NUMBER() OVER (PARTITION BY url ORDER BY publishtime DESC) AS rn
FROM news
)
DELETE FROM NewsCTE WHERE rn > 1;
- 关键点：这里
DELETE FROM NewsCTE实际等价于DELETE FROM news，因为 CTE 是对基表的引用（非物化），SQL Server 允许直接删这种“可更新的 CTE” - 必须确保
OVER子句里的排序字段能唯一确定保留哪一行；如果publishtime可能重复，建议追加ID DESC避免不确定性 - CTE 定义前若前面有其他语句（如
SET NOCOUNT ON），必须加分号，否则报Incorrect syntax near the keyword 'with'
比 CTE 更稳的替代方案：用 EXISTS + 相关子查询
当 CTE 写起来绕、或需要跨数据库兼容（如迁移到 PostgreSQL），直接用 EXISTS 往往更直白、更少陷阱。
同样删掉有低分记录的学生：
DELETE FROM Students
WHERE EXISTS (
SELECT 1 FROM Scores
WHERE Scores.student_id = Students.student_id
AND Scores.score
- 不用建 CTE，逻辑扁平，执行计划通常更易优化
- 避免 CTE 物化策略差异带来的性能波动（SQL Server 有时会重算 CTE，而相关子查询天然复用索引）
- 如果子查询里涉及聚合（如
COUNT(*) > 2），记得用GROUP BY和相关列对齐，否则语法报错
CTE 的价值不在“能干更多”，而在把嵌套三层的子查询变成带名字的逻辑块；但一旦你试图让它承担“跨表关联删除”的角色，就踩进了语法禁区。真正的简化，是选对表达方式，而不是硬套语法糖。
