什么是数据库索引，索引有什么做用

数据库索引是为了增长查询速度而对表字段附加的一种标识。见过不少人机械的理解索引的概念，认为增长索引只有好处没有坏处。这里想把以前的索引学习笔记总结一下：

    首先明白为何索引会增长速度，DB在执行一条Sql语句的时候，默认的方式是根据搜索条件进行全表扫描，遇到匹配条件的就加入搜索结果集合。若是咱们对某一字段增长索引，查询时就会先去索引列表中一次定位到特定值的行数，大大减小遍历匹配的行数，因此能明显增长查询的速度。那么在任什么时候候都应该加索引么？这里有几个反例：一、若是每次都须要取到全部表记录，不管如何都必须进行全表扫描了，那么是否加索引也没有意义了。二、对非惟一的字段，例如“性别”这种大量重复值的字段，增长索引也没有什么意义。三、对于记录比较少的表，增长索引不会带来速度的优化反而浪费了存储空间，由于索引是须要存储空间的，并且有个致命缺点是对于update/insert/delete的每次执行，字段的索引都必须从新计算更新。

    那么在何时适合加上索引呢？咱们看一个Mysql手册中举的例子，这里有一条sql语句：

    SELECT c.companyID, c.companyName FROM Companies c, User u WHERE c.companyID = u.fk_companyID AND c.numEmployees >= 0 AND c.companyName LIKE '%i%' AND u.groupID IN (SELECT g.groupID FROM Groups g WHERE g.groupLabel = 'Executive')

    这条语句涉及3个表的联接，而且包括了许多搜索条件好比大小比较，Like匹配等。在没有索引的状况下Mysql须要执行的扫描行数是77721876行。而咱们经过在companyID和groupLabel两个字段上加上索引以后，扫描的行数只须要134行。在Mysql中能够经过Explain Select来查看扫描次数。能够看出来在这种联表和复杂搜索条件的状况下，索引带来的性能提高远比它所占据的磁盘空间要重要得多。

    那么索引是如何实现的呢？大多数DB厂商实现索引都是基于一种数据结构——B树。由于B树的特色就是适合在磁盘等直接存储设备上组织动态查找表。B树的定义是这样的：一棵m(m>=3)阶的B树是知足下列条件的m叉树：

    一、每一个结点包括以下做用域(j, p0, k1, p1, k2, p2, ... ki, pi) 其中j是关键字个数，p是孩子指针

    二、全部叶子结点在同一层上，层数等于树高h

    三、每一个非根结点包含的关键字个数知足[m/2-1]<=j<=m-1

    四、若树非空，则根至少有1个关键字，若根非叶子，则至少有2棵子树，至多有m棵子树

    看一个B树的例子，针对26个英文字母的B树能够这样构造：

    能够看到在这棵B树搜索英文字母复杂度只为o(m)，在数据量比较大的状况下，这样的结构能够大大增长查询速度。然而有另一种数据结构查询的虚度比B树更快——散列表。Hash表的定义是这样的：设全部可能出现的关键字集合为u，实际发生存储的关键字记为k，而|k|比|u|小不少。散列方法是经过散列函数h将u映射到表T[0,m-1]的下标上，这样u中的关键字为变量，以h为函数运算结果即为相应结点的存储地址。从而达到能够在o(1)的时间内完成查找。          然而散列表有一个缺陷，那就是散列冲突，即两个关键字经过散列函数计算出了相同的结果。设m和n分别表示散列表的长度和填满的结点数，n/m为散列表的填装因子，因子越大，表示散列冲突的机会越大。          由于有这样的缺陷，因此数据库不会使用散列表来作为索引的默认实现，Mysql宣称会根据执行查询格式尝试将基于磁盘的B树索引转变为和合适的散列索引以追求进一步提升搜索速度。我想其它数据库厂商也会有相似的策略，毕竟在数据库战场上，搜索速度和管理安全同样是很是重要的竞争点。