背景：
我有许多带有大量 VIEW 和大量 SYNONYM 的数据库。例如，一个数据库有超过 10k 的 VIEW's 和 2+ 百万的 SYNONYM's。
一般问题：
涉及sys.objects（和一般系统表）的查询往往很慢。涉及sys.synonyms的查询是冰川。我想知道我可以做些什么来提高性能。
具体示例
此命令由第三方工具运行。它在应用程序和 SSMS 中都很慢：
exec sp_tables_rowset;2 NULL,NULL
我的问题：
我怎样才能让它运行得更快？
我试过的：
如果SET STATISTICS IO ON我得到这个输出：
（2201538 行受影响）
表“sysobjrdb”。扫描计数 1，逻辑读取 28，物理读取 0，预读读取 0，lob 逻辑读取 0，lob 物理读取 0，lob
预读读取 0。表 'sysschobjs'。扫描计数1，逻辑读53926，物理读0，预读0，lob逻辑读0，lob物理读0，lob预读0。
我已经能够更新底层系统表的统计信息。这在我的 SQL 2008 R2 或更新的环境中有效：
UPDATE STATISTICS sys.sysobjrdb WITH FULLSCAN
UPDATE STATISTICS sys.sysschobjs WITH FULLSCAN
我还能够执行索引维护。这适用于我的 SQL 2012 或更新的环境。例如运行sp_help 'sys.sysschobjs'标识表上的索引，然后我从那里创建并运行这些命令：
ALTER INDEX clst ON sys.sysschobjs REORGANIZE
ALTER …微软关于Trace Flag 4199的知识库文章有点混乱：
...任何可能影响查询执行计划的修补程序都必须由跟踪标志控制。除了对可能导致错误结果或损坏的错误的修复外，这些修补程序默认情况下处于关闭状态，并且需要跟踪标志才能启用修复。
注意：我假设“修补程序”是累积更新（又名“CU”）。如果我错了，请发表评论。
所以...让我们假设我正在运行最新的 Service Pack。SP 包括以前 CU 中的所有修复。是否为 SP（甚至RTM）打开了修补程序？还是仍需要跟踪标志 4199？