分析查询性能差的核心原因是其需全量扫描、索引失效、宽表多维分析、大结果集、复杂算子、统计信息不准、数据倾斜等多重因素叠加，远超业务查询的简单点查场景。
分析查询要扫全表，业务查询靠索引快速定位
业务查询通常带明确过滤条件（比如 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，且盐值选择不当会引入额外去重逻辑，反而降低可读性和维护性
Spilled to disk: 2.4 GB 到底从哪来的。 
