这些sys.sp_ *存储过程在做什么？

Question

我在SQL服务器安装中追踪一个奇怪而巨大的性能问题。在我的系统上，一个特定的存储过程需要2分钟才能执行;在同事的系统上，它只需不到1秒。我们有类似的数据库/数据和配置，但显然有一些非常不同的东西。

我在两个系统上通过Profiler运行了有问题的SP，并发现了一些奇怪的事情。在我的系统上，我看到9个具有以下属性的条目：

• 相对于其他行，持续时间较高。我的值高达37,698且低至1734.在“快速”系统中，最大持续时间（对于整个SP呼叫）为259。
• 它们是针对与包含我运行的SP的数据库相关的两个数据库执行的。 （此SP通过链接服务器调用这两个数据库）。
• 它们是以下系统SP之一的执行：
  • sp_tables_info_90_rowset
  • sp_check_constbytable_rowset
  • sp_columns_90_rowset
  • sp_table_statistics2_rowset
  • sp_indexes_90_rowset

我找不到任何Googleable documentation这些是什么，为什么它们会如此慢，或者为什么它们会在一个系统上而不是另一个系统上运行。有谁知道他们的全部内容？

Answer 1

我不知道你问题的答案。但是为了尝试解决你遇到的问题（我认为，这是你真正感兴趣的问题），我要做的第一件事是对你要查询的表运行重新索引。当条件如您所述（相同的数据库结构，不同的数据/数据库，相同的查询）时，这通常会解决任何类型的缓慢。

Answer 2

尝试手动更新该表的统计信息。

UPDATE STATISTICS [TableName]

然后仔细检查AutoUpdateStatistics的数据库选项是否为TRUE。尽管如此，我已经看到过向表中添加大量数据并不总是导致统计数据及时更新的情况，并且查询可能会很慢。

Answer 3

这些是链接服务器调用时创建的表。这些称为在Tempdb中创建的工作表。它们由数据库引擎自动创建，用于临时操作，如Spooling等。

Answer 4

我不熟悉这些特定程序，但您可以尝试运行：

SELECT object_definition(object_id('Procedure Name'))

为了更好地了解幕后发生的事情。

Answer 5

上次索引重建？上次统计更新？

否则，这些存储的过程也被SQL Server客户端使用......不是吗？并且可能不会导致这些错误

Answer 6

这些sp意味着您的查询通过使用同义词来访问链接的服务器。应尽可能避免这种情况。