关于SSAS Tabular 2016/2017对比2014的Excel浏览性能问题咨询

这种相同硬件、相同Cube却出现跨版本性能大幅退化的问题确实让人头疼，结合你提到的环境差异（兼容级别、OS版本），我整理了几个关键的排查和优化方向，你可以按顺序尝试：

1. 排查兼容级别带来的引擎行为差异 #

• 1200/1400兼容级别启用了新一代VertiPaq引擎优化，但默认逻辑可能和1103（2014）的旧引擎不匹配你的Cube结构。可以先临时将2016/2017上的Cube兼容级别降级到1103（记得先备份），测试性能是否回到2014水平——这能快速定位是不是引擎版本导致的核心问题。
• 确认Cube的存储模式：1200+对DirectQuery混合模式的处理逻辑有调整，检查Cube属性里的Storage Mode是否和2014完全一致，避免因模式差异导致的查询路径变化。

2. 调整SSAS服务的资源配置（默认设置可能不匹配） #

虽然硬件参数相同，但2016/2017的默认资源分配逻辑有变化：

• 内存限制：SSAS Tabular默认按总内存百分比分配，在SQL Server配置管理器中找到SSAS服务属性，切换到Memory选项卡。建议手动设置最大内存为110GB左右（预留18GB给系统），避免内存不足引发分页。
• 线程池优化：2016+新增了精细化线程池控制，默认设置可能没充分利用16核CPU。在SSMS中右键SSAS实例→属性→General，将MaxThreads调整为64（核数的4倍是常见优化值），同时确保ThreadTimeout设置为合理值（比如300秒）。

3. 优化Excel与SSAS的交互模式 #

Excel对新版本SSAS的默认交互逻辑可能更复杂：

• 关闭*“Enable Fast Combine”*：打开Excel选项→数据→Queries & Connections，取消勾选“Enable fast combine for data refresh operations”——这个选项在复杂查询场景下会额外增加延迟。
• 检查连接属性：右键Excel数据连接→属性→Definition，确认Command type为Default，没有自动生成多余的MDX语句。必要时手动简化查询语句测试性能。

4. 确保Cube的统计信息与缓存状态一致 #

• 重新完整处理Cube：2016+的统计信息生成逻辑和2014不同，完整处理（而非增量处理）能更新列级统计，帮助引擎生成更优的执行计划。
• 冷启动测试：在SSMS中右键Cube→Clear Cache，清除旧缓存后再测试查询性能——2014和2016/2017的缓存机制有差异，冷启动状态的对比更准确。

5. 对比查询执行计划定位瓶颈 #

• 使用SSAS Profiler（或Extended Events）捕获两个版本的查询执行事件，重点关注Query Subcube、VertiPaq Scan等事件的耗时，对比扫描行数、内存占用、CPU时间，找到性能差异的核心点。
• 利用DMV分析：在2016/2017上执行SELECT * FROM $SYSTEM.DISCOVER_QUERY_STATISTICS，查看查询的详细执行指标，和2014的结果做对比，定位资源消耗异常的环节。

6. 检查OS层面的隐藏差异 #

• 电源计划：Windows Server 2016默认电源计划是“平衡”，切换到“高性能”模式，确保CPU能满负载运行——2012R2可能默认就是高性能，这点容易被忽略。
• 内存锁定权限：给SSAS服务账号添加Lock Pages in Memory权限（在本地安全策略中配置），避免系统回收SSAS占用的内存，重启服务后生效。

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