堆栈溢出主因是调用深度失控，非数据量问题：MySQL递归存储过程超max_sp_recursion_depth限、DBeaver等Java客户端解析深层嵌套SQL时AST过深，均触发StackOverflowError；须限递归深度、拆分SQL、建索引防内存溢出混淆。
堆栈溢出不是数据量问题，而是调用深度失控——嵌套查询本身不直接爆栈，但深层递归子查询、过度嵌套的存储过程或客户端驱动层反复解析复杂 SQL，会快速耗尽 JVM 或 MySQL 线程栈空间。
MySQL 存储过程中递归调用触发 StackOverflowError
MySQL 本身不执行“SQL 嵌套查询”导致栈溢出，真正爆栈的是 CALL 递归过程。比如你写了没有终止条件或深度失控的存储过程：
DELIMITER $$
CREATE PROCEDURE deep_loop(IN n INT)
BEGIN
IF n > 0 THEN
CALL deep_loop(n - 1); -- 每次调用压一层栈帧
END IF;
END$$
DELIMITER ;当 n 超过默认限制（max_sp_recursion_depth = 0 表示禁用，非 0 时默认 100），就会报 ERROR 1456 (HY000): Recursive limit exceeded；若手动设为过高值（如 10000）且未加防护，JVM 层或 MySQL 线程栈真会 StackOverflowError。
- 立即检查：运行
SELECT @@max_sp_recursion_depth;，非零值需评估业务是否真需要递归 - 强制设限：执行
SET max_sp_recursion_depth = 20;（建议 ≤ 20，足够覆盖组织树/分类层级） - 更安全替代：用应用层循环 + 缓存路径（如 Redis 存
user_id → [dept_id, parent_id, root_id]） - 注意：MySQL 5.7 不支持 CTE，别误把
WITH RECURSIVE当通用解法——它在 8.0+ 才可用，且仍受cte_max_recursion_depth控制
IN/EXISTS 子查询被错误当成“递归语法”来写
很多人看到 WHERE id IN (SELECT ...) 就以为是“嵌套”，其实这是标准 SQL，不会递归调用。但若内层子查询里又套了另一层 SELECT，且外层结果集大、内层无索引，就会引发海量重复执行——这不是栈溢出，而是内存溢出或连接中断（ERROR 2013 (HY000): Lost connection）。真正的风险点在于“写法诱导优化器物化失败”。
- 典型坏模式：
SELECT * FROM logs WHERE user_id IN (SELECT user_id FROM events WHERE created_at > '2025-01-01' GROUP BY user_id HAVING COUNT(*) > 10)—— 内层没索引，外层百万行，等于扫千万次 events 表 - 改法不是“扁平化”，而是拆断执行链：
CREATE TEMPORARY TABLE tmp_active_users AS SELECT user_id FROM events WHERE created_at > '2025-01-01' GROUP BY user_id HAVING COUNT(*) > 10;，再JOIN logs ON logs.user_id = tmp_active_users.user_id - 关键动作：对
events(created_at, user_id)建联合索引，否则GROUP BY必走Using temporary; Using filesort
DBeaver 或 JDBC 客户端因 SQL 太长/嵌套太深触发 JVM 栈溢出
DBeaver 是 Java 应用，其 SQL 解析器（如 JSQLParser）在处理超长嵌套表达式（如 15 层括号套 CASE WHEN ... END、多层子查询拼接字符串）时，会因 AST 构建深度超限而抛 java.lang.StackOverflowError。这不是数据库问题，是客户端崩了。
- 验证方式：把同一段 SQL 粘进 mysql 命令行执行成功，但在 DBeaver 里报错 → 锁定是客户端解析问题
- 临时绕过：在 DBeaver 中修改 JVM 参数，在
dbeaver.ini末尾加-Xss2m（增大线程栈至 2MB），但治标不治本 - 根本解法：拆分 SQL。例如把 8 层嵌套的
SELECT ... FROM (SELECT ... FROM (SELECT ...)) t改成中间建CREATE TEMPORARY TABLE step1 AS ...，再基于step1查下一层 - 警惕“自动生成 SQL”工具：MyBatis 动态 SQL、JOOQ 的嵌套
DSL.select(...).where(...)链式调用，容易无意写出 20+ 层 AST，上线前用log4j开启 SQL 日志看实际生成语句长度
最易被忽略的一点：**堆栈溢出和内存溢出常被混为一谈，但修复路径完全不同**。前者要砍调用深度、设递归上限、换客户端解析策略；后者得建索引、拆临时表、控 JOIN 基数。查错第一步，先分清报错来源——是 StackOverflowError 还是 OutOfMemoryError，日志里连类名都不同，别一上来就调大 tmp_table_size。
