#1 楼
更新现在已在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点本质上是不可解决的。
然而，可能由专业技术人员不断监视，诊断和预期（或至少对）工作负载变化的绝大部分安装都不是在这种理想情况下。
Microsoft Research的AutoAdmin项目自1996年以来一直在运行
该项目的目标是通过利用工作负载的知识来使数据库自动调整和
自动管理
项目主页列出了几个有趣的项目。一个与这里的问题特别相关的问题
当没有可用的DBA时出现另一个有趣的问题（例如嵌入式数据库或小型企业）。在这种情况下，
低接触连续索引调整方法可能变得很重要。我们
在ICDE的“物理设计调整的在线方法”中探索了解决方案... [br /> 2007年。
作者声明
随着越来越多的DBMS功能（例如在线索引）的出现，
对于探索更先进的物理设计自动解决方案很有吸引力。
进一步发展了现代技术。
本文介绍了一种算法
它的主要特点是：
随着查询的优化，我们确定了一个相关的候选索引集，可以提高性能。此功能允许查询
处理与在
背景中建立的索引并行进行。
在执行时，我们跟踪由于没有这样的索引而可能丢失的潜在好处。候选索引以及存在查询，更新和空间约束的现有索引的用途。
在我们收集了足够的证据表明物理设计变更是有益的之后，我们自动触发索引的创建或删除。
问题的在线性质意味着我们通常会落后于了解未来的最佳解决方案。但是，通过仔细地衡量证据，我们可以确保我们不会遭受重大的“迟来”决定，从而限制了已发生的损失额
该算法的实现允许响应服务器负载的变化而进行节流，并且如果在创建过程中工作负载的变化和预期收益低于认为值得的程度，还可以中止索引的创建。
作者关于在线与传统物理调优的结论。
当DBA不确定未来的行为时，本工作中的在线算法非常有用
的工作量，或者没有可能进行全面的分析或建模。如果DBA拥有有关
工作负载特征的完整信息，那么使用
现有工具（例如[2，3]）进行静态分析和部署将是更好的选择。
这里的结论与另一篇论文类似。自主查询驱动的索引调整
如果整个工作量都是已知的，我们的方法将无法胜过索引顾问。提前。但是，在动态环境中，随着工作负载的不断变化和变化，查询驱动的方法会产生更好的结果。
评论
假设DBA的技能永远无法自动化，这对DBA的职业来说是极其危险的。由于正在转向软件定义的数据中心，因此这正在扼杀网络专家的职业。作为优秀的DBA，我们应该领导自动化工作。
– Gaius
13年6月13日在10:47
#2 楼
您采用的索引设计更多的是艺术而不是科学。 RDBMS不够智能，无法处理常见的工作负载并设计智能索引策略。依靠人工干预（阅读：DBA）来分析工作负载并确定什么是最佳方法。如果没有使用索引的代价，那么只添加一个无限量就是a弹枪方法索引数。但是，由于数据修改（INSERTS，UPDATES和DELETES）会影响表上已启用的索引，因此这些索引将产生可变的开销。
需要人为设计和巧妙地进行策略创建索引以最大程度地提高读取性能，同时减少数据修改开销。
评论
评论不作进一步讨论；此对话已移至聊天。
–保罗·怀特♦
17年8月29日在7:36
#3 楼
实际上，有一些数据库可以做到这一点。例如，谷歌的BigTable和亚马逊的SimpleDB自动创建索引（尽管两者都不是RDBMS的）。还有至少一个MySQL RDBMS引擎可以做到这一点。 SQL Server还会跟踪它认为您应该创建的索引，尽管它并没有真正创建索引那么远。问题出乎意料地难以解决，因此大多数数据库也就不足为奇了不要自动创建它们（BigTable / SimpleDB放弃了它，因为它们不允许任意联接，这使事情变得更加容易）。此外，动态创建索引是一个耗时的过程，需要独占访问整个表-绝对不希望在表联机时发生任何事情。
由业余爱好者编写的LAMP Web应用程序甚至不知道索引是什么，我仍然认为此功能对某些人将是有益的。
评论
我要说的是，将BigTable（及其派生类，例如Cassandra，HBase等）与RDBMS解决方案进行比较，就是将苹果与橙子进行比较-BigTable及其派生类更像是巨大的键值或列式存储，而行键本质上就是一个索引。
–苏曼
2013年6月4日16:56
究竟。这个问题用rdbms标记，我不认为BigTable属于此类。
–超立方体ᵀᴹ
13年4月4日在22:14
@ypercube：...是的，我在回答中提到了这一点；但至少值得一提的是，它仍然值得了解。我还提到了其他一些RDBMS数据库，它们可以做到这一点，并解释了为什么它不常见。这绝对不值得一票。
– BlueRaja-Danny Pflughoeft
2013年6月5日在2:21
我没有投票。我同意这是一个非常困难的问题。
–超立方体ᵀᴹ
2013年6月5日9:25
#4 楼
尽管已经有了一些广泛的答案，但它们似乎绕过了真正的答案：索引并不总是可取的。评论中提到的汽车比喻，您最好说一下为什么不行。所有装有极限运动套件的汽车吗？部分原因是费用，但也要归因于许多人不需要或不希望使用低调轮胎和坚硬的悬挂系统的事实。
所以也许每个插入有1000次读取，为什么不具有自动创建的索引呢？如果表很宽且查询不同，为什么不进行几个查询呢？也许提交是时间紧迫的，而读取不是紧要的。在这种情况下，放慢插入速度可能是不可接受的。也许您正在使用有限的磁盘空间，而您又负担不起更多索引占用您拥有的空间。
关键是，不会自动创建索引，因为它们不是一切的答案。设计索引不仅仅是说“嘿，这将加快我的阅读速度”，还需要考虑其他因素。
评论
+1虽然使这些工作自动化当然是可行和可行的，但我们并非总能通过一个系统实现的一堆魔术索引来获得更好的收益，而该系统对明天如何使用数据一无所知，不必管您的写与读取权衡阈值。前几天我在博客上写了一些，但是显然还有很多要讨论的。
–亚伦·伯特兰（Aaron Bertrand）
2013年6月8日18:09
>也许提交是时间紧迫的，而读取不是紧要的。在这种情况下，放慢插入速度可能是不可接受的。这样的好答案，非常有帮助。
–悉达多
16年3月18日在6:57
#5 楼
他们可以分析过去的查询并建议/创建索引，但这并不是最佳方法，因为索引会达到平衡，从而以成本为代价加快了您想要优化的速度，并且服务器不知道您的意图。#6 楼
它们不是很聪明，而是一段代码。每次将新数据输入数据库时，它都需要为其找到一个新位置，并在需要时找到一个地图来查找它。
索引听起来比实际要容易，您只是给一个新的数据块赋予一个新的数字？
那么，下一个查询不是关于最后一个数据块，而是早于约36271个块，那又如何呢？您可以通过索引轻松找到它，对吗？但是，如果查询中包含1997年生产的36271旧块中的“钓鱼”一词，该怎么办？ ？在旧文章中没有提到捕鱼。
如果数据一个一个地进入数据库，则可以像这样进行索引。
但是简单的索引将导致错误的结果和/或迟早会降低性能...
评论
您的汽车会自动修复自己的flat胎吗？一个更准确的类比是您的ECU是否会更改提供给燃油泵的功率以固定燃油/机油流速并补偿脏线？答案是肯定的。
数据库已经可以在一张表上放置索引，而现在它只是需要我们命令它，汽车实际上无法替换轮胎，除非我们为其建立一些臂来使用。
它们确实适用–对于具有UNIQUE约束的列。
如果您使用Google“自我调整数据库”，您会发现很多对此的研究。也许将来会对此有所了解。