您好，当我们从2008 R2切换到2016年时，对数据库的性能有重要影响。该数据库用作其他服务器的发布，并且在创建该发布时，如果执行以下操作会延迟2秒“将脚本表创建为...”。这个问题与该操作并没有真正的关系，只是一个症状（因为在我们发布之前非常快）。主要问题是在执行快照时会进行相同类型的查询，它通过查询非常慢的sysobjects和sys.all_columns列来检查表结构。
这是STATISTICS IO的结果：
(13 row(s) affected)
Table 'syssingleobjrefs'. Scan count 53, logical reads 117, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'sysclsobjs'. Scan count 0, logical reads 26, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'sysnsobjs'. Scan count 1, logical reads 27, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'sysschobjs'. Scan count 2, logical reads 62, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'sysscalartypes'. Scan count 1, logical reads 53, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'syscolpars'. Scan count 1, logical reads 15646, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'sysobjvalues'. Scan count 15, logical reads 45, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'sysidxstats'. Scan count 13, logical reads 26, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'syscolpars'. Scan count 1, logical reads 4, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Workfile'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'syspalvalues'. Scan count 1, logical reads 2, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
(1 row(s) affected)
SQL Server执行时间： CPU时间= 1343毫秒，经过的时间= 1871毫秒。
SQL Server执行时间： CPU时间= 1937毫秒，经过时间= 2469毫秒。 SQL Server解析和编译时间： CPU时间= 0毫秒，经过的时间= 0毫秒。
SQL Server执行时间： CPU时间= 0毫秒，经过的时间= 0毫秒。
我们可以在这里清楚地看到它的大量阅读内容：
表'syscolpars'。扫描计数1，逻辑读取15646
此表也可以视为执行计划中的主要性能指标：
您可以使用syscolpars（系统表）的聚集索引来查看其索引，并且我注意到该索引在2008 R2和2016之间发生了变化。
在2008 R2中，聚集的列为：
在2016年，它发生了变化：
因此，由于其不再按名称聚类，因此它执行了聚集索引扫描操作，而在2008 R2中，它进行了聚簇索引查找操作。
因此，快照需要4个小时，而2008 R2则需要10分钟。
sys.syscolpars indexes between 2008 R2 and 2016
任何人都知道为什么要将ID设置为该syscolpars系统表上的聚集索引的第一列吗？还有如何更改（您不能编辑系统索引）。
感谢您帮助我了解此问题！
