sql - Azure SQL 数据库中的索引

Question

我有一个 Azure SQL 数据库，到目前为止已证明非常成功。它已经使用了大约 20 个月，没有进行任何维护......但它已经处理了很多。有些表有数百万行，当查询已建立索引的列时，使用与其交互的 Web 应用程序时，查询响应时间是可以接受的。

但是，我读到了有关重建索引的相互矛盾的建议。

这家伙说这样做没有意义:http://beyondrelational.com/modules/2/blogs/76/posts/15290/index-fragmentation-in-sql-azure.aspx

这家伙说继续重建: https://alexandrebrisebois.wordpress.com/2013/02/06/dont-forget-about-index-maintenance-on-windows-azure-sql-database/

我已经在一些存储几千行的较小表上运行了一些重建索引语句。一些碎片会下降约 1/2...然后如果我第二次运行它，它可能会下降约

这些重建大约需要 2-10 秒，具体取决于表的大小...

然后我在一个大约有 200 万行的表上运行了一个索引，该索引具有以下碎片:PK__tmp_ms_x__CDEC17C03A4CDB46 55.2335782060565PK__tmp_ms_x__CDEC17C03A4CDB46 0IX_this_is_my_fk_index 15.7538877620014

花了 33 分钟。

结果是PK__tmp_ms_x__CDEC17C03A4CDB46 0.01PK__tmp_ms_x__CDEC17C03A4CDB46 0IX_this_is_my_fk_index 0

问题:自从执行上述操作以来，查询速度并没有真正改变。这正常吗？

鉴于 SQL Azure 中有很多事情我无法控制，重建索引是否有意义？

顺便说一句:我不是、也从来不是 DBA……只是一名开发人员

Answer 1

如果索引确实被使用，重建索引就很重要。如果索引没有用于您正在运行的查询，那么您将看不到差异。如果只是轻微使用，那么运行统计数据时您会发现细微的差异。如果它被大量使用，大多数时候您应该会看到性能的良好提升。使用 Microsoft SQL 时需要注意的另一件事是索引碎片有时是无关紧要的。通常，当我选择是否重建索引时，我会查看页数和碎片。如果我正在运行查询并且遇到性能问题，并且我正在使用索引，并且该索引有超过 16000 个页面，并且该索引的碎片超过 50%，则需要重建它。如果表很小或者我可以使用在线选项，我将继续同时重建所有表..

特别是对于 Azure，我的观点是，如果您正在尝试提高性能，这仍然是一个很好的步骤，因为它非常简单，即使您无法确定结果。无论它是否是共享服务，是否可以控制硬件层，检查索引碎片和重建索引都是您可以访问的，那么为什么不利用它呢？

所以我想简短的答案是肯定的，在某些情况下。

我建议不要手动检查索引并重建它们，而是设置一个每晚或每周的作业，在数据库最不活跃时运行。让它遍历所有表并重建索引。如果您有很多表，您还可以给它设定一个运行时间，然后将其设置为“有状态”(您可以使用表来保留进度信息)，以便它记住它停止的位置并在下一次计划运行时恢复。