去年冬天，硅谷一家SaaS公司的数据团队收到一份$47,000的Snowflake账单。查询日志显示，罪魁祸首是一行被复用了17个月的WHERE子句——他们把字符串转换函数包在了条件外面，让引擎被迫扫描了全表800亿行数据。
这不是技术债，这是技术高利贷。当数据量突破PB级，SQL不再是"能跑就行"的脚本语言，而是直接挂钩 CFO 签字权的财务工具。
1. 把过滤条件"推"到最底层
分布式引擎最贵的操作不是计算，是搬运数据。
想象你在10层图书馆找一本红皮书。糟糕的查询对管理员说："把4楼所有书搬到前台，我再挑哪些是红的。"聪明的查询说："只把4楼红皮书拿来。"这就是谓词下推（Predicate Pushdown）——让存储层在数据出库前就完成过滤。
一个经典踩坑：WHERE UPPER(status) = 'ACTIVE'。引擎无法利用status列的索引或分区，因为它必须先读取每一行、转换成大写，再判断条件。改成WHERE status = 'active'，过滤直接发生在存储节点，网络传输量可能从TB级降到GB级。
更隐蔽的陷阱出现在日期处理。WHERE DATE(created_at) = '2024-01-01'会阻断分区裁剪，而WHERE created_at >= '2024-01-01' AND created_at < '2024-01-02'能让引擎只读取目标日期的文件。在Databricks的Delta Lake上，这个写法差异可能意味着扫描10个文件 vs 10万个文件。
字符串函数、数学运算、类型转换——任何对列的"加工"都会让优化器失明。保持过滤条件的"原生形态"，是分布式SQL的第一性原理。
2. 统计信息是优化器的眼睛
再聪明的引擎也不是算命先生，它需要数据分布的"视力表"。
分布式Join的核心决策：哪张表进内存（Build侧），哪张表被流式扫描（Probe侧）。选错了，就是内存溢出→磁盘溢出（Disk Spilling）的死亡螺旋。某次现场排查中，我看到引擎试图把50GB表塞进内存，同时"流式"处理一张10MB表——只因为统计信息是三个月前的。
现代Lakehouse的自动统计收集并非万能。高频更新的表、倾斜严重的列（比如90%记录都是"US"的country字段）、新加载的分区——这些场景需要显式的ANALYZE TABLE。在Snowflake，这是ALTER TABLE ... CLUSTER BY的配套动作；在Databricks，OPTIMIZE和ANALYZE要写进Delta Live Tables的管道定义。
一个实用检查：EXPLAIN PLAN的输出里找"Statistics"行。如果某张表的行数显示为"unknown"或明显离谱的估算，优化器就是在蒙眼开车。
统计信息的新鲜度直接决定执行计划的理性程度。把ANALYZE命令埋进数据管道的最后一步，成本远低于一次失控的Join。
3. 笛卡尔积：分布式系统的集群杀手
漏写一个Join条件，在单机MySQL上是慢查询，在Snowflake上是全员停工。
100行 × 100行 = 10,000行，这还能忍。但100万行 × 100万行 × 100万行？分布式引擎会尝试把中间结果广播到所有节点，网络瞬间饱和，查询进入"不可取消"状态。我见过一个被遗漏的ON条件让生产集群卡了4小时，最终靠强制终止实例解决。
防御性写法很简单：永远用显式Join语法（JOIN ... ON），拒绝FROM t1, t2, t3的隐式风格。前者让意图清晰，后者让错误隐形。代码审查时，任何没有ON子句的Join都应该亮红灯。
更进阶的防护：在开发环境设置查询结果行数上限。Databricks有spark.sql.autoBroadcastJoinThreshold可以调低，Snowflake的STATEMENT_TIMEOUT_IN_SECONDS能在失控前熔断。这些不是性能优化，是生存保险。
显式Join还有意外收益——优化器更容易识别并消除冗余的Join路径。在某些场景下，这能让计划生成时间从秒级降到毫秒级。
4. Group By与窗口函数：别用锤子拧螺丝
我见过太多人用窗口函数做聚合，或用Group By做行级计算——就像用微波炉烘干衣服，能跑，但费电。
Group By的语义是"压缩"：把多行变成一行，伴随聚合函数（SUM/COUNT/MAX）。窗口函数的语义是"扩展"：每行保留，但附加一个计算列（ROW_NUMBER/RANK/LAG）。混用两者的查询往往产生意外的数据膨胀或收缩。
典型反模式：用窗口函数ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY timestamp)去重，然后外面包一层WHERE rn = 1。这在逻辑上等价于QUALIFY ROW_NUMBER() ... = 1，但前者需要物化整个窗口结果，后者让引擎在排序过程中就过滤。在BigQuery上，这个改写曾让某查询从12分钟降到8秒。
另一个盲区：分布式引擎对窗口函数的并行化有限制。PARTITION BY的基数过高（比如每行一个独立分区），会强制单线程执行，彻底浪费集群资源。此时改用自Join或子查询，反而能利用并行度。
工具选择的底线：先问"我要行数变多还是变少"，再选武器。Group By是漏斗，窗口函数是放大镜——用反了，账单数字也会跟着放大。
回到开头那家SaaS公司。他们最终建立了"查询成本预算"机制：每个PR必须附带EXPLAIN PLAN的估算扫描量，超过1TB需要架构师签字。三个月后，平均账单降到$3,200。
但最让我印象深刻的不是这个数字，而是一位数据工程师的反馈——他在代码注释里写道："现在写SQL像在下棋，每一步都要想对手（优化器）会怎么回应。"
你的团队是怎么防止查询失控的？是依赖自动优化，还是有一套人工审查的"土办法"？
热门跟贴