SQL Azure。创建索引建议和性能

Question

我在Azure SQL S3层上获得了几个 CREATE INDEX建议。

在完成之前，我想知道在索引1000万条记录时遇到的一些问题。

1. 我们能否大致知道索引进度或完成时间？
2. 索引是否以异步（或者我们可以说是懒惰索引）的方式工作？或者它阻止查询到表/数据库？
3. 在索引编制期间，我们需要了解有关性能下降的任何信息吗？如果是这样，我们可以预期会有多少退化吗？
4. 它的执行方式与我的CREAT INDEX命令不同吗？
5. 如果数据库是readonly-georedundant配置的，我假设索引配置本身也被复制。但索引工作是否单独运作？
6. 如果索引是在自己的（复制的）数据库上执行的，则层主服务器（S3层）到副本（S1）可能具有不同的索引进度。这是对的吗？

Answer 1

  

我们能否大致知道索引进度或完成时间？

您可以使用get to know amount of space，但不能使用索引创建时间。您可以使用sys.dm_exec_requests

跟踪进度

同样使用SQL2016（azure compatabilty level 130），有一个new DMV called Sys.dm_exec_query_profiles ..可以比exec requests DMV更好地跟踪准确状态..

  

索引是以异步（或者我们可以说是懒惰索引）方式工作的吗？或者它阻止查询到表/数据库？

创建索引有两种方法 1.Online
2.Offline

当您在线创建索引时，您的表将不会被阻止*，因为SQL维护索引的单独副本并平行更新两个索引

使用离线方法，您将遇到阻止，表也将无法使用

  

在索引编制期间，我们需要了解有关性能下降的任何信息吗？如果是这样，我们可以预期会有多少退化吗？

您将遇到额外的IO负载，内存增加。这无法准确估计。

  

它的执行方式与我的CREATE INDEX命令不同吗？   创建索引完全是一个单独的声明，我不确定你的意思

     

如果数据库是readonly-georedundant配置的，我假设索引配置本身也被复制。但索引工作是否单独运作？

如果在自己的（复制的）数据库上执行索引，则层主服务器（S3层）到副本（S1）可能具有不同的索引进度。这是对的吗？

记录索引创建，并且所有TLOG也在辅助节点上重播。所以there is no need to do index rebuilds on secondary ..