C# 重建索引是否等同于删除和重新创建索引？

昨天和今天，我花了几个小时试图解决为什么在我在本地实例上还原的数据库上执行特定数据库查询需要很长时间（3分钟以上），而在生产服务器上只需要几秒钟。（这不仅仅是生产服务器的规格更高的问题，因为同一个查询以前在我的本地实例上执行得很好）

我会尽我所能解释这个问题，这意味着这篇文章可能有点长。这个问题非常直截了当：

SELECT [t0].[BillId], [t0].[CustomerId], [t0].[BillDate], [t0].[DueDate], 
[t0].[Period], [t0].[Total], [t0].[Balance], [t0].[DateCreated], [t0].[DateModified] --, other fields
FROM [dbo].[Bills] AS [t0]
WHERE ([t0].[Period] = 201307) AND (([t0].[DateModified] >= '2013-07-04 17:00:00.000') 
OR (([t0].[DateModified] < '2013-07-04 17:00:00.000') AND (EXISTS(
SELECT NULL AS [EMPTY]
FROM [dbo].[BillDetails] AS [t1]
WHERE [t1].[BillID] = [t0].[BillID] AND [t1].[DateModified] >= '2013-07-04 17:00:00.000'
))))

根据我在试图解决这个问题时的经验，我有几个问题困扰着我

Q：重建索引做什么？它是否等同于手动删除和重新创建索引

Q：将索引结果放入与被删除索引相关联的统计数据中。重建索引是否“刷新”或“重置”相关统计信息

Q：考虑到查询优化器在选择执行计划时对统计数据的依赖性，统计数据是否会对查询执行的感知阻塞负责

Q：根据MSDN，不能使用

DROP statistics

删除索引统计信息。这是否意味着必须删除并重新创建索引才能重置统计信息

---

注意：LINQ和C#被标记，因为上面查询的来源是在数据层中使用LINQtoSQL的C#应用程序。

我发现这句话：

但是，索引重新组织根本不会更新统计数据 因为整个表不是一次分析的（仅页面 与碎片一起重新组织）

在本文中：

可能您用于重建/重组索引的脚本只是重组了该索引，但没有重建它（由于碎片较少），因此该索引的统计信息变得“旧”

文章中有一个很好的建议：

因此，如果您发现索引维护脚本定期更新 重新组织索引，然后您需要确保您还添加了 在统计维护中

---

我发现这句话：

但是，索引重新组织根本不会更新统计数据 因为整个表不是一次分析的（仅页面 与碎片一起重新组织）

在本文中：

可能您用于重建/重组索引的脚本只是重组了该索引，但没有重建它（由于碎片较少），因此该索引的统计信息变得“旧”

文章中有一个很好的建议：

因此，如果您发现索引维护脚本定期更新 重新组织索引，然后您需要确保您还添加了 在统计维护中

NCI_IDX1 ([CustomerId] ASC)
NCI_IDX2 ([CustomerId] ASC, [Period] ASC, [BillId] ASC)
NCI_IDX3_Inc_Various ([Period] ASC, [DateModified] ASC, [BillId] ASC, [CustomerId] ASC) INCLUDE ([BillDate], [Total], [Balance] /* more fields */)