6

我在 SQL Server 2012 中有一个多租户数据库，其中每个租户的行都由一tenant_id列标识（也称为共享数据库、共享架构方法）。一些租户，尤其是较新的租户，行数很少，而另一些则很多。

SQL Server 的查询优化器通常会根据第一次执行期间提供的参数构建查询计划，然后将这个计划重新用于所有未来的查询，即使提供了不同的参数。这称为参数嗅探。

我们的数据库存在的问题是 SQL Server 有时会根据指向较小租户的参数构建这些计划，这对于该租户来说效果很好，但是当它将缓存的计划重新应用到较大的租户时，它会灾难性地失败（通常是定时事实上）。通常，只有当我们的一个较大的租户与我们联系并告知我们遇到超时错误时，我们才会发现这种情况，然后我们必须进入系统并手动刷新所有查询计划以更正它。

您可以使用查询提示来防止 SQL Server 缓存查询计划 ( OPTIMIZE FOR UNKNOWN)，但这会导致一些额外的开销，因为每次调用查询时都会重新生成查询计划。另一个问题是我们使用的是实体框架，它无法指定OPTIMIZE FOR UNKNOWN查询的提示。

所以问题是——多租户数据库在参数嗅探方面的最佳实践是什么？有没有一种方法可以在数据库范围内禁用参数嗅探，而不必在每个查询中都指定它？如果是这样，这甚至是最好的方法吗？我应该以其他方式对数据进行分区吗？还有其他我没有想到的方法吗？

4

2 回答 2

3

我遇到过类似的问题，并通过像这样传递我的参数成功地解决了它：

CREATE PROCEDURE [dbo].[InsertAPCheck]
@APBatchID  int = Null,
@BankAccountID  int = Null
AS
  /* copy parameters to temporary variables */
  SELECT @xAPBatchId = APBatchId, @xBankAccountID = @BankAccountID
 .
 .
 /* now run the meat of your logic using the temp variables */
 SELECT * FROM myTable where Id=@xAPBatchId.....etc.

换句话说，在 1-1 的基础上为传入的每个参数创建一个局部变量，然后仅在 SP 的逻辑中引用这些新变量。我可能错过了 SQL Server 可以为我做的一些优化，但最重要的是我错过了当参数嗅探开始时我得到的真正可怕的性能。

在您的情况下，也许您可​​以尝试仅针对多租户 id 执行此操作（我假设它是所有 SP 的参数？），并让 SQL Server 优化其余参数（如果可以）。

于 2012-10-19T17:43:01.223 回答
1

对于动态 SQL，例如 Entity Framework 生成的 SQL，将注释注入到包含当前租户标识符的命令文本中。这实质上是按租户划分 SQL 的执行计划缓存，保持执行计划与租户隔离，但允许它们被同一租户重用。

要将注释注入命令文本，您可以子类化/实现DbConnection/IDbConnection并DbCommand/IDbCommand应用装饰器模式。调用DbCommand/IDbCommand.Execute*可以在调用内部方法之前附加注释的租户 ID，然后在返回后删除注释。使用装饰连接初始化实体框架或您使用的任何 ORM。

如果您有很多租户，则按租户大小类别对计划缓存进行分区可能是有意义的。否则，您将有效地执行相同的操作，OPTION (RECOMPILE)因为计划将在重用之前从缓存中过期。

于 2018-08-06T21:19:14.187 回答