MySQL索引的设计原则

• 搜索的索引列，不一定是索要选择的列。换句话说，最适合索引的列是出现在WHERE子句中的列，或连接子句中指定的列，而不是出现在SELECT关键字后的选择列表中的列。

• 使用唯一索引。考虑某列中值得分布。索引的列的基数越大，索引的效果越好。例如，存放出生日期的列具有不同值，很容易区分各行。而用来记录性别的列，只含有“M”和“F”，则对此列进行索引没有多大用处，因为不管搜索哪个值，都会得出大约一半的行。

• 使用短索引。如果对字符串列进行索引，应该指定一个前缀长度。例如，有一个CHAE(200)列，如果在前10个或20个字符内，多数值是唯一的，那么就不要对整个列进行索引。对前10个或20个字符进行索引能够节省大量索引空间，也可能会使查询更快。较小的索引涉及的磁盘IO较少，较短的值比较起来更快。更为重要的是，对于较短的键值，索引高速缓存中的块能容纳能多的键值，因此，MySQL也可以在内存中容纳更多的值。这样就增加了找到行而不用读取索引中较多块的可能性。

• 不要过度索引。每个额外的索引都要占用额外的磁盘空间，并降低写操作的性能。修改表的内容时，索引必须进行更新，有时重构，因此，索引越多，所花的时间越长。

HASH索引

MEMORY存储引擎的表可以选择使用BTREE索引或者HASH索引，两种不同类型的索引各有其不同的使用范围。

Hash 索引结构的特殊性，其检索效率非常高，索引的检索可以一次定位，不像B-Tree 索引需要从根节点到枝节点，最后才能访问到页节点这样多次的IO访问，所以 Hash 索引的查询效率要远高于 B-Tree 索引。

• Hash 索引仅仅能满足"=","IN"和"<=>"查询，不能使用范围查询。

• Hash 索引无法被用来避免数据的排序操作。

• Hash 索引不能利用部分索引键查询。

• Hash 索引在任何时候都不能避免表扫描。

• Hash 索引遇到大量Hash值相等的情况后性能并不一定就会比B-Tree索引高。