具有重复值的列上的数据库索引

Gau*_*rav 9 mysql sql database indexing sybase

如果有一个包含员工详细信息的表,其中包括一列Gender,其值可以是M/F. 现在,在此列上创建索引是否有意义,是否会使搜索更快?逻辑上,如果我们使用where子句包含Gender作为列来激活select语句,它应该将搜索时间缩短一半.但我听说这种索引无济于事,并且在执行查询时实际上会被Database Optimizer忽略.但我不明白为什么?有人可以解释一下吗?

Bar*_*mar 12

在大多数情况下,只能使用一个索引来优化数据库查询.如果查询需要匹配多个索引列,则查询计划程序必须决定使用哪些索引.每个索引都有一个基数,它基本上是表中不同值的数量.具有更高基数的索引将更有效,因为选择与索引匹配的行将导致扫描的行非常少以匹配其他条件.

gender列上的索引只会将表格减半.任何其他指数都会更有效.

作为类比,想想电话簿.如果您有一个针对整个国家/地区的电话簿,那么搜索您想要的特定人员将会非常困难.因此,电话簿通常仅针对某个城市或某个地区的少数城市制作,以使其尺寸合理.但是,如果您使用的是"男性电话簿"而不是区域电话簿,那么它几乎就像整个国家的电话簿一样无法使用.创建新电话簿的标准是它们应该比整个国家的书小得多.当你从一个巨大的尺寸开始时,减少2倍并不是很有用.


Gor*_*off 7

据推测,性别具有两个价值观.一般来说,索引gender不会有帮助.事实上,它可能是有害的.

如果您在没有索引的情况下选择性别,则查询优化器会对数据库页执行全表扫描以满足查询.在典型页面上,一半条目将与查询匹配,因此您将在第一次点击时开始获得结果.

在查询执行的这个阶段,索引通常用于减少正在读取的页面数.但是,如果每个页面都有"M"和"F"的记录,那么仍然必须读取每个页面.更糟糕的是,使用索引意味着您从一个随机页面读取,然后从另一个页面读取,另一个,而不是仅按顺序读取值.跳转页面需要一些额外的时间.如果这些页面都不适合内存,那么就会出现一种叫做颠簸的情况,这可能需要非常长的时间.

对此的一个例外是聚簇索引,其中页面上的值实际上按值排序.在这种情况下,使用索引的查询将快50%,因为只需要读取页面.这在"归档"表中尤其有效,在该表中,您有经常搜索的活动记录.此标志可能出现在记录的10%,1%或0.1%上,并且聚簇索引可以显着提高速度.

在大型表上运行返回一半记录的查询是很少见的.很可能,性别与其他列相结合将是包含在索引中的良好候选者.