什么时候索引(在DBMS中)是一个坏索引?

时间:2009-05-14 04:09:33

标签: sql indexing

当索引是坏索引时,有人能告诉我吗?

8 个答案:

答案 0 :(得分:11)

如果从未搜索索引列并且表经过大量更新,则无法获得indeces用于的性能优势。相反,你可能会遇到性能损失。

答案 1 :(得分:11)

索引几乎无条件坏的一种情况是,如果有另一个索引使用相同的列(以相同的顺序)作为前缀:

CREATE INDEX ix_good ON SomeTable(Col1, Col2, Col3);
CREATE INDEX ix_bad  ON SomeTable(Col1, Col2);

糟糕的索引会浪费磁盘空间并减慢修改操作,从而无益。

答案 2 :(得分:9)

之前我已经联系过了,我会再次链接到它,因为它很棒:

SQL Indexing in 9 Minutes and a Half, by Stephane Faroult.

答案 3 :(得分:5)

要记住索引的一个重要事项(除了前面提到的“实际使用”部分)是选择性的概念。

构造索引时,您希望在具有“高选择性”概率的列上创建索引。这需要对列中的数据有所了解(根据您对样本数据的域/可用性的了解,您可能拥有或不拥有该数据)。

选择性=不同值的数量/总行数

让我们使用表“People”,其中包含Given_name,Surname,Gender,Age

的列

例如,在诸如Gender之类的列上创建索引(性别被限制为NULL,M或F)在查询期间不会提供太多好处(特别是如果查询已经因其他原因导致表扫描) 。在任何情况下,该指数的选择性都会非常低。根据DBMS,使用此索引实际上可能比全表扫描更糟糕。

但是,在(Given_name,Surname)上创建复合索引会在针对这些列执行查询时提供好处。该指数(对大多数人群而言)的选择性非常好。

选择性为1的索引是理想的,但是,实现1的选择性的唯一方法是在非可空列上具有唯一索引。

另外,请记住,您可以轻松编写查询以“跟踪”索引及其选择性。

答案 4 :(得分:1)

如果从未使用该字段,那么它就是一个糟糕的索引(如果您觉得不必要的事情很糟糕。)。

答案 5 :(得分:1)

索引是为了帮助我们更快地搜索行。

如果索引列未用于搜索,则无法定义它。

如果该列 中的值不断变化 ,那么它将是数据库服务器的额外工作(用于重新编制索引)

如果表中有 过多的插入和删除 ,那么服务器将会有额外的工作

答案 6 :(得分:1)

拥有索引(创建和维护结构)会带来内在的性能损失。您通常希望该命中获得更快扫描的好处。当你没有得到好处时,它只是一个净损失而且这是一个糟糕的指数。

可能的原因:

  • 从不使用索引
  • 冗余索引
  • 不经常扫描但持续更新的表格(由于表格很少被扫描,因此索引的效果超出了优势)。
  • 经常扫描并持续更新的表格。在这种情况下,您可以通过为插入/更新提供无索引表以及具有每日或每小时批量更新的扫描索引的表来获得索引和快速更新/插入的好处(在某些情况下,这不会当然没有用。如果在这种情况下遇到严重的性能问题,你需要获得更好的硬件或重新设计应用程序。)

如何找到不良指数?大多数RDBMS都有显示查询计划的选项,您可以看到您设置的索引是否按照您期望的方式使用。这引出了我最后的建议,考虑你的索引,永远不要创建一个“以防万一”。

答案 7 :(得分:1)

如果您从未搜索过它,那么索引就会很糟糕。例如,如果您从未在同一查询中使用Col1,Col2和Col3进行搜索,则索引(Col1,Col2,Col3)会浪费资源。