MySQL单表列数硬上限为1017列，源于InnoDB行格式中10 bit位图设计（2¹⁰=1024，扣除保留位后为1017）；嵌套查询本身不限字段数，但若引用的表、视图、CTE或派生表已超此限，执行即报ERROR 1117。
嵌套查询本身不直接受字段数限制，但关联的表结构和执行过程会触发1017列硬上限
SQL嵌套查询语句本身没有对SELECT字段数量的语法限制，真正卡住你的是MySQL底层InnoDB的row_format设计：一张表最多允许1017个字段。这个数字来自存储元数据所需的10 bit位图（2¹⁰ = 1024），扣除保留位后实际为1017。一旦嵌套查询涉及的宽表（比如含大量JSON展开字段或历史归档列）接近该阈值，哪怕只是SELECT其中一部分字段，只要FROM子句引用的表已达到或超过1017列，执行时就会报ERROR 1117 (HY000): Too many columns。
- 不是“嵌套导致字段变多”，而是嵌套查询中引用了已经超限的表
- 视图、临时表、CTE均无法绕过此限制——它们最终仍映射到物理表的列定义
- 即使嵌套里只写
SELECT id FROM t，只要t本身有1018列，照样失败
嵌套层级与字段数量是两套独立限制，别混在一起排查
嵌套查询的32层深度限制和表的1017列限制毫无关系，它们作用在数据库不同模块：32层由SQL解析器（parser）控制，防止递归栈溢出；1017列由InnoDB存储引擎（storage engine）强制，关乎记录头结构和内存模板（mysql_row_templ_t）大小。你在错误日志里看到Subquery returns more than 1 row或Unknown column，说明问题出在逻辑或作用域；而Too many columns一出现，直接锁定目标是建表语句或导入脚本。
- 查当前表字段数：
SELECT COUNT(*) FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'db' AND TABLE_NAME = 't'; - 查是否逼近上限：
SHOW CREATE TABLE t\G看字段列表长度 - 不要试图用
SELECT *嵌套去“测试字段数”——它不会提前报错，而是在打开表时才崩
嵌套中字段爆炸的真实来源：JOIN + SELECT * + 多层派生表
真正让字段数量失控的，往往不是嵌套本身，而是嵌套里混用了SELECT *和多表JOIN。例如三层嵌套中，最内层SELECT * FROM a JOIN b ON a.id = b.a_id，若a有500列、b有600列，仅这一层就生成1100列的中间结果——哪怕外层只取其中3个字段，InnoDB在构建read_set位图和mysql_row_templ_t模板时，仍需为全部1100列分配内存和索引位。这不仅触碰1017上限，还会显著拖慢字段转换过程（纯内存拷贝，非指针引用）。
- 永远用显式字段列表替代
SELECT *，尤其在子查询中 - 避免在嵌套里JOIN宽表；如必须，先用CTE或临时表预聚合、裁剪列
- MySQL 8.0+ 的
derived_merge=on优化可能加剧问题——它把派生表合并进外层，导致字段数叠加更隐蔽
为什么改用JOIN通常比嵌套查询更能规避字段限制
JOIN本身不限制字段数，但它让字段膨胀变得可预测和可控。一个LEFT JOIN的结果集字段数 = 左表字段数 + 右表字段数（无重名时），而嵌套查询中每个子查询都可能独立触发一次1017列校验。更重要的是，优化器对JOIN的列裁剪更积极：当你写SELECT u.name, o.total FROM users u JOIN orders o ON u.id = o.user_id，MySQL会在物化中间结果前就丢弃orders表中未被引用的99个字段；但嵌套里(SELECT * FROM orders WHERE user_id = u.id)会坚持加载全部字段，哪怕外层只用total。
- 能用JOIN表达的逻辑，优先不用相关子查询
- EXISTS/IN子查询比SELECT子查询更安全——它们不生成字段，只返回布尔或单值
- 如果业务强依赖嵌套且字段多，考虑升级到支持列存储的引擎（如ClickHouse），但这就不再是MySQL范畴了
字段数量限制藏在存储层，不是语法糖能绕开的。看到Too many columns，别翻SQL手册，直接去information_schema.COLUMNS查表结构。
