在内部SQL数据库中，通常有一个维护计划，以便在不经常使用索引时偶尔重建索引。
如何在Azure SQL DB中进行设置？
P.S：我之前曾尝试过，但是由于找不到任何选择，我想他们可能会自动执行，直到我阅读this post并尝试：
SELECT
DB_NAME() AS DBName
,OBJECT_NAME(ps.object_id) AS TableName
,i.name AS IndexName
,ips.index_type_desc
,ips.avg_fragmentation_in_percent
FROM sys.dm_db_partition_stats ps
INNER JOIN sys.indexes i
ON ps.object_id = i.object_id
AND ps.index_id = i.index_id
CROSS APPLY sys.dm_db_index_physical_stats(DB_ID(), ps.object_id, ps.index_id, null, 'LIMITED') ips
ORDER BY ps.object_id, ps.index_id
并发现我有需要维护的索引
最佳答案
我将指出，大多数人根本不需要考虑在SQL Azure中重建索引。是的，B +树索引可能会碎片化，是的，与具有经过优化的索引相比，这可能会导致一些空间开销和一些CPU开销。因此，在某些情况下，我们与客户合作来重建索引。 （主要方案是客户当前可能会用完空间，因为由于当前体系结构，SQL Azure中的磁盘空间受到一定限制）。因此，我鼓励您退后一步，并认为使用SQL Server模型来管理数据库并不是“错误的”，但是它可能值得也可能不值得您付出。
（如果最终确实需要重建索引，欢迎使用其他张贴者在此处发布的模型-它们通常是脚本任务的良好模型。请注意，SQL Azure托管实例还支持SQL Agent，您也可以使用创建作业以编写维护操作脚本（如果您选择的话）。
以下是一些详细信息，可以帮助您确定是否可以进行索引重建：
您引用的链接来自2013年的一篇文章。该文章之后，SQL Azure的体系结构已完全重做。具体而言，硬件体系结构从基于本地旋转磁盘的模型转变为基于本地SSD的模型（在大多数情况下）。因此，原始帖子中的指导已过期。
在当前体系结构中，您可能会遇到碎片化索引空间不足的情况。您可以选择重建索引或移到较大的预留空间一段时间（这将花费更多的钱），以支持更大的磁盘空间分配。 [由于机器上的本地SSD空间有限，因此保留大小大致与机器的比例相关。随着我们获得具有更大/更多驱动器的较新硬件，您将拥有更多的扩展选项。
与旋转磁盘相比，SSD碎片影响相对较低，因为随机IO的成本实际上并不比顺序IO高。多走一些B +树中间页的CPU开销是适度的。通常情况下，我通常会看到最多5-20％的开销（这可能会或可能不会证明定期重建的合理性，而重建对重建工作量的影响更大）
如果使用的是查询存储（在SQL Azure中默认为打开），则可以评估特定的索引重建是否对您的性能有明显的帮助。您可以进行此测试，以查看工作量是否有所改善，然后再花时间自行构建和管理索引重建操作。
请注意，SQL Azure当前没有针对用户工作负载的数据库内资源治理。因此，如果开始重建索引，最终可能会消耗大量资源并影响您的主要工作量。当然，您可以尝试将工作安排在下班时间进行，但是对于在全球拥有大量客户的应用程序而言，这可能是不可能的。
此外，我将注意到许多客户“因为他们希望更新统计信息”而拥有索引重建作业。不必为了重建统计信息而重建索引。在最近的SQL Server和SQL Azure中，用于统计信息更新的算法在较大的表上变得更加激进，并且在客户查询最近插入的数据（自上次统计信息更新以来）的情况下，我们用于估计基数的模型已更改，以实现更高的兼容性。水平。因此，通常情况下，客户甚至根本不需要进行任何手动统计信息更新。
最后，我将注意到，过时的统计数据的影响是历史上您将获得计划选择的回归。对于重复查询，通过在查询存储区中引入自动调整功能可以缓解许多影响（如果与以前的计划相比，如果它注意到查询性能有较大的下降，则会强制执行先前的计划）。
我向客户提供的官方建议是，不要烦恼索引重建，除非他们拥有已证明其实际需求（收益超过成本）的Tier-1应用程序，或者是他们正在尝试调整工作负载的SaaS ISV弹性池或多租户数据库设计中的许多数据库/客户上，因此他们可以减少COGS或避免在大型数据库上耗尽磁盘空间（如前所述）。在平台上拥有的最大客户中，有时会看到与客户手动进行索引操作的价值，但是我们经常不需要做常规工作，以防万一。 SQL团队的意图是，您根本不必为此烦恼，而可以专注于应用程序。当然，总有一些事情可以添加或改进到我们的自动机制中，因此，我完全允许单个客户数据库可能需要执行此类操作。除了我提到的案例，我还没有见过任何其他人，即使那些案例也很少出现。
我希望这为您提供了一些背景信息，以了解为什么尚未在平台中完成此操作-与其他紧迫的需求相比，对于我们今天服务的绝大多数客户数据库而言，这并不是一个问题。当然，我们会重新审视构建每个计划周期所需的事情清单，并且会定期查看此类机会。
祝您好运-无论您在这里取得什么成果，我希望这可以帮助您做出正确的选择。
真诚的
科纳·坎宁安
SQL架构师
关于sql-server - 如何设置Azure SQL自动重建索引？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/48681024/