我们需要每晚在我们的 SQL Server 2008 R2 上做一些报告。计算报告需要几个小时。为了缩短时间，我们预先计算了一个表格。该表是基于 JOINining 12 个相当大（数千万行）的表创建的。
直到几天前，这个聚合表的计算才用了大约 4 个小时。我们的 DBA 将这个大连接拆分为 3 个较小的连接（每个连接 4 个表）。临时结果每次都保存到一个临时表中，供下次join使用。
DBA 增强的结果是，聚合表在 15 分钟内计算完成。我想知道这怎么可能。DBA 告诉我，这是因为服务器必须处理的数据数量较少。换句话说，在大的原始连接中，服务器必须处理比在总和较小的连接中更多的数据。但是，我认为优化器会使用原始大连接有效地执行此操作，自行拆分连接并仅发送下一个连接所需的列数。
他所做的另一件事是在其中一个临时表上创建了索引。但是，我再次认为优化器会在需要时创建适当的哈希表，并更好地优化计算。
我和我们的 DBA 讨论过这个问题，但他自己不确定是什么导致了处理时间的改善。他刚刚提到，他不会责怪服务器，因为计算如此大的数据可能会让人不知所措，而且优化器可能很难预测最佳执行计划...... 我明白这一点，但我想对确切原因有更多明确的答案。
所以，问题是：
什么可能导致大的改善？
将大连接拆分为小连接是标准程序吗？
在多个较小连接的情况下，服务器必须处理的数据量真的更小吗？
这是原始查询：
Insert Into FinalResult_Base
SELECT
TC.TestCampaignContainerId,
TC.CategoryId As TestCampaignCategoryId,
TC.Grade,
TC.TestCampaignId,
T.TestSetId
,TL.TestId
,TSK.CategoryId
,TT.[TestletId]
,TL.SectionNo
,TL.Difficulty
,TestletName = Char(65+TL.SectionNo) + CONVERT(varchar(4),6 - TL.Difficulty)
,TQ.[QuestionId]
,TS.StudentId
,TS.ClassId
,RA.SubjectId
,TQ.[QuestionPoints]
,GoodAnswer = Case When TQ.[QuestionPoints] Is null Then 0
When TQ.[QuestionPoints] > 0 Then 1
Else 0 End
,WrongAnswer …有没有办法找出 SQL Server 2008 R2 中缓存的内容？我发现了以下不错的文章：http : //blog.sqlauthority.com/2010/06/17/sql-server-data-pages-in-buffer-pool-data-stored-in-memory-cache。但是，我想知道每个表和索引存储了多少数据（例如百分比和 KB）。有没有一些简单的方法来获取这些数据？
或者换句话说…… DBMS 是否以某种方式绕过操作系统缓存管理器并直接访问内存，或者它让操作系统完成其工作，作为正常进程运行并使用虚拟内存的概念？
我们有相当大的表（500 密耳行），我们期望频繁插入。桌子有大约。每个索引 2 个。问题是我们担心，当索引重新计算时，整个表被锁定，所有查询都会超时（在重新计算期间）。
有没有办法尽量减少重新计算索引的发生？例如，让节点在创建时变大，这样更多添加的指针将适合索引，而无需重新平衡索引？
我们有 SQL Server 2008 R2。