Spark SQL中LIMIT必须写在查询末尾且仅支持常量整数，动态行数应使用DataFrame的limit()方法；CTAS中LIMIT可能被优化器忽略，需用子查询或分步执行；ORDER BY+LIMIT需加二级排序保证结果稳定。
Spark SQL里用LIMIT控制返回行数最直接
Spark SQL支持标准SQL的LIMIT子句，这是限制结果行数最常用、也最可靠的方式。它在物理执行计划中会尽早截断数据流，避免不必要的Shuffle和计算开销。
注意：LIMIT必须写在查询末尾（ORDER BY之后），不能放在WHERE或JOIN子句里；且不支持变量或表达式（比如LIMIT @n或LIMIT 10 + 5），只能是常量整数。
- 正确写法：
SELECT * FROM logs LIMIT 100 - 带排序时顺序不能错：
SELECT user_id FROM events ORDER BY ts DESC LIMIT 10（ORDER BY必须在LIMIT前） - 错误写法：
SELECT * FROM logs LIMIT ?（JDBC参数绑定不生效）、LIMIT 10 OFFSET 20（Spark 3.0+才支持OFFSET，旧版会报ParseException）
想动态控制行数？得绕过LIMIT用DataFrame API
如果行数需要运行时决定（比如从配置读取、用户输入），纯SQL的LIMIT不够用。这时应该用DataFrame的limit()方法，在SQL执行后链式调用。
它和SQL LIMIT语义一致，但更灵活：参数可以是变量，还能和其他操作组合（比如先filter()再limit()）。底层都转为相同的物理算子，性能无差异。
- PySpark示例：
df = spark.sql("SELECT * FROM sales")<br>df.limit(int(max_rows)).show() - Scala示例：
val df = spark.sql("SELECT name FROM users")<br>df.limit(config.getInt("max_result_size")).show() - 别用
take(n)代替——它会把数据拉到Driver端，超大表容易OOM；limit(n)只在Executor端截断，安全得多
LIMIT在分区表或CTAS里可能被优化掉
当LIMIT出现在CREATE TABLE AS SELECT（CTAS）语句中，某些Spark版本（尤其是3.2之前）可能因优化器误判而忽略它，导致建出全量表。这不是bug，而是CBO认为“建表不需要限制中间结果”。
解决办法很实在：显式拆成两步，先查再存。
- ❌ 危险写法：
CREATE TABLE top_users AS SELECT * FROM users ORDER BY score DESC LIMIT 100（可能建出全表） - ✅ 安全写法：
spark.sql("CREATE TABLE top_users AS SELECT * FROM (SELECT * FROM users ORDER BY score DESC LIMIT 100) t")（加一层子查询强制固化逻辑） - 或者更稳妥：
spark.sql("SELECT * FROM users ORDER BY score DESC LIMIT 100").write.saveAsTable("top_users")
ORDER BY + LIMIT组合要小心数据一致性
ORDER BY触发全局排序，代价高；而LIMIT本身不保证稳定性——如果排序字段有重复值（比如多个用户score都是95），不同执行可能返回不同行，尤其在分布式环境下。
这不是Spark特有，但容易被忽略。真要可重现结果，必须加足够区分度的二级排序。
- 不推荐：
SELECT id FROM products ORDER BY price LIMIT 5（price相同的产品，每次结果可能不同） - 推荐：
SELECT id FROM products ORDER BY price, id LIMIT 5（id确保唯一性） - 如果没天然唯一字段，可加
rand()但慎用：ORDER BY price, rand()会让结果不可复现，仅适合探索场景
实际用LIMIT时，最容易栽在CTAS语义陷阱和ORDER BY稳定性上——前者导致资源浪费，后者导致结果漂移。这两处不看执行计划很难发现。
