两段查询answer字段的SQL语句运行逻辑与差异解析

第一段嵌套查询SQL的执行机制 #

对应SQL语句：

SELECT answer AS answer
FROM
  (SELECT answer
   FROM "default"."enriched-responses-dev") AS virtual_table
LIMIT 1000;

按SQL语法的标准执行顺序，逻辑上的执行步骤为：

1. 先执行括号内的子查询：从default模式下的enriched-responses-dev表中，查询所有行的answer字段，生成一个仅包含answer字段的临时派生表，SQL语法要求这类FROM后的子查询必须设置别名，这里将该临时表命名为virtual_table。
2. 外层查询从virtual_table临时表中读取answer字段，将字段别名设置为answer（别名与原字段名完全一致，无实际重命名效果）。
3. 最终通过LIMIT 1000截断结果，最多返回1000条记录。

第二段直接查询SQL的执行机制 #

对应SQL语句：

SELECT answer AS answer
FROM "default"."enriched-responses-dev"
LIMIT 1000;

该语句逻辑非常直接：直接定位到default模式下的enriched-responses-dev原表，读取answer字段并设置同名字段别名，最后截断返回最多1000条记录。

两者的实际差异 #

• 优化器正常工作的常规场景下无任何实质差异：当前主流SQL引擎（包括Trino/Presto、Spark SQL、MySQL 8.0+、ClickHouse等）的查询优化器默认支持子查询展开、投影下推、LIMIT下推优化，会自动将第一段的无意义嵌套查询改写为和第二段完全一致的执行计划，不会真的先生成全量临时表再取1000条，两者的执行效率、返回结果完全相同。
• 语法冗余度不同：第一段SQL属于典型的冗余写法，内层子查询没有做任何过滤、聚合、计算、多表关联操作，仅做字段透传，外层也没有任何额外逻辑，完全可以简化为第二段的写法；另外两段语句中answer AS answer的写法也属于冗余，别名和原字段名一致，不会改变返回结果的字段名。
• 极端老旧引擎场景下存在性能差异：如果使用的是不支持子查询展开优化的老旧SQL引擎，第一段SQL会先扫描全表所有行的answer字段，全量加载生成临时表后再截取1000条，当原表数据量极大时会产生极高的性能开销；而第二段SQL会在表扫描阶段读取到1000条记录后就终止扫描，性能远高于嵌套写法。不过这类老旧引擎目前在生产环境已经极少使用。

日常编写SQL时不推荐使用第一段这类无意义嵌套写法，除了提升代码理解成本，在部分引擎适配场景下可能触发非预期的性能问题。

内容的提问来源于stack exchange，提问作者Arpit Shukla