SSAS Tabular小分区处理异常耗时求助：160K行分区需近1小时

针对Table A的160K行分区处理耗时接近全表的问题，核心排查点如下：

• 分区筛选逻辑失效
  检查分区的日期筛选表达式是否正确。如果筛选条件存在语法错误，或日期范围意外覆盖了全表数据，SSAS实际会扫描整张1.58亿行的表，导致分区处理耗时和全表一致。可以在SSMS中查看分区的SourceQuery，验证生成的SQL是否仅返回目标月份的160K行数据。

• 复杂计算依赖的额外开销
  Table A上的大量度量值或计算列如果依赖全表上下文（比如使用ALL()、ALLSELECTED()函数，或跨多表的关联计算），即使只处理单个分区，SSAS也需要验证或计算这些依赖项，产生远超数据量本身的开销。而Table B可能没有这类复杂计算，因此处理更快。可以临时移除Table A的复杂度量值/计算列，重新测试分区处理耗时，验证是否为此原因。

• 数据源查询效率低下
  分区对应的数据源查询可能未利用日期列的索引，导致全表扫描。检查数据源（如SQL Server）中Table A的日期列是否创建了索引，执行分区的源SQL查询，查看其执行计划是否命中索引，以及查询本身的耗时是否过长。

• 元数据与关系验证开销
  作为大事实表，Table A与多个维度表存在关联关系。处理单个分区时，SSAS可能需要重新验证所有关联的元数据和关系，这部分开销不随数据量线性变化。而Table B关联的维度少，这部分开销可以忽略。通过SSMS的处理报告或SQL Server Profiler查看处理日志，定位耗时最长的阶段（如关系验证、元数据同步）。

• 存储模式与压缩设置
  若Table A使用列存储索引，分区的压缩级别或存储模式设置不合理，可能导致小数据量下压缩的相对开销过高。对比Table B的存储设置，检查是否存在差异（如Table A启用了最高级别的列存储压缩，而Table B使用默认设置）。

快速验证步骤 #

1. 提取分区的SourceQuery，在数据源执行，确认返回行数和查询耗时。
2. 临时禁用Table A的所有度量值和计算列，重新处理分区，观察耗时变化。
3. 查看SSAS处理日志，定位耗时占比最高的处理环节。
4. 检查数据源中日期列的索引状态，确保分区查询能高效获取数据。

内容的提问来源于stack exchange，提问作者D. Henry