MySQL 8.0 不支持对 WITH RECURSIVE CTE 直接执行 UPDATE 或 DELETE，因其递归 CTE 为只读逻辑结果集；需先用临时表物化 ID 列表，再 JOIN 更新，并注意去重、环检测与分批处理。
MySQL 8.0 的 WITH RECURSIVE CTE **不能直接用于 UPDATE 或 DELETE 语句**——这是硬性限制，不是写法问题。你无法写出 UPDATE ... FROM (WITH RECURSIVE ...) AS t 这类语法，MySQL 会报错 ERROR 1288 (HY000): The target table s of the UPDATE is not updatable 或类似提示。
为什么 CTE 递归不能直接 UPDATE？
MySQL 的递归 CTE 是只读执行模型：它生成的是一个逻辑上“追加式”的中间结果集（按轮次迭代拼接），而非可寻址的物理行集合。优化器不允许将递归 CTE 作为 DML 的目标表或 JOIN 源表参与更新逻辑——这和 PostgreSQL 或 SQL Server 的行为有本质区别。
常见错误现象包括：
- 写
UPDATE employees e JOIN (WITH RECURSIVE ...) c ON e.id = c.id SET ...→ 报错Recursive reference in a subquery is not allowed - 试图用
UPDATE ... WHERE id IN (SELECT id FROM WITH RECURSIVE ...)→ 若子查询含递归，仍被禁止（除非外层是纯 SELECT） - 误以为
WITH RECURSIVE+UPDATE是标准 SQL 兼容写法 → 实际 MySQL 完全不支持
替代方案：用递归 CTE 生成 ID 列表再 UPDATE
可行路径是分两步：先用递归 CTE 构建需要更新的主键集合（如 id），再用这个结果驱动 UPDATE。关键在于确保中间结果能被物化、可复用。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
实操建议：
- 用
CREATE TEMPORARY TABLE存储递归结果，避免重复计算：CREATE TEMPORARY TABLE tmp_target_ids AS WITH RECURSIVE sub AS ( SELECT id FROM employees WHERE manager_id = 1001 UNION ALL SELECT e.id FROM employees e INNER JOIN sub s ON e.manager_id = s.id ) SELECT id FROM sub;
- 对临时表加索引提升 JOIN 效率：
CREATE INDEX idx_id ON tmp_target_ids (id); - 执行批量 UPDATE：
UPDATE employees e JOIN tmp_target_ids t ON e.id = t.id SET e.status = 'archived';
- 若数据量极大（>10 万行），考虑分批次处理，避免长事务锁表：
WHERE e.id BETWEEN ? AND ?配合循环
容易踩的坑：递归结果未去重导致 UPDATE 多次命中
递归 CTE 默认用 UNION ALL，如果树形结构存在环（比如 A→B→C→A），或业务逻辑允许同一节点被多个父节点引用，CTE 可能产出重复 id。UPDATE 本身不会报错，但会导致同一行被反复更新（例如 status 字段被设多次），语义异常。
预防措施：
- 在生成临时表时强制去重：
SELECT DISTINCT id FROM sub - 检查数据是否存在环：
SELECT * FROM employees WHERE id = manager_id（自引用）或用递归 CTE 加深度限制探测环：WHERE depth - UPDATE 前先验证目标行数：
SELECT COUNT(*) FROM tmp_target_ids，和预期层级规模比对
真正难的不是写出递归逻辑，而是确认哪些行该进、哪些不该进——环检测、NULL 边界、manager_id 是否允许为 0 而非 NULL，这些细节一旦漏掉，UPDATE 就会静默出错。
