出于测试目的，我部署了：
该测试旨在将查询与Azure SQL DB的速度与针对表格模型的查询速度进行比较。
测试中的表格模型由4个维度组成，但在查询中只使用了其中2个维度。我认为针对表格模型的查询不能处理超过2个维度？
查询从本地计算机上运行的.NET控制台应用程序运行。针对表格模型的查询使用ADOMD.NET客户端库，并使用DAX（我没有经验的语言）编写，并且来自SSMS中的设计工具。针对SQL DB的查询使用ADO.NET客户端库（包含聚合函数，7个内部联接和一些＆＃34; where子句＆＃34;参数）。
测试包括每个系统的10个查询，每个查询之间的等待时间为500毫秒。使用System.Diagnostics.Stopwatch测量每个查询的时间加上执行客户端库的控制台应用程序的开销。与SQL SB查询（529,1ms）相比，表格模型的查询的平均持续时间是两倍（957,6ms）。
由于Analysis Services针对包含聚合和连接的分析查询进行了优化，因此我希望对表格模型的查询更快。
任何人都可以解释为什么它的表现不会更好吗？或者为什么会使用Tabular模型而不是直接在关系数据库上运行SQL查询？
答案 0 :(得分：1)
除非您的手工制作的SQL表现特别差，否则查询在SQL DB上执行的时间应该大致相同。 Analysis Services将从SQL DB返回的数据与您的语义模型相匹配所花费的时间是额外延迟的来源。
这里使用Direct Query的价值在于，您可以为用户提供更直观的语义模型，因为预计用户不会是DBA。除此之外，语义模型很可能包括计算，度量，KPI等。
如果您不需要提供以业务为中心的语义模型，并且您很乐意在SQL查询中进行所有计算和聚合，那么您可能不需要Analysis Services。
当然，关闭直接查询模式使用Analysis Service的另一个好处是，您可以将数据存储在内存中而不是存储在磁盘上，以提高查询性能。另一个主要好处是您可以将语义模型指向多个数据源，这样您的模型就可以成为业务用户的集中数据源。
最后，表格模型可以使用的维度数量没有限制......
测试中的表格模型由4个维度组成，但只有2个 这些维度在查询中使用。我想对一个查询 表格模型不能处理超过2个维度？