我试图找出您在SSMS中定义使用哪个数据库的方式的差异。
使用'可用数据库&#39>之间是否存在任何功能差异?下拉列表
Adventure works Available Databases dropdown,
在查询中定义的数据库
SELECT * FROM AdventureWorks2008.dbo.Customers
和 在开始时说明数据库?
USE AdventureWorks2008
GO
SELECT * FROM dbo.Customers
我有兴趣知道每个案例的表现或幕后发生的事情是否存在差异。
感谢您的帮助
答案 0 :(得分:0)
是的,有。当您使用" USE AdventureWorks2008"时,会增加非常小的开销。因为每次执行查询时它都会对数据库执行它。它还将打印成功完成的"命令。"。然而,这是一个很小的开销,如果你对这个消息没问题,那就不用关心了。
答案 1 :(得分:0)
是的,可能存在差异。
当你在另一个数据库(而不是AdventureWorks2008)的上下文中执行这样的语句:SELECT * FROM AdventureWorks2008.dbo.Customers
时,应用了另一个数据库的设置。
首先,任何数据库的Compatibility Level都可以不同,因此它可以限制某些代码的使用,例如,在CL设置为的数据库环境中,您不能使用APPLY
运算符80但你可以在数据库中使用CL> = 90
其次,每个数据库都有自己的一组选项,例如AUTO_UPDATE_STATISTICS_ASYNC
和Forced Parameterization
,可能会影响您的查询计划。
当数据库的上下文影响了计划时,我确实遇到了一些情况:
有一种情况是我为一个表创建了过滤索引,并且在计划中使用它直到我在使用简单参数化的数据库上下文中执行我的查询,并且在上下文中执行时它不用于相同的查询具有强制参数化的数据库。当我使用提示强制该索引时,由于查询提示而导致无法生成查询计划的错误,所以我需要调查并发现我的查询已参数化而不是我的条件{{ 1}}有fld = 0
,它无法使用我的过滤索引fld = @p
条件。
第二种情况是调整表基数估计:我们使用登台表在我们的ETL程序中加载数据,然后切换到这样的实际表:
fld = 0
当程序编译时,所有的临时表都是空的,但在proc中它们充满了数据,所以当我们在它们之间进行连接时,它们就不再是emty了。从0行传递到非0行会触发语句重新编译,这应该考虑实际的行数,但它不会在生产服务器上发生,因此所有估计都是完全错误的(每个表都有1行)我需要调查。原因是生产数据库中insert into stg with(tablock);
...
truncate table actual;
alter table stg swith to actual;
设置为ON。
现在假设有2个db:db1和db2,此选项分别设置为ON和OFF,在db1中,此代码将具有错误的估计,而如果使用db1.dbo.stg在db2中执行它将具有正确的估计。这两个数据库的执行时间将大不相同。