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.2335782060565 PK__tmp_ms_x__CDEC17C03A4CDB46 0 IX_this_is_my_fk_index 15.7538877620014

花了33分钟。

结果为PK__tmp_ms_x__CDEC17C03A4CDB46 0.0 1 PK__tmp_ms_x__CDEC17C03A4CDB46 0 0 IX_this_is_my_fk_index 0

问题:执行上述操作后，查询速度并没有发生真正的变化。这是正常的吗？

考虑到在SQL中有很多事情我无法控制，那么重建索引是否有意义呢？

顺便说一句:我不是，也从来没有做过DBA.只是个开发人员

Answer 1

如果实际使用索引，则重建索引将非常重要。如果没有将索引用于正在运行的查询，那么您将不会看到有什么不同。如果它只被轻松地使用，那么如果您运行stats，您将看到一个细微的差别。如果它被大量使用，大多数情况下，您应该会看到良好的性能提高。Microsoft需要注意的另一件事是，索引碎片有时是不相关的。通常，当我选择是否重建一个索引时，我会查看页面计数和碎片。如果im运行一个查询，而我有性能问题，而im使用这个索引，并且索引有超过16000页，而且索引是50%以上的零碎，那么我就会重新构建它。如果表很小，或者我可以使用在线选项，我将继续同时重建它们。

特别是对于Azure，我的观点是，如果你试图提高性能，这仍然是一个很好的步骤，因为它是如此容易，即使你不能肯定的结果。它是否是共享服务，以及是否可以控制硬件层、查看索引碎片和重建索引都是您可以访问的东西，那么为什么不使用它呢？

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

我建议的不是手动检查和重建索引，而是设置一个夜间或每周运行的作业，在数据库最不活跃的时候运行。让它遍历所有的表并重建索引。如果您有很多表，您也可以给它一个设定的运行时间，然后使它“有状态”(您可以使用一个表来保留进度信息)，这样它就可以记住它停止运行的位置，并在下一次预定运行时继续运行。