SQL Server带row_number分区的视图在PowerBI导入模式超时问题

首先明确：ROW_NUMBER() OVER(PARTITION BY ...)窗口函数本身不存在和PowerBI导入模式不兼容的问题，你同事的判断不成立。视图逻辑确实是在SQL Server端执行，但PowerBI发起的查询和你在SSMS中手动执行的查询存在本质差异，会直接触发SQL Server执行计划异常，这才是超时的根本原因。

• 你在SSMS中直接查询视图时，使用的是默认会话参数配置，SQL Server生成的执行计划适配当前查询场景，所以9秒就能正常返回结果。
• PowerBI导入模式加载数据时，不会简单发送SELECT * FROM 你的视图这类基础查询：它会自动修改会话级参数配置（比如ARITHABORT、ANSI_NULLS等参数的默认值和SSMS不一致），部分版本还会在视图外层包装多层子查询、先发起元数据探测语句，这些差异会直接触发SQL Server的参数嗅探问题，生成完全不同的低效执行计划——最常见的情况是优化器错误选择嵌套循环连接、跳过分区字段索引，导致窗口函数计算阶段需要反复全表扫描，执行耗时翻几十倍，直接触发超时。
• PowerBI导入数据默认会开多线程并行拉取，如果视图没有稳定的执行计划缓存，并行请求同时触发编译，会进一步拉高执行计划跑偏的概率，性能波动会比单线程在SSMS执行大很多。

• 实体表存储了持久化的统计信息，无论会话参数怎么变，SQL Server优化器都能拿到准确的行数、数据分布估算值，不会为窗口函数关联逻辑选择偏差极大的执行计划，哪怕外层有查询包装，执行成本也不会出现量级飙升。
• 视图本身只是存储的逻辑定义，不缓存任何数据和统计信息，每次执行都要实时展开逻辑定义生成执行计划，只要上层查询写法、会话参数有微小变化，带窗口函数、多表关联的复杂视图的执行计划就会出现大幅波动。

• 先抓真实查询定位问题：开启SQL Server扩展事件或Profiler，捕获PowerBI加载时实际发送到数据库的T-SQL语句，将语句复制到SSMS中执行，你会发现该语句的执行耗时和PowerBI侧一致，远高于9秒，这一步可以直接排除PowerBI端的兼容性问题。
• 优化窗口函数计算性能：给PARTITION BY分区字段、ORDER BY排序字段创建覆盖索引，避免计算行号时做全表排序，从根源降低查询成本。
• 固定执行计划：如果确认是参数嗅探导致的计划跑偏，可以在视图定义中添加OPTION (RECOMPILE)提示，或者通过计划指南固定你在SSMS中跑出的9秒完成的高效执行计划，保证无论上层传入什么会话参数，都走稳定的执行路径。
• 重查询做预计算：如果视图逻辑本身计算量较大，不要让PowerBI直接查询裸视图，可以通过SQL Server代理定时任务将视图计算结果同步到专用的实体中间表，PowerBI直接读取预计算好的实体表，既可以避免执行计划波动，加载速度也会明显提升。

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