不同的方式来定义使用哪个数据库？

Question

我想找出你可以定义在SSMS中使用哪个数据库的方式的差异。

是否有使用“可用数据库”下拉列表

Adventure works Available Databases dropdown之间的功能差异，

数据库在查询中被定义

SELECT * FROM AdventureWorks2008.dbo.Customers 

和 说明在数据库开始？

USE AdventureWorks2008 
GO 
SELECT * FROM dbo.Customers 

我很想知道是否在性能方面有差异或者发生在每种情况下的幕后。

谢谢你的帮助

Answer 1

是的，有。当您使用“USE AdventureWorks2008”时会添加非常小的开销，因为它会在您每次执行查询时针对数据库执行它。它还将打印“命令已成功完成”。然而，它是如此之小的开销，如果你对这个消息没问题，那么就不要在意这一点。

Answer 2

是的，可以有区别。

当您执行如下语句时：SELECT * FROM AdventureWorks2008.dbo.Customers在的上下文中另一个数据库（不是AdventureWorks2008）应用了另一个数据库的设置。

首先，任何数据库都有其Compatibility Level，可以是不同的，所以它可以限制某些代码的使用，例如，你不能使用APPLY运营商的数据库与CL上下文设置为80，但你可以在做数据库CL> = 90

其次，每个数据库都有自己的一组选项，如AUTO_UPDATE_STATISTICS_ASYNC和Forced Parameterization，这些选项可能会影响您的查询计划。 我也遇到一些情况下，当数据库的情况下影响了计划：

一种情况是，当我创建过滤索引一个表，它是在计划中使用的，直到我在数据库中有简单参数的上下文中执行我的查询，并且在带有强制参数化的数据库环境中执行时，它不会用于相同的查询。当我使用提示强制该索引时，我得到了由于查询提示而无法生成查询计划的错误，所以我需要调查并发现我的查询已被参数化，而不是我的条件fld = 0有fld = @p它不能使用我的筛选索引与fld = 0条件。

第二种情况是reguarding表基数估计：我们用临时表来加载在我们的ETL过程的数据，然后再切换到实际表是这样的：

insert into stg with(tablock); 
... 
truncate table actual; 
alter table stg swith to actual; 

所有临时表是空的时过程编译，但在过程中他们充满了数据，所以当我们在他们之间加入时，他们不再是emty了。从0行传递到非0行会触发语句重新编译，应该考虑到实际行数，但它不会在生产服务器上发生，因此所有估计都是完全错误的（每个表格有1行），我需要调查。生产数据库中的原因是AUTO_UPDATE_STATISTICS_ASYNC设置为ON。 现在想象你有2 db：db1和db2这个选项分别设置为ON和OFF，在db1中，这个代码将有错误的估计，而如果你使用db1.dbo.stg在db2中执行它，它将有正确的估计。这两个数据库的执行时间会有很大差异。