当数据在分区中大幅度变化时,每个分区的统计信息可以防止参数嗅探问题吗



目前我们有一个数据仓库,它保存来自多个租户的数据。SQL server的版本为2019。所有租户数据库的相同架构以及来自所有租户的数据都整合在数据仓库中。数据在数据仓库中以租户为基础进行分区。由于租户之间的数据差异很大,因此新仪表板存在参数嗅探问题。一些租户的数据少于10000行,而一些租户则有高达500万行的数据。因此,如果执行计划是基于较小租户构建的,那么仪表板性能对较大租户不利。

互联网上有建议,要求使用重新编译提示或优化提示等。但我对这个参数嗅探的基本原理有疑问。由于统计信息是由SQL server在分区级别维护的,所以这些统计信息是否不用于查看生成的计划是否适合新的运行时值?在执行之前,是否对基于编译时和运行时构建的计划的统计数据进行过比较,以查看它们是否有效以及相关的计划是否有效?

请告知。

  1. 在查询文本中嵌入分区号或TenantID键

参数适用于何时需要共享、重用的查询计划。对导致查询计划变化的条件进行硬编码是这里的基本正确答案。

即使";我们尽可能避免在代码";,你应该在这里破例。

  1. 使用OPTION RECOMPILE

如果您最终没有在查询优化上花费太多时间,这几乎同样好。或

  1. 在查询中添加一个因租户或租户大小而异的注释,以获得分区计划缓存。这对于将查询关联到生成查询的代码路径也很有用。例如
/* Dashboard: Sales Overview
Visual: Total Sales
TenantID: 12345    */   
select sum(Sales) TotalSales
from T
where TenantId = @tenantId

最新更新