为什么数据库不自动创建自己的索引？

Question

我原以为数据库会对它们经常遇到的事情有足够的了解，并且能够对它们所面临的需求做出响应，以便它们可以决定向高度请求的数据添加索引。

Answer 1

更新

这现在在 SQL Server Azure 中实现。它生成建议

并且可以将索引管理配置为自动。

启用自动索引管理

您可以将 SQL 数据库顾问设置为自动实施建议。当建议可用时，它们将自动应用。与服务管理的所有索引操作一样，如果性能影响为负面，则建议将被恢复。

原答案

一些数据库已经（有点）自动创建索引。

在 SQL Server 中，执行计划有时可以包括索引假脱机操作符，其中 RDBMS 动态创建数据的索引副本。然而，这个 spool 不是与源数据保持同步的数据库的持久部分，它不能在查询执行之间共享，这意味着此类计划的执行可能最终会重复创建和删除相同数据的临时索引。

也许在未来 RDBMS 将有能力根据工作负载动态删除和创建持久索引。

索引优化的过程归根结底只是成本效益分析。虽然原则上人类可能有更多关于查询在工作负载中的相对重要性的信息，但没有理由不能将这些信息提供给优化器。SQL Server 已经有一个资源调控器，它允许根据优先级将会话分为具有不同资源分配的不同工作负载组。

Kenneth 提到的缺失索引 DMV 并不打算盲目实施，因为它们只考虑特定查询的好处，而没有尝试考虑潜在索引对其他查询的成本。它也不合并类似的缺失索引。例如，此 DMV 的输出可能会报告A,B,C和A,B INCLUDE(C)

这个想法目前的一些问题是

• 任何不实际创建索引的自动分析的质量都将高度依赖于成本计算模型的准确性。
• 即使在自动化分析领域内，离线解决方案也将能够比在线解决方案更彻底，因为在线解决方案不应向实时服务器增加大量簿记开销并干扰其执行查询的主要目的。
• 为响应工作负载而自动创建的索引必然是为响应发现它们有用的查询而创建的，因此将落后于提前创建索引的解决方案。

预计成本计算模型的准确性会随着时间的推移而提高可能是合理的，但第 2 点看起来更难解决，而第 3 点本质上是不可解决的。

然而，可能绝大多数安装都没有处于这种理想情况下，技术人员会持续监控、诊断和预测（或至少对工作负载的变化做出反应）。

微软研究院的AutoAdmin 项目自 1996 年开始运行

该项目的目标是通过利用工作负载的知识使数据库自我调整和自我管理

项目主页列出了几个有趣的项目。一个与这里的问题特别相关

当没有可用的 DBA（例如嵌入式数据库或小型企业）时，会出现另一个有趣的问题。在这种情况下，低接触连续索引调整方法可能变得重要。我们在 ICDE 2007 中探索了解决方案......[in]“物理设计调整的在线方法”。

作者指出

随着越来越常见的 DBMS 功能（如在线索引），探索更自动化的解决物理设计问题的解决方案是很有吸引力的。

论文介绍了一种算法

其主要特点是：

• 随着查询的优化，我们确定了一组可以提高性能的相关候选索引。此功能允许查询处理与在后台构建的索引并行继续。
• 在执行时，我们跟踪由于没有这样的候选索引而失去的潜在好处，以及在存在查询、更新和空间限制的情况下现有索引的效用。
• 在我们收集到足够的“证据”表明物理设计更改是有益的后，我们会自动触发索引创建或删除。
• 我们问题的在线性质意味着我们通常会落后于了解未来的最佳解决方案。然而，通过仔细衡量证据，我们确保我们不会受到“迟到”决定的严重影响，从而限制了发生的损失金额

该算法的实现允许限制以响应服务器负载的变化，如果在创建期间工作负载发生变化并且预期收益低于认为值得的点，也可以中止索引创建。

作者关于在线与传统物理调整主题的结论。

当 DBA 不确定工作负载的未来行为，或者无法进行全面分析或建模时，这项工作中的在线算法非常有用。如果 DBA 拥有有关工作负载特征的完整信息，那么通过现有工具（例如 [2, 3]）进行静态分析和部署将是更好的选择。

这里的结论与另一篇论文Autonomous Query-driven Index Tuning 中的结论相似

如果事先知道整个工作量，我们的方法就无法击败索引顾问。但是，在工作负载不断变化和变化的动态环境中，查询驱动的方法会产生更好的结果。

Answer 2

您采用的索引设计与其说是科学，不如说是一门艺术。RDBMS 不够智能，无法处理常见的工作负载并设计智能索引策略。分析工作负载并确定最佳方法取决于人工干预（阅读：DBA）。

如果没有索引的惩罚，那么添加无限数量的索引将是一种霰弹枪方法。但是因为数据修改（插入、更新和删除）对表上启用的索引有影响，所以这些索引的可变开销将会存在。

需要人为设计和策略来巧妙地创建索引，以最大限度地提高读取性能，同时将数据修改开销降至最低。

Answer 3

事实上，有一些数据库可以做到这一点。例如，Google 的 BigTable和Amazon 的 SimpleDB 会自动创建索引（尽管它们都不是 RDBMS）。还有至少一个 MySQL RDBMS 引擎可以做到这一点。SQL Server 还跟踪它认为您应该创建的索引，但实际上并没有创建索引。

这个问题出人意料地难以纠正，因此难怪大多数数据库不会自动创建它们（BigTable/SimpleDB 可以避免使用它，因为它们不允许任意连接，这使事情变得更加容易）。此外，动态创建索引是一个耗时的过程，需要对整个表进行独占访问 - 绝对不是您希望在表在线时发生的事情。

但是，考虑到由甚至不知道索引是什么的业余爱好者编写的 LAMP Web 应用程序的数量，我仍然认为此功能对某些人来说是有益的。

Answer 4

虽然已经有一些广泛的答案，但它们似乎绕过了真正的答案：索引并不总是可取的。

用评论中提到的汽车类比，你最好说为什么不是所有的汽车都配备极限运动套装？部分原因是费用，但也归结为很多人不需要或不想要低调的轮胎和坚硬的悬架；这是不必要的不​​舒服。

因此，也许您每次插入都有 1,000 次读取，为什么没有自动创建的索引？如果表很宽，查询多种多样，为什么不多一些呢？也许提交是时间关键的，而读取不是；在这种情况下，放慢插入速度可能是不可接受的。也许您正在使用有限的磁盘空间，并且您无法承受额外的索引占用您所拥有的空间。

关键是，索引不会自动创建，因为它们不是所有问题的答案。设计索引不仅仅是说“嘿，这将加快我的阅读速度”，还有其他因素需要考虑。

Answer 5

他们可以分析过去的查询和建议/创建索引，但是由于指标取得平衡，以加快你想要什么优化这个功能不能很好地工作，在成本和服务器无法知道你的意图。