索引策略

在《高性能的MYSQL》中对高性能的索引策略进行了描述，现在归纳一下。

一，独立的列。
指索引列不能是表达式的一部分，也不能是函数的参数。
Select actorI_id from actor where actor_id+1=5//不能使用索引。
策略：始终将索引列单独放在比较符号的一侧。

二，前缀索引。
前缀索引是指将字段列的前部分作为索引存储，它是一种平衡索引大小和效率的方法。
通过比较前缀的长度和索引的选择性，来确定前缀的长度（选择性是指匹配的时候剩余部分和全部的比值，条件多虑掉的越多选择性越高）。这样等到前缀长度的合适值，建立前缀索引。

三，多列索引
误区：不是为每个列创建单独的索引，或者按照错误的顺序创建多列索引。
为每个列单独的建立索引在mysql老的版本中甚至会采用全表扫描，新的版本中虽然会对索引进行合并，但是很多时候不是最优的选择。在合并运算的时候会消耗更多的cpu和内存的资源。
而使用多列索引，多列索引的顺序问题也是一个难题。在不需要考虑排序和分组的时候，我们将选择性最高的排在前列。

四，聚蔟索引
聚蔟索引是一种数据存储的方式而不是一种单独的索引类型。聚蔟表示相邻的键值和数据行紧凑的存储在一起。
在mysql的InnoDB中是支持聚蔟索引，他的存储方式是在B-Tree索引的叶子节点中直接存储数据行。
在InnoDB中，默认会将表的主键当做聚蔟索引，如果没有定义主键，则会选择一个唯一的非空索引代替，但是如果不存在这样的列，InnoDB会隐式的创建一个键当做聚蔟索引。
聚蔟索引的优点：
1，相关的数据保存在一起，IO更为集中。
2，索引和数据记录保存在同一个B-Tree中，所以比非聚蔟索引要快。
缺点：
1，插入的速度严重依赖于插入的速度，按照主键的顺序最快。
2，聚蔟索引对于行比较稀疏的，聚蔟索引可能会导致全表扫描变慢。

Mysql的MyISSAM不支持聚蔟索引，所以数据的顺序是按照插入的顺序。主键索引和其他索引没有分别。
InnoDB中聚蔟索引的叶子节点直接存放数据，其他非聚蔟索引的叶子节点指针指向主键，所以需要查询2次。
对高并发工作负载中，按照主键顺序插入可能造成明显的争用，主键上称为热点，所有的插入都集中在这里。
五，覆盖索引 如果一个索引包含所有需要查询的字段的值，那么就称之为覆盖索引。
覆盖索引是分厂有用的工具，能够极大的提高性能。索引的条目通常是远小于数据行大小的，所以如果只是需要读取索引，那么在Mysql就会极大的减少数据的访问量。
六 使用索引来做排序。
当索引的列顺序和order by字句的顺序完全一致的时候Mysql可以使用同一个索引及满足查找查找有满足排序。

七压缩索引（前缀压缩）
压缩索引主要是使用前缀压缩来减少索引的大小。从而让更多的索引可以放入内存中。
MyISAM压缩索引的方式是，完全保存索引块中的第一个值，然后将其他值和第一个值进行比较得到相同的前缀的字节数和剩余的不同的后缀。比如第一个值是abcd123，第二个值是abcdef4；那么第二个值的存储类似4,ef4;这样的形式。
压缩块使用了更少的空间，但是每个值的压缩前缀都依赖前面的值，所以压缩索引在查询的时候不能够使用二分法查找只能够从头开始查找。所以压缩索引其实是在cpu内存资源和磁盘之间做权衡。