我有一个Azure SQL数据库，到目前为止已证明非常成功。它已经有20个月左右了，没有维护......但它已经处理了很多。有些表有数百万行，在查询已建立索引的列时，使用与之对话的Web应用程序时，查询响应时间是可以接受的。
但是，我读到了有关重建索引的相互矛盾的建议。
这家伙说这样做是没有意义的：http://beyondrelational.com/modules/2/blogs/76/posts/15290/index-fragmentation-in-sql-azure.aspx
我在一些存储几千行的小表上运行了一些重建索引语句。一些碎片会下降大约1/2 ...然后如果我第二次运行它，它可能会下降约
根据桌子的大小，这些重建在大约2-10秒内完成...
然后我在一个有大约200万行的表上运行了一个索引，该索引有以下碎片： PK__tmp_ms_x__CDEC17C03A4CDB46 55.2335782060565 PK__tmp_ms_x__CDEC17C03A4CDB46 0 IX_this_is_my_fk_index 15.7538877620014
花了33分钟。
结果是 PK__tmp_ms_x__CDEC17C03A4CDB46 0.01 PK__tmp_ms_x__CDEC17C03A4CDB46 0 IX_this_is_my_fk_index 0
问题： 自上述操作以来，查询速度并没有真正改变。这是正常的吗？
鉴于我在SQL Azure中无法控制很多事情，重建索引是否有意义？
BTW：我不是，也不是DBA ...只是一名开发人员答案 0 :(得分：4)
如果实际使用索引，重建索引将很重要。如果索引不用于您正在运行的查询，那么您将看不到差异。如果它只是轻微使用，如果你运行统计数据，你会发现一个微小的差异。如果它被大量使用，您应该会在大多数情况下看到良好的性能提升。 Microsoft SQL需要注意的另一件事是索引碎片有时无关紧要。通常，当我选择是否重建索引时，我会查看页数和碎片。如果即时运行查询并且我遇到了性能问题，并且我正在使用索引，并且索引有超过16000个页面，并且索引碎片超过50％，则重建它。如果表格很小或我可以使用在线选项，我会继续并同时重建所有这些选项..
特别是对于Azure，我的观点是，如果你想提高性能，它仍然是一个很好的步骤，因为它很容易，即使你不能确定结果。无论是否共享服务以及您是否可以控制硬件层，查看索引碎片和重建索引都是您可以访问的，那么为什么不使用它？
所以我想简短的回答是肯定的，在某些情况下。
我建议，而不是手动查看索引并重建它们，设置每夜或每周作业，当您的数据库最不活跃时运行。让它遍历所有表并重建索引。如果你有很多表，你也可以给它一个设定的运行时间，然后使它成为有状态的＆＃34; （您可以使用表格来保留进度信息），以便记住它停止的位置并在下一次计划的运行中恢复。