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

我本以为数据库会充分了解它们经常遇到的情况，并能够响应他们所提出的要求，即他们可以决定向高度要求的数据添加索引。

更新资料

现在，这已在SQL Server Azure中实现。它产生建议

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

启用自动索引管理

您可以将SQL Database Advisor设置为自动实施建议。当建议可用时，它们将自动应用。与服务管理的所有索引操作一样，如果性能影响为负，则将还原建议。

原始答案

一些数据库确实已经（自动）创建了索引。

在SQL Server中，执行计划有时可以包括Index Spool运算符，RDBMS在其中动态创建数据的索引副本。但是，此后台打印不是数据库中与源数据保持同步的持久部分，并且无法在查询执行之间共享，这意味着执行此类计划可能最终会重复在相同数据上创建和删除临时索引。

也许将来，RDBMS将具有根据工作负荷动态删除和创建持久索引的能力。

索引优化的过程最终只是成本效益分析。从原则上讲，人们可能会获得有关查询相对重要性的更多信息，这是没有道理的，为什么没有信息可以提供给优化人员。SQL Server已经有一个资源调控器，该资源调控器允许根据优先级将会话分为具有不同资源分配的不同工作负载组。

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

这个想法目前存在一些问题

• 不会真正创建索引的任何自动化分析的质量将在很大程度上取决于成本核算模型的准确性。
• 甚至在自动化分析领域，离线解决方案也将比在线解决方案更彻底，因为必须使在线解决方案不要给实时服务器增加大量账簿管理费用，并且不会干扰其执行查询的主要目的。
• 响应于工作负载而自动创建的索引将必然会响应于发现它们有用的查询而创建，因此将落后于预先创建索引的解决方案。

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

但是，可能绝大部分安装都不在理想的情况下，而熟练的人员会不断监视，诊断和预期（或至少对工作负载的变化）。

自1996年以来，Microsoft Research 的AutoAdmin项目一直在运行

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

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

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

作者指出

随着越来越多的DBMS功能（例如在线索引）的出现，探索更先进的物理设计问题自动解决方案非常有吸引力。

本文介绍了一种算法

其主要特点是：

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

该算法的实现允许响应于服务器负载的变化而进行节流，并且如果在创建过程中工作负载发生变化且预期收益低于认为值得的程度，则也可以中止索引的创建。

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

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

这里的结论与另一篇论文《自动查询驱动的索引调整》中的结论相似。

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

您采用的索引设计更多的是艺术而不是科学。RDBMS不够智能，无法处理常见的工作负载并设计智能索引策略。由人为干预（阅读：DBA）来分析工作负载并确定什么是最佳方法。

如果没有使用索引的代价，那么添加无限数量的索引将是a弹枪的方法。但是，由于数据修改（INSERTS，UPDATES和DELETES）会影响表上已启用的索引，因此这些索引将产生可变的开销。

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

实际上，有一些数据库可以做到这一点。例如，谷歌的BigTable和亚马逊的SimpleDB自动创建索引（尽管两者都不是RDBMS的）。还有至少一个MySQL RDBMS引擎可以做到这一点。SQL Server也跟踪它认为您应该创建的索引，尽管它实际上并没有创建索引。

问题出乎意料地难以解决，因此也就不足为奇了，大多数数据库不会自动创建它们（BigTable / SimpleDB放弃了它，因为它们不允许任意联接，这使事情变得非常容易）。此外，动态创建索引是一个耗时的过程，需要独占访问整个表-绝对不是您希望表在线时发生的事情。

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

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

考虑到评论中提到的汽车类比，您最好说为什么所有的汽车都没有配备极限运动套件？部分原因是费用，但也要归因于许多人不需要或不希望使用低调轮胎和坚硬的悬挂系统的事实。这是不必要的不​​舒服。

因此，也许每个插入都有1000次读取，为什么没有自动创建的索引？如果表很宽且查询不同，为什么不进行几个查询呢？也许提交是时间紧迫的，而读取不是紧要的。在这种情况下，放慢插入速度可能是不可接受的。也许您在有限的磁盘空间上工作，而您负担不起其他索引占用您拥有的空间。

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

他们可以分析过去的查询并建议/创建索引，但这并不是最佳方法，因为索引无法平衡以加快您想要优化的成本，而服务器却无法了解您的意图。

他们不聪明，他们只是一段代码。每次将新数据输入数据库时​​，它都需要为它找到一个新位置，并在需要时找到一个地图来查找它。索引听起来比它容易，您只是给新的数据块赋予了新的数字？好吧，如果下一个查询不是关于最后一个数据块，而是关于较早的36271块，那该怎么办？您可以通过索引轻松找到它，对吗？但是，如果查询中包含1997年生产的旧36271块中的“钓鱼”一词，该怎么办？?？在旧文章中一言不发。

如果数据一个接一个地进入数据库，则可以像这样对它建立索引。但是简单的索引将使您错误的结果和/或迟早会降低性能...