SQL Server 性能和完全限定的表名答案

【问题标题】：SQL Server performance and fully qualified table namesSQL Server 性能和完全限定的表名
【发布时间】：2017-09-19 06:31:08
【问题描述】：

在查询中包含架构所有者会提高数据库性能似乎已被广泛接受，例如：

SELECT x FROM [dbo].Foo 与 SELECT x FROM Foo.

这应该保存查找，因为 SQL Server 否则会在连接上下文中查找属于用户的 Foo 表。

今天有人告诉我，始终包含数据库名称以同样的方式提高性能，即使您正在查询您在连接字符串中选择的数据库：

SELECT x FROM MyDatabase.[dbo].Foo

这有什么道理吗？这作为编码标准有意义吗？这些（甚至是第一个例子）是否可以转化为可衡量的收益？

我们是在谈论数据库服务器上额外的字典查找与 Web 服务器（或其他客户端）上更臃肿的 SQL 和额外连接的几个周期吗？

【问题讨论】：

如果确实有所作为，则会增加维护问题，因为您的所有查询都包含数据库名称。使重命名数据库变得非常困难。
取决于你的维护。在我的特定过程中拥有完全限定的名称可以保证它以完全相同的方式运行，即使在我的测试环境中附加到不同的数据库时——在我的特定场景中，我想要测试环境。就存储过程而言，产生“生产”结果。我意识到，也许不是最佳实践，但是，我们广泛的数据存储环境在某些单独的 TEST 域中没有完全复制的、干净的、沙盒状态的对应部分——因此，我们的许多 TEST/DEV 环境充其量是虚假数据和生产数据的混合体。

【解决方案1】：

要记住的一点是，这是一个编译绑定，而不是执行绑定。因此，如果您执行相同的查询 100 万次，只有第一次执行会“命中”查找时间，其余的将重用相同的计划并且计划是预先绑定的（名称已经解析为对象 ID）。

【讨论】：

【解决方案2】：

在这种情况下，我个人更喜欢可读性，而不是这可能导致的微小性能提升（如果有的话）。

SELECT * FROM Foo

似乎比扫描容易得多：

SELECT * FROM MyDatabase.[dbo].Foo

【讨论】：

【解决方案3】：

试试看？只需循环一百万个查询，看看哪个先完成。

我猜这是一堆铺位。 MS SQL 的开发人员花费数百万小时研究搜索算法和存储方法的效率，结果却被未指定完全限定表名的用户所阻挠？好笑。

【讨论】：

【解决方案4】：

如果默认架构相同，SQL 服务器将不会进行额外查找。如果不是，并且它是一个经常使用的查询，则应该包含它。

数据库名称不会有利于查询性能。我认为这可以从 Management Studio 中的估计执行计划中看出。

【讨论】：

【解决方案5】：

正如 Spencer 所说 - 尝试一下，当然要确保每次都清除缓存，因为这会干扰您的结果。

如果它有任何明显的不同，我也会感到惊讶。

【讨论】：