标签：高度 前缀 字段 需要 相互 sam 磁盘 bsp char
InnoDB和MyISAM使用了b+树和b树作为索引组织的方式。
在这些结构中，索引的深度是个关键因素。当查找被索引了的行时，查找会在索引上从根到叶子执行。
假设这些索引不在内存中，索引的深度就代表了查找的(IO)代价。当然，我们希望大部分的查找都在内存中执行(被cache在内存中)。尽管如此，索引的深度仍然是一个重要因素。索引深度越深，查找越慢。
那么什么影响了索引的深度？
虽然有相当多的结构问题，但可以归结为两个重要的点：
1.表的行数:
行数越多，索引的行数越多，导致索引的深度越深
2.索引的大小:
对于相同整形的和字符串类型，如果树的高度相同，肯定整形的要放的记录数多些
当然，这两个也影响索引的大小，磁盘空间必须大，在这里我们只关注索引的深度。
下面就着重来看第二个因素。如果可以的话，尽量使用“短”索引（在短列上建索引）。这也就是为什么，如果遇到varchar做索引的时候采用前缀索引（varchar(column(n))）;这也就是为什么能用int类型做索引的时候就不用bigint（你的业务场景不需要bigint）。
被索引列（包括单列索引和组合索引）越大，索引节点上放的值越少。在一个节点上的越少，节点分裂的次数越多，需要更多的索引节点。节点里的值越少，索引树越窄。索引树越窄，索引就需要更多的索引节点，然后索引树的深度越深。
从上面我们可以得出，大的数据类型类型，导致索引树越深，进而导致更多的IO查找。
InnoDB
所有使用InnoDB类型的表的primary key都是聚簇索引。访问表的数据都需要通过primary key树。
对于InnoDB引擎来说，二级索引（除了primary key之外的索引）不直接引向表数据。二级索引上的叶子节点的数据，就是primary key的值。
所以如果我们从InnoDB表里通过二级索引查找数据的话，我们要通过二级索引找出primary key的id，然后再通过遍历primary key的树找出符合id值的值。
这就意味着，如果我们用二级索引的话，会有两层树的查找， 其中一个总是遍历primary key。
在InnoDB中如果用了长字段类型，不仅仅意味着primary key的树膨胀了（深了），其他引入长字段类型的索引也膨胀了。
MyISAM
由于MyISAM用的不是聚簇树，primary key和普通的唯一索引是一样的。索引的创建方式都是一样的，索引查找就是简单的一系列单个索引查找。所以两个索引不相互影响，不过需要注意的是他们共用一个key cache。
标签：高度 前缀 字段 需要 相互 sam 磁盘 bsp char
原文地址：http://www.cnblogs.com/sunss/p/6601851.html
