答案是“syntax tree depth limit exceeded”错误源于phpMyAdmin自研PMA_SQP解析器硬编码的约100层嵌套限制，与upload_max_filesize等上传配置无关；该限制发生在SQL接收后的解析阶段，唯一可靠绕过方式是使用mysql命令行直接导入。
phpmyadmin 报错 “syntax tree depth limit exceeded” 不是 sql 本身写错了，而是它内置的 sql 解析器（基于 phpmyadmin 自研的 pma_sqp）对嵌套结构的递归深度做了硬性限制，默认仅允许约 100 层嵌套。遇到含深层子查询、长链 join、复杂 cte 或自动生成的 orm 导出 sql（如 django/sqlalchemy 大量嵌套 select）时，极易触发。
为什么改 upload_max_filesize 没用？
这个错误和文件上传大小完全无关，它发生在 phpMyAdmin 已成功接收 SQL 内容之后的解析阶段。你调大 post_max_size、memory_limit 甚至重启 PHP 都不会影响该限制——它由 phpMyAdmin 的 PHP 代码控制，不是 PHP 引擎或 MySQL 的配置。
- 错误只在 phpMyAdmin Web 界面执行导入时出现，命令行
mysql客户端完全不受影响 - 即使是一个只有几 KB 的 SQL 文件，只要含 100+ 层嵌套括号或子查询，也会报此错
- phpMyAdmin 5.0+ 版本仍沿用该限制，官方未提供配置开关，源码里写死在
libraries/classes/SqlParser/Utils/Query.php中
绕过语法树深度限制的实操路径
没有“调大深度”的安全配置项，只能换方式处理：
- 用
mysql命令行直导：上传 SQL 文件到服务器（如/www/backup/query.sql），执行mysql -u root -p database_name 。MySQL 服务端解析器无此限制 - 拆分嵌套逻辑：把最外层主查询单独拎出，把深层子查询结果先
CREATE TEMPORARY TABLE AS SELECT ...存成临时表，再在外层查询中JOIN这个临时表。这样每段 SQL 的嵌套深度就降下来了 - 禁用 phpMyAdmin 的语法高亮与校验（临时）：在
config.inc.php中加一行$cfg['SQP']['fmtEnable'] = false;，可跳过部分解析步骤，但不保证 100% 规避，仅作尝试
哪些 SQL 结构最容易踩中这个坑？
别只盯着 SELECT * FROM (SELECT * FROM (...)) 这种显式嵌套——以下写法同样危险：
- ORM 生成的多级关联查询，例如 Laravel 的
with('user.posts.comments')导出后变成三层子查询嵌套 - 含大量
UNION ALL的语句，每个分支若自身有嵌套，总深度会累加 - JSON_EXTRACT 或 JSON_TABLE 套多层函数调用，如
JSON_EXTRACT(JSON_EXTRACT(...), '$.a.b.c') - MySQL 8.0+ 的 CTE 递归查询（
WITH RECURSIVE），若迭代次数超限，解析器会按展开层数计数
真正难察觉的是：错误提示里的 “line X” 行号往往指向嵌套最深那一层的开头，但你得手动展开所有括号才能数清到底嵌了多少层——不如直接切命令行。
立即学习“PHP免费学习笔记（深入）”；
