Azure的用于自动调整的SQL数据库功能根据数据库使用情况创建和删除索引。我已经将一个旧的数据库导入到Azure中，该数据库没有定义全面的索引，并且它似乎在减少CPU和放大器方面做得很好。在相对较短的时间内使用DTU。
感觉不对 - 但这是否意味着我可以在不定义索引的情况下开展前进？有没有人这样做？ SSMS索引编辑器很痛苦，修改起来很慢。不必担心/维护索引会加快开发时间。
答案 0 :(得分：2)
自动调整利用了三个方面：查询存储，缺失索引和机器学习。
首先，最后一个已知的好计划是查询存储的武器化。这是在Azure和SQL Server 2017中。它会发现计划更改后性能下降的查询（以及相当多的执行，而不仅仅是一次），并将恢复到该计划。如果性能下降，它会关闭它。这很棒。但是，如果您编写垃圾代码或者数据结构不正确或过时的统计数据，那么它并没有多大帮助。
Azure中的自动索引使用两件事，缺少优化器的索引建议和Azure上的机器学习。有了这些，如果丢失的索引在12-18小时内出现很多（阅读关于自动化的博客文章），您将获得索引建议。它测量了另外12-18小时，如果该指数有所帮助，它会保留，如果没有，它会继续。这也很棒。但是，它有两个问题。首先，和以前一样，如果你有垃圾代码等，这只会在边缘真正有用。其次，优化器缺少的索引建议并不总是最佳索引。例如，当我撰写博客文章时，它恰当地确定了缺失的索引，但它错过了INCLUDE列甚至比它建议的索引更好的事实。
人脑和眼球仍将解决更难的问题。这些自动化带走了许多更容易，最轻松的问题。总的来说，这是一件好事。但是，不要把它与灵活性混淆，以解决所有与性能相关的问题。绝对没有。