sql-server - SQL Azure。创建索引推荐和性能

Question

我在 Azure SQL S3 层上收到了几条CREATE INDEX 建议。

在讨论之前，我想了解一下对 1000 万条记录进行索引时的一些问题。

1. 我们能否知道索引编制进度或大约完成时间？
2. 索引是否以异步(或者我们可以说惰性索引)方式工作？或者它会阻止对表/数据库的查询？
3. 关于索引期间的性能下降，我们需要了解什么吗？如果是这样，我们可以预期退化程度吗？
4. 它的执行方式与我的 CREAT INDEX 命令不同吗？
5. 如果数据库配置为只读地理冗余，我假设索引配置本身也被复制。但是索引作业是单独运行的吗？
6. 如果在自己的(复制)数据库上执行索引，则主层(S3 层)到副本层(S1)可能会有不同的索引进度。这是正确的吗？

Answer 1

Can we know indexing progress or completion time approximately?

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

跟踪进度

对于 SQL2016(azure 兼容性级别 130)，还有 new DMV called Sys.dm_exec_query_profiles ..它可以比 exec requests DMV 更好地跟踪准确的状态..

Does indexing work in asynchronous (or we can say lazy index) manner? Or it blocks query to the table/database?

创建索引有两种方式
1.在线
2.离线

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

使用离线方式，您会遇到阻塞，并且 table 也将不可用

Is there anything we need to know about performance degradation during indexing? If so, can we expect amount of degradation?

您将经历额外的 IO 负载、内存增加......这无法准确估计。

Does it perform differently from my CREATE INDEX command? Create Index is altogether a seperate statement ,i am not sure what you meant here

If the database is readonly-georedundant configured, I assume that index configuration itself is replicated either. But does indexing job operate separately?

如果在自己的(复制的)数据库上执行索引，则主层(S3 层)到副本层(S1)可能会有不同的索引进度。这是正确的吗？

记录索引创建，并且所有 TLOG 也在辅助设备上重放。so there is no need to do index rebuilds on secondary ..