SSAS Tabular模型用视图替代表引发Power BI性能及部署异常求助

我们数据集规模较大，因此在SQL Server中基于表创建视图以减少数据量，但随后Power BI的性能出现下降。发现SSAS Tabular模型似乎并未使用视图的结果集，而是直接执行视图的底层代码，以下结合具体示例分析这一现象：

示例1：主键重复错误问题 #

视图定义 #

CREATE VIEW [dim].[vw_PlaylistJaar] 
AS
    SELECT DISTINCT
        broad_date.Year AS jaar
    FROM
        Datamart.fact.Playlistline pls
    INNER JOIN
        datamart.dim.Playlist plt ON pls.Playlist_SID = plt.Playlist_SID 
    INNER JOIN
        datamart.dim.Date broad_date ON broad_date.Date_SID = pls.DateBroadcast_SID

该视图返回唯一年份列表（如2020、2021、2022），将其作为SSAS Tabular模型中PlaylistJaar表的数据源，该表仅含jaar列且是一对多关系的一端。部署时收到错误：

Column 'jaar' in Table 'PlaylistJaar' contains a duplicate value '2020' and this is not allowed for columns on the one side of a many-to-one relationship or for columns that are used as the primary key of a table

这说明SSAS并未使用视图生成的唯一年份结果集，而是直接执行底层代码。换成加载包含唯一年份的物理表后，部署无错误。

示例2：性能差异问题 #

通过视图过滤大量行作为SSAS数据源，在Power BI中可视化时，性能反而不如直接用底层物理表并在SSAS中过滤行的情况。

原因分析 #

1. 查询折叠机制的影响 #

SSAS Tabular模型默认会执行查询折叠：将模型内的数据转换逻辑（筛选、计算等）与视图的底层SQL合并为一条完整查询发送给SQL Server，而非先执行视图获取结果集再处理。这种机制会导致：

• 示例1中，SSAS验证主键唯一性时，折叠后的查询可能未保留视图的DISTINCT逻辑，或合并后的关联逻辑意外产生重复值，触发错误。
• 示例2中，视图的过滤逻辑与SSAS内的其他筛选条件组合后，生成的执行计划效率低于直接对物理表进行过滤的情况。

2. 视图的虚拟表特性 #

SQL视图本质是虚拟表，不存储实际数据，每次调用都会重新执行底层SQL。SSAS处理视图数据源时，不会预先计算并缓存视图结果，而是在需要数据时直接执行底层查询：

• 示例1中，SSAS验证模型时实际执行的是视图的关联查询，而非视图预计算的去重结果。
• 示例2中，视图的过滤逻辑与SSAS操作结合后，可能无法利用物理表的索引优化，导致执行效率下降。

3. 解决方案建议 #

• 改用物理表或索引视图：若视图结果集稳定，创建物理表存储视图结果，或创建索引视图（将结果持久化到磁盘），让SSAS直接读取预计算数据，避免查询折叠问题。
• 禁用查询折叠：在SSAS Tabular模型的数据源设置中，针对特定表禁用查询折叠，强制SSAS先执行视图获取结果集再处理，但需权衡数据加载时间的增加。
• 优化视图底层逻辑：为视图的底层SQL添加合适索引、简化关联逻辑，确保即使发生查询折叠，也能生成高效的执行计划。

内容的提问来源于stack exchange，提问作者Aniek