prepared statement 本身不会导致栈溢出，但与递归存储过程、深度嵌套调用或 thread_stack 不足叠加时会触发 thread stack overrun；根本原因是每层 prepare/execute 增加栈帧开销，解析复杂动态 sql 易引发深度递归。
Prepared statement 本身不会直接导致堆栈溢出（stack overflow），但当它与递归存储过程、深度嵌套调用或线程栈空间不足叠加时，会触发 Thread stack overrun 或 Stack overflow 错误。真正出问题的不是 PREPARE 语句本身，而是执行上下文里撑爆了线程栈。
为什么 PREPARE + EXECUTE 可能引发栈溢出？
MySQL 的每个客户端连接对应一个线程，该线程有固定大小的栈空间（由 thread_stack 参数控制，默认通常为 192K 或 256K）。当你在存储过程中反复 PREPARE / EXECUTE，尤其是嵌套调用或递归调用中混用动态 SQL，每层调用都会压入栈帧——而 PREPARE 涉及语法解析、参数绑定、执行计划生成等操作，开销比普通语句大。
- 常见诱因：在递归存储过程中每轮都
PREPARE同一条 SQL； - 更隐蔽的情况：使用
PREPARE构造含多层子查询或复杂 JOIN 的动态 SQL，解析阶段深度递归； - 注意：
max_sp_recursion_depth限制的是存储过程调用深度，不约束PREPARE内部解析行为，所以即使设了该值，仍可能栈溢出。
thread_stack 不生效？先确认是否真重启了 mysqld
很多线上问题卡在这一步：改了 my.cnf 里的 thread_stack = 512K，但没重启 MySQL 进程。MySQL 启动后，thread_stack 就固化为线程默认栈大小，运行时无法动态调整。
- 验证是否生效：
SELECT @@thread_stack;—— 输出值必须是你配置的字节数（如 524288）； - 如果仍是旧值，说明配置未加载：检查
my.cnf是否在正确路径（mysqld --help --verbose | grep "Default options"）、是否有多个配置文件冲突； - Linux 下常用重启命令：
sudo systemctl restart mysql或sudo service mysqld restart，不是 reload； - 小内存服务器（如 512MB Linode）慎设过高值，
thread_stack是每个连接独占的，100 并发就吃掉 50MB+，可能挤占 buffer pool。
如何定位是 PREPARE 引发的栈问题？
错误日志里不会直接写 “PREPARE 导致栈溢出”，但结合上下文可判断。典型线索包括：
- 报错信息含
Thread stack overrun或Stack overrun，且发生在存储过程执行期间； - 调用栈里出现
mysql_execute_command→mysql_sql_stmt_prepare→parse_sql等函数回溯（需开启 core dump 或用gdb分析）； - 复现条件明确：仅当某段含
PREPARE的逻辑被执行时出错，注释掉PREPARE部分就正常； - 对比测试：把动态 SQL 改成静态 SQL（如把
SET @sql = CONCAT(...)+PREPARE换成硬编码SELECT ... WHERE id = ?），问题消失。
替代方案：绕开 PREPARE 降低栈压力
不是所有场景都需要 PREPARE。如果只是为了参数化，优先用原生参数绑定；如果是为了拼接表名/列名等无法参数化的部分，尽量控制拼接复杂度。
- 能用
CALL proc_name(?, ?, ...)就别用PREPARE+EXECUTE； - 避免在循环内反复
PREPARE/DEALLOCATE PREPARE，应提至循环外，复用同一句柄； - 动态 SQL 拼接尽量简单：不用嵌套子查询、少用
UNION、避免IN (subquery)结构； - 对超深递归逻辑，改用临时表 + 迭代（
WHILE）代替递归存储过程，彻底避开栈增长路径。
真正棘手的是那种“改了 thread_stack 也不行”的情况——往往说明 SQL 结构本身存在隐式递归或解析爆炸，比如用 PREPARE 构造了带 20 层嵌套 SELECT 的语句。这时候再调栈大小只是掩耳盗铃，得回到 SQL 设计层面砍掉冗余层级。
