MySQL索引优化

个人想法：所谓的索引优化无非就是引擎、索引类型的选择，索引顺序的排列，索引排序的理解！

1)我会首先考虑采用哪种存储引擎：INNODB 、MYISAM 、ARCHIVE 、MEMORY，因为索引是在引擎层实现的。

2)接下来考虑应该采用哪种索引：B-TREE 和HASH索引，B-TREE更适合范围查询，HASH更适合精确查询。

3)利用好EXPLAIN 工具分析查询语句:EXPLAIN select * from 表名 ；

   注意rows项和以及type项，分别表示了查询了多少行，以及查询表的方式。

4)创建索引时列的顺序,经验选择法则不考虑排序与分组时推荐将选择性高的前缀放在索引列顺序的前面

计算完整列的选择性：不重复索引列的前缀和数据表记录总数的比值。推荐—> 【0.0310】

示例1：select count(distinct LEFT(列名,3))/count(*) as col_3,count(distinct LEFT(列名,4))/count(*) as col_4,

                     count(distinct LEFT(列名,5)/count(*))as col_5,count(distinct LEFT(列名,6))/count(*)as col_6

         FROM 表名；

解析：通过对不同前缀长度计算来记录选择性，推荐值接近0.0310的前缀长度作为前缀索引；

5)聚簇索引   ：存储数据的方式而非一种单独的索引类型

                推荐主键自增AUTO_INCREMENT，它确保了insert数据存储的连续性，主键页被顺序的记录填满；

                如果未使用自增AUTO_increment，在进行数据insert操作时会造成随机I/O，innodb引擎不得不频繁的做页分裂操作以插入数据，造成了大量的碎片；

6)覆盖索引  ：一个索引包含所查询字段的值，覆盖索引必须存储索引咧的值，所以只有B-TREE索引符合，并且需要考虑引擎momery不支持覆盖索引；

7)索引排序   ： 设（col1，col2，col3，col4，col5）             索引列顺序是（col1,col3,col5）

壹）where col1=‘常量’ order by col3，col5   \G    虽然order by 不满足索引醉左前缀，但是col1是常量；组合成功

贰）where col1=‘常量’ order by col3 desc  \G     两列组合排序；

叁）where col1>‘常量’ order by col3，col5   \G   依然成立因为它符合索引的顺序