直接原因是解析阶段栈帧耗尽：每层call及隐式嵌套（如标量子查询、with、prepare）均压入栈帧，thread_stack默认192k–256k，3–5层即可能溢出。
MySQL 中 CALL 嵌套调用触发 thread_stack 溢出的直接原因
不是执行慢，是解析阶段就崩了。MySQL 在准备执行嵌套存储过程时，每层 CALL 都会压入一个函数调用栈帧，包含参数、局部变量、返回地址等上下文。默认 thread_stack=128K（Windows）或 192K–256K（Linux），实测 3–5 层深度就可能耗尽——尤其当过程内含游标、临时表、复杂条件分支时，单帧开销远超预期。
thread_stack 调整后仍报错？检查这三类隐式嵌套
即使把 thread_stack 加到 512K，以下情况仍会快速触顶：
- 过程 A 调用过程 B，B 内部又执行了含标量子查询的
SELECT—— 这个子查询在 PREPARE 阶段独立占栈，不计入“过程调用层数”，但实际消耗等同于一次CALL - 使用
WITH RECURSIVE的 CTE 被嵌在过程体中：递归部分单独计数，但非递归 CTE 若被多处引用，每次展开都新增栈帧 - 过程内动态拼接 SQL 并用
PREPARE/EXECUTE执行：预编译动作本身触发二次语法解析，相当于隐式嵌套一层
SQL Server 报 Msg 319 时，别去查执行时间
这个错误明确表示“全局嵌套深度超限 32 层”，和耗时无关。它统计的是所有可展开对象的依赖链总长：
- 视图 v1 引用视图 v2，v2 引用函数 f1，f1 内部再调用过程 p1 → 已占 4 层
- 哪怕 p1 是空过程，只要定义存在，就计入计数
-
sp_depends不可靠（已弃用），应改用sys.dm_exec_describe_first_result_set(N'EXEC p1')或解析OBJECT_DEFINITION追踪真实依赖路径
真正该盯住的不是“层数”，而是中间结果复用失效
栈溢出只是表象。本质是数据库被迫重复计算同一逻辑块：
- 没加
MATERIALIZED提示的 CTE，在嵌套过程中被反复重算（PostgreSQL 尤其明显） - 外层
WHERE条件无法下推到内层过程的基表扫描，导致全量中间结果生成 - LATERAL JOIN 后跟多层嵌套，优化器放弃谓词下推，物化节点激增
重构时优先提取高频共用逻辑为物化视图或临时表，比单纯拆分过程更能根治栈压问题。
