SQL 分析查询为何比业务查询更复杂？

分析查询性能差的核心原因是其需全量扫描、索引失效、宽表多维分析、大结果集、复杂算子、统计信息不准、数据倾斜等多重因素叠加，远超业务查询的简单点查场景。

分析查询要扫全表，业务查询靠索引快速定位

业务查询通常带明确过滤条件（比如 WHERE user_id = 123），数据库能直接走 user_id 的 B+ 树索引跳到单行或小范围数据；而分析查询常需聚合全量或大比例数据（如“近30天各省销售额TOP10”），GROUP BY 和 SUM() 必须读取大量原始行，索引失效或仅用于加速部分过滤，主体仍依赖顺序扫描。

• 即使加了时间范围，若字段未建索引或选择率太高（如 WHERE dt >= '2024-01-01' 覆盖80%数据），优化器大概率放弃索引，改用全表扫描
• 分析场景常用宽表（几十甚至上百列），但索引一般只覆盖少数列，无法支撑多维组合分析（如 GROUP BY region, product_type, channel）
• 业务查询结果集通常很小（1~100行），分析查询动辄数万行中间结果，内存/磁盘交换开销显著上升

分析查询涉及多层嵌套与复杂算子，执行计划更难预测

一个典型分析 sql 可能包含子查询、窗口函数、CTE、多表 JOIN（含事实表与多个维度表）、去重聚合等，每个环节都可能触发不同执行策略。比如 ROW_NUMBER() OVER (PARTITION BY category ORDER BY sales DESC) 要求先分组排序再编号，而 JOIN 顺序稍变（事实表放左还是右）就可能导致哈希表膨胀或临时磁盘 spill。

• ORDER BY + LIMIT 在分析中常出现在末尾，但若没走索引，数据库必须先排完整个结果集再截断，代价远高于业务查询的“查到即返回”
• 使用 union ALL 合并多周期数据时，各分支执行计划独立生成，优化器无法跨分支做全局优化
• 某些数据库（如 hive/spark SQL）对 LATERAL VIEW 或复杂 UDTF 支持有限，容易退化成多次 shuffle

统计信息不准或缺失，让优化器频繁选错执行路径

业务表数据变更频次低、分布稳定，统计信息（如直方图、NDV 值）更新及时，优化器能较准估算 WHERE 条件的选择率；而分析常跑在数仓分区内，新分区刚加载完，ANALYZE table 没来得及执行，优化器以为某列只有10个唯一值，实际有10万，导致本该用广播 JOIN 的却走了 Shuffle JOIN。

• 分区表若只对一级分区（如 dt）收集统计信息，忽略二级分区（如 region），多维下钻时基数估算严重失真
• 物化视图或汇总表未同步更新统计信息，查询改走视图后执行计划劣化，现象是“同样SQL昨天快、今天慢”
• 某些引擎（如 Presto）默认不自动收集统计信息，需显式调用 ANALYZE，且不支持列级采样，整表扫描成本高

数据倾斜在分析场景中更容易暴露且更难缓解

业务查询天然分散（用户ID哈希均匀），而分析常按热点维度聚合，比如“统计所有订单中的 seller_id = '平台自营' 占比”，这个值可能占总行数70%，导致 reducer 或 executor 处理负载不均，任务卡在最后1%。

• count(DISTINCT) 在大数据量下极易倾斜，尤其当去重键分布极不均匀（如90%用户来自3个省份）
• 用 JOIN 关联维度表时，若维度表存在空值或默认值（如 category = 'unknown'），该 key 对应的事实行可能暴增数倍
• 手动加盐（salting）需改写 SQL，且盐值选择不当会引入额外去重逻辑，反而降低可读性和维护性

分析查询的复杂性不在语法本身，而在它迫使数据库暴露底层数据分布、硬件资源边界和优化器能力短板——这些在点查场景里被完美掩盖了。真正棘手的不是写不出SQL，而是看懂执行计划里那一行 Spilled to disk: 2.4 GB 到底从哪来的。