Spark SQL 加 LIMIT 10 就只读十行吗？为什么查询还是很慢？
本文目录
面试怎么回答
我会先区分无排序取少量行、全局TopN和聚合后LIMIT。直接取行可能提前结束，但稀疏过滤、文件发现和数据源能力仍有成本；TopN通常需要检查候选数据，聚合也依赖输入。随后看Spark实际计划及扫描指标，确认是否发生下推和提前终止。需要降本时用合法的分区或范围过滤，不把LIMIT当成通用扫描限制。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
一条查询最后只返回十行，却扫了很久。用户问：“已经写 LIMIT 10 了，还能慢在哪？”如果这十行是全站成交额最高的十个商品，系统就得先知道谁比谁高。限制结果数量，并不等于限制求出结果所需的工作。
LIMIT约束最终输出，不承诺所有上游只处理同样行数；是否少读，要看排序、聚合、过滤和数据源下推。
三种查询，只是最后都写了 LIMIT
直接读取一张表并取十行，如果没有必须完成的上游操作，执行器可能只读取部分输入就满足需求。但结果没有明确排序时，也不能把它当作稳定的最新十条。
按金额倒序取前十名，需要在候选集合里判断谁进入前十。局部TopN可以减少后续传输和排序开销，却不意味着其余候选数据完全不必检查。
先按商品聚合成交额，再取前十，更要先形成正确的商品总额。除非计划有可证明等价的特殊优化，否则不能在原始订单层随便截断十行再聚合。
LIMIT放在里面，可能已经改了问题
下面两种需求必须区分：“全量订单里成交最高的十个商品”，与“先取十条订单，再找其中成交最高的商品”。
第二种可能很快，但它不是第一种的优化版本，而是另一个问题。为了提速把LIMIT搬进子查询，尤其容易产生这种语义变化。
同样，先取十行再过滤与先过滤再取十行也不同。前者可能最终一行都没有，后者需要找到十条满足条件的记录，扫描范围可能大得多。
少量结果，也可能有大量准备工作
读取文件表时，文件发现、元数据读取和任务启动本身就有成本。即使真正读取的数据不多，也不等于整个查询只花十行的处理时间。
如果过滤条件很稀疏，可能需要检查大量数据才能找到十个匹配项；如果根本没有匹配项，无法指望很早就满足LIMIT。
外部数据源还要看是否支持以及是否实际完成LIMIT下推。Spark 4.0.1的JDBC V2文档说明了相关配置和条件，多分区读取时仍可能需要Spark端再施加限制，不能从配置名推导只发生一次十行读取。
一个典型场景：榜单只有十行，却扫描整月
比如某商品榜单按月汇总成交额，末尾写ORDER BY总额降序LIMIT 10。开发认为查询只返回十行，应该足够轻量，于是没有限制业务月份。
上线后实际扫描了更长历史。最初怀疑排序参数不够，检查计划才发现上游聚合输入范围远超需求。
旧测试只检查返回行数不超过十，没有检查扫描分区与总字节。修复应补上业务合法的日期范围，必要时复用已治理的同口径汇总表，再评估TopN执行成本。
不能为了减少扫描直接在订单明细上先取十条。那样即使榜单立刻返回，也不再是用户要的全月商品排名。
用哪些证据判断优化是否成立？
查看物理计划中的扫描、过滤、聚合、排序和限制位置，同时核对运行时读取的文件、字节、任务数量和结果行数。
有无下推要依据数据源实际能力与计划显示，而不是仅凭SQL长相。不同版本、连接器和查询形态，可能采用不同策略。
对照测试时固定数据范围，分别测试直接LIMIT、排序LIMIT和聚合后LIMIT，再记录端到端耗时。这样才能看出成本来自启动、扫描还是计算。
如果只是临时检查样例，可以选择有代表性的日期分区并明确说明只是样本；如果是完整指标计算，则必须守住输入完整性。
这道题的核心不在于“LIMIT有没有用”，而在于它限制了哪一层。最终只有十行，也完全可能是一条需要处理大量数据的正确查询。
资料与适用边界
机制以所链接版本为准；业务示例用于说明判断方法，不代表作者真实项目或已验证的生产性能。