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

前端之家收集整理的这篇文章主要介绍了为什么数据库不自动创建自己的索引?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我原以为数据库会对他们经常遇到的内容有足够的了解,并且能够响应他们所处的需求,他们可以决定为高要求的数据添加索引.

解决方法

更新

现在,这在sql Server Azure中实现.它会产生建议

和指数管理can be configured to be automatic.

Enable automatic index management

You can set the sql Database Advisor to implement recommendations
automatically. As recommendations become available they will
automatically be applied. As with all index operations managed by the
service if the performance impact is negative the recommendation will
be reverted.

原始答案

有些数据库已经(有点)自动创建索引.

sql Server中,执行计划有时可以包含一个Index Spool运算符,其中RDBMS动态创建数据的索引副本.但是,此假脱机不是数据库的持久部分,与源数据保持同步,并且不能在查询执行之间共享,这意味着执行此类计划可能最终会在同一数据上重复创建和删除临时索引.

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

指数优化的过程最终只是成本效益分析.虽然原则上人类可能有更多关于查询在工作负载中的相对重要性的信息,但没有理由不能将此信息提供给优化器. sql Server已经有一个资源调控器,允许根据优先级将会话分类到具有不同资源分配的不同工作负载组.

Kenneth提到的缺失索引DMV并非盲目实现,因为它们只考虑特定查询的好处,并且不会尝试将潜在索引的成本考虑到其他查询.它也没有整合类似的缺失指数.例如此DMV的输出可能会报告A,B,C和A上的缺失索引,B包括(C)

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

>实际上不创建索引的任何自动分析的质量将高度依赖于成本计算模型的准确性.
>即使在自动分析领域,离线解决方案也能够比在线解决方案更彻底,因为在线解决方案必须不会给实时服务器增加大量的簿记开销,并且干扰其执行查询的主要目的.
>必须创建响应于工作负载自动创建的索引,以响应会发现它们有用的查询,因此将滞后于预先创建索引的解决方案.

期望成本计算模型的准确性随着时间的推移而改善可能是合理的,但是第2点看起来更难解决,而第3点本质上是不可解决的.

然而,绝大多数安装可能不是在这种理想情况下,技术人员不断监视,诊断和预测(或至少对工作负载的变化做出反应).

微软研究院的AutoAdmin project自1996年以来一直在运行

The goal of this project is to make databases self-tuning and
self-administering by exploiting knowledge of the workload

项目主页列出了几个有趣的项目.一个与此处的问题特别相关

Another interesting problem arises when there is no DBA available
(e.g. an embedded database or a small business). In such scenarios,a
low touch continuous index tuning approach may become important. We
have explored solutions …[in] “07004” in ICDE
2007.

作者说

With increasingly common DBMS features like online indexes,it is
appealing to explore more automatic solutions to the physical design
problem that advance the state of the art.

本文介绍了一种算法

Its main characteristics are:

  • As queries are optimized,we identify a relevant set of candidate indexes that would improve performance. This feature allows query
    processing to continue in parallel with indexes that are built in the
    background.
  • At execution time,we track the potential benefits that we
    lose by not having such candidate indexes and also the utility of
    existing indexes in the presence of queries,updates,and space
    constraints.
  • After we gather enough “evidence” that a physical design change is beneficial,we automatically trigger index creations or deletions.
  • The online nature of our problem implies that we will generally lag behind optimal solutions that know the future. However,by carefully
    measuring evidence,we ensure that we do not suffer from “late”
    decisions significantly,thus bounding the amount of incurred loss

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

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

The online algorithms in
this work are useful when DBAs are uncertain about the future behavior
of the workload,or have no possibility of doing a comprehensive
analysis or modelling. If a DBA has full information about the
workload characteristics,then a static analysis and deployment by
existing tools (e.g.,[2,3]) would be a better alternative.

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

Our approach cannot beat the index advisor if the whole workload is known in advance. However,in dynamic environments with evolving and changing workloads the query-driven approach produces better results.

猜你在找的MsSQL相关文章