MySQL 8.0递归CTE内存占用高源于迭代缓存中间结果集，优化需控制迭代规模、强WHERE剪枝、预清洗数据、索引JOIN字段、显式设cte_max_recursion_depth及用EXPLAIN ANALYZE监控轮次与行数。
MySQL 8.0 中递归 CTE 的内存占用主要发生在迭代过程中缓存每一轮结果集，尤其当层级深、分支多或数据量大时，cte 会把所有中间结果暂存在内存（甚至临时表），极易触发 Memory limit exceeded 或拖慢整个查询。优化核心不是“减少写法复杂度”，而是控制迭代规模、切断无效路径、提前剪枝。
避免递归成员无终止条件或弱过滤
递归成员若缺少强 WHERE 条件，会导致大量无效行进入下一轮迭代，内存随深度指数增长。比如用 WHERE remaining_tags != '' 处理标签字符串时，若原始字段含空格或连续逗号（如 "a,,b"），SUBSTRING_INDEX 可能返回空字符串，使递归持续生成空行，最终撑爆内存。
- 始终在递归部分加长度判断：
WHERE LENGTH(remaining_tags) > 0 AND remaining_tags NOT REGEXP '^[[:space:]]*$' - 对原始字段预清洗：建表时用
TRIM+REPLACE(tags, ' ', '')统一格式，或在锚定查询中先过滤脏数据 - 禁止在递归部分使用无索引字段做 JOIN 条件——这会导致全表扫描并缓存全部匹配行
限制递归深度并主动截断
MySQL 默认 max_recursive_depth 是 1000，但实际业务中极少需要超过 20 层（如分销链、组织架构）。不设限等于放任内存无序增长。
- 显式设置会话级限制：
SET SESSION cte_max_recursion_depth = 25;（注意：全局变量max_recursive_depth已在 8.0.31+ 废弃，改用cte_max_recursion_depth） - 在递归成员中嵌入深度计数和中断逻辑：
WHERE rt.depth ，比依赖系统变量更可控 - 若某轮结果集行数突增（如某节点有 5000 个子节点），可考虑用
LIMIT截断该轮输出（虽牺牲完整性，但保内存）
用覆盖索引减少中间结果体积
递归 CTE 每轮都需从基础表 JOIN 新数据，若 JOIN 字段无索引，MySQL 会读取整行再过滤，大幅增加内存驻留数据量。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 确保递归 JOIN 条件字段有单独索引或复合索引前导列，例如：
INDEX idx_parent (parent_id)对应ur.parent_id = rt.user_id - 只 SELECT 实际需要的列，避免
SELECT *—— 每多一个 TEXT 或 JSON 字段，内存开销翻倍 - 对高频递归场景，可建冗余轻量表（如仅含
user_id,parent_id,level），用空间换内存稳定性
游标分页替代 OFFSET 分页
用 LIMIT 10000, 20 做深度分页时，MySQL 必须生成全部递归结果并缓存前 10000 行，内存峰值直接对标总结果集大小。
- 改用基于主键或深度+ID 的游标分页，例如记录上一页最后的
user_id和depth，下一页查：WHERE (depth, user_id) > (3, 98765) - 递归查询本身不带分页，分页逻辑下沉到外层主查询，且确保外层
ORDER BY字段有索引 - 若必须跳转任意页，优先考虑物化中间结果到临时表（
CREATE TEMPORARY TABLE），再分页查临时表——比在 CTE 内硬扛安全得多
真正卡住性能的往往不是语法写错，而是递归过程中某一层悄悄加载了 10 万行中间数据却没被察觉。每次上线前，务必用 EXPLAIN ANALYZE 看迭代轮数和每轮行数，比看总耗时更能暴露内存隐患。
