在主数据库下查询视图比直接在特定数据库下查询要慢得多答案

【问题标题】：Query against a view under master database is much slower than query directly under specific database在主数据库下查询视图比直接在特定数据库下查询要慢得多
【发布时间】：2017-01-09 17:12:41
【问题描述】：

在给出更多细节之前，我不确定是否存在一般性答案。

例如：我有一个名为vw_View的视图

我尝试了以下两个查询以获得结果：

master数据库下select * From [test].[dbo].[vw_View]
待测数据库 select * From [dbo].[vw_View]

谁能告诉我为什么从master数据库查询同一个查询比从其他数据库查询慢得多，我什至尝试了其他数据库：

Use [db]    --any other databases not master database
select * From [test].[dbo].[vw_View]

我检查了实际的执行计划，连接顺序不同但是为什么它会改变，因为我已经在master下指定了[test].[dbo].[vw_View]

只是出于好奇，在此先感谢。

【问题讨论】：

只是一个猜测，但也许该计划来自缓存，并且在缓存时有所不同。如果你使用with recompile，你还会得到不同的计划吗？
感谢您的评论，但问题仍然存在 :(

标签： sql sql-server database sql-server-2014

【解决方案1】：

注意这可能不是答案，但无论如何，评论的文字太多了......

我们经常听到的一件事是，当开发人员抱怨运行缓慢的程序时，该程序仅在从应用程序调用时运行缓慢，但在从 SSMS 执行时运行良好。

这通常是由于不同的执行设置取决于调用过程的位置。为了检查这些设置是否存在差异，我通常使用 SQL Profiler。

在您的情况下，您可以在 SSMS 中打开两个不同的窗口，一个在 Master 数据库的上下文中，另一个在 User Database 的上下文中，然后运行 SQL Profiler，第一个事件分析器将捕获，将是Event Class = Existing Connections 和 Text Data = -- network protocol: LPC.....。

此记录将显示您正在执行命令的每个会话的所有默认设置，这些设置看起来像......

-- network protocol: LPC
set quoted_identifier on
set arithabort off
set numeric_roundabort off
set ansi_warnings on
set ansi_padding on
set ansi_nulls on
set concat_null_yields_null on
set cursor_close_on_commit off
set implicit_transactions off
set language us_english
set dateformat mdy
set datefirst 7
set transaction isolation level read committed

现在比较两个会话的设置，看看有什么不同。

分析器还有一个列SIPD，它将帮助您识别哪个窗口是哪个窗口。我很确定答案就在某个地方。

【讨论】：

感谢您的回答，但我在同一范围内的同一会话中运行了这两个

【解决方案2】：

有同样的问题 - 从master 执行一个视图会无限长，但“在此服务器上的任何其他用户数据库下”执行相同的视图只需要 8 秒。我有一个环境，我们刚刚迁移到 SQL Server 2017 并且“所有其他数据库”的兼容性级别 = 2008（或 2012）

所以我做了一些测试：

如果我创建一个默认兼容级别 = 2017 的新数据库并运行查询，它将无限长地执行
如果我将兼容级别更改为 2008 并重新连接 - 8 秒
如果我将兼容性级别改回 2017 年 - 再次长期运行

关于查询本身，我们注意到的最后一件事 - 查询正在使用 CHARINDEX 函数，如果我将其注释掉，则查询在两个兼容性级别上的执行时间相同为 8 秒。

所以...看起来我们在兼容级别 = 2017 上下文下在旧数据库上执行 CHARINDEX 函数存在混合问题。

解决方案是（如果你可以这样称呼它......） - 在（相同的）遗留执行上下文下执行遗留查询。

【讨论】：