Mysql索引查找原理及调优

1.1 常见查找方法举例

1.1.1 顺序查找（linear search ）

1. 最基本的查询算法当然是顺序查找（linear search），也就是对比每个元素的方法，不过这种算法在数据量很大时效率是极低的。

2. 数据结构：有序或无序队列

3. 复杂度：O(n)

1.1.2 二分查找

1. 从数组的中间元素开始，如果中间元素正好是要查找的元素，则搜素过程结束；

2. 如果某一特定元素大于或者小于中间元素，则在数组大于或小于中间元素的那一半中查找，而且根开始一样从中间元素开始比较。

3. 如果在某一步骤数组为空，则代表找不到。

4. 数据结构：有序数组

5. 复杂度：O(logn)

1.1.3 二叉排序树查找

• 二叉排序树的特点是：

  • 若它的左子树不空，则左子树上所有结点的值均小于它的根结点的值；

  • 若它的右子树不空，则右子树上所有结点的值均大于它的根结点的值；

  • 它的左、右子树也分别为二叉排序树。

• 搜索的原理：

  若b是空树，则搜索失败，否则：

  若x等于b的根节点的数据域之值，则查找成功；否则：

  若x小于b的根节点的数据域之值，则搜索左子树；否则：查找右子树。

  数据结构：二叉排序树

  时间复杂度： O(log2N)

1.1.4 哈希散列法(哈希表)

1. 其原理是首先根据key值和哈希函数创建一个哈希表（散列表），燃耗根据键值，通过散列函数，定位数据元素位置。

2. 数据结构：哈希表

3. 时间复杂度：几乎是O(1)，取决于产生冲突的多少。

1.2 MyISAM实现索引

1.2.1 MyISAM实现索引 介绍

1. MyISAM引擎使用B+Tree作为索引结构，叶节点的data域存放的是数据记录的地址。

2. MyISAM中索引检索的算法为首先按照B+Tree搜索算法搜索索引。

3. 如果指定的Key存在，则取出其data域的值，然后以data域的值为地址，读取相应数据记录。

4. MyISAM的索引方式也叫做“非聚集”的，之所以这么称呼是为了与InnoDB的聚集索引区分。

1.2.2 MyISAM索引的原理图

1. 这里设表一共有三列，假设我们以Col1为主键，则上图是一个MyISAM表的主索引（Primary key）示意。

2. 可以看出MyISAM的索引文件仅仅保存数据记录的地址。
   

1.3 InnoDB索引实现

注：虽然InnoDB也使用B+Tree作为索引结构，但具体实现方式却与MyISAM截然不同。

• 区别1：InnoDB的数据文件本身就是索引文件

  • 从上文知道，MyISAM索引文件和数据文件是分离的，索引文件仅保存数据记录的地址。

  • 而在InnoDB中，表数据文件本身就是按B+Tree组织的一个索引结构，这棵树的叶节点data域保存了完整的数据记录。

  • 这个索引的key是数据表的主键，因此InnoDB表数据文件本身就是主索引。
    
    说明：

    可以看到叶节点包含了完整的数据记录，这种索引叫做聚集索引。

    因为InnoDB的数据文件本身要按主键聚集，所以InnoDB要求表必须有主键（MyISAM可以没有）

    如果没有显式指定，则MySQL系统会自动选择一个可以唯一标识数据记录的列作为主键

    如果不存在这种列，则MySQL自动为InnoDB表生成一个隐含字段作为主键，这个字段长度为6个字节，类型为长整形。

• 区别2：InnoDB的辅助索引data域存储相应记录主键的值而不是地址

1. 换句话说，InnoDB的所有辅助索引都引用主键作为data域。

2. 这里以英文字符的ASCII码作为比较准则。

3. 聚集索引这种实现方式使得按主键的搜索十分高效，但是辅助索引搜索需要检索两遍索引

4. 首先检索辅助索引获得主键，然后用主键到主索引中检索获得记录。

• 为什么不建议使用过长的字段作为主键

1. 例如知道了InnoDB的索引实现后，就很容易明白为什么不建议使用过长的字段作为主键

2. 因为所有辅助索引都引用主索引，过长的主索引会令辅助索引变得过大。

3. 再例如，用非单调的字段作为主键在InnoDB中不是个好主意，因为InnoDB数据文件本身是一颗B+Tree，

4. 非单调的主键会造成在插入新记录时数据文件为了维持B+Tree的特性而频繁的分裂调整，十分低效，而使用自增字段作为主键则是一个很好的选择。

1.4 索引使用策略

1.4.1 联合索引（复合索引）

1. 联合索引其实很简单，相对于一般索引只有一个字段，联合索引可以为多个字段创建一个索引

2. 它的原理也很简单，比如，我们在（a,b,c）字段上创建一个联合索引，则索引记录会首先按照A字段排序

3. ，然后再按照B字段排序然后再是C字段

4. 其实联合索引的查找就跟查字典是一样的，先根据第一个字母查，然后再根据第二个字母查

5. 或者只根据第一个字母查，但是不能跳过第一个字母从第二个字母开始查。这就是所谓的最左前缀原理。

6. 联合索引的特点就是：
   1）第一个字段一定是有序的

   2）当第一个字段值相等的时候，第二个字段又是有序的，比如下表中当A=2时所有B的值是有序排列的，依次类推，当同一个B值得所有C字段是有序排列的
   　　　　　　　

• 最左前缀查询举例

'''最左前缀原理'''

#### 1、以下的查询方式都可以用到索引
'''
select * from table where a=1；
select * from table where a=1 and b=2；
select * from table where a=1 and b=2 and c=3；
上面三个查询按照 （a ）, （a，b ）,（a，b，c ）的顺序都可以利用到索引，这就是最左前缀匹配。
'''

#### 2、如果查询语句是：
'''
select * from table where a=1 and c=3； 那么只会用到索引a。
'''

#### 3、这样不会用的索引
'''
select * from table where b=2 and c=3； 因为没有用到最左前缀a，所以这个查询是用户到索引的。
'''

1.4.2 前缀索引

1. 前缀索引就是用列的前缀代替整个列作为索引key，当前缀长度合适时，可以做到既使得前缀索引的选择性接近全列索引

2. 同时因为索引key变短而减少了索引文件的大小和维护开销。

3. 一般来说以下情况可以使用前缀索引：
   1）字符串列(varchar,char,text等)，需要进行全字段匹配或者前匹配。也就是=‘xxx’ 或者 like ‘xxx%’

   2）字符串本身可能比较长，而且前几个字符就开始不相同。（比如：收件地址、外国人的姓名）

4. MySQL 前缀索引能有效减小索引文件的大小，提高索引的速度。

5. 但是前缀索引也有它的坏处：MySQL 不能在 ORDER BY 或 GROUP BY 中使用前缀索引，也不能把它们用作覆盖索引(Covering Index)。

1.4.3 索引优化策略

说明：MySQL的优化主要分为结构优化（Scheme optimization）和查询优化（Query optimization）。

# 1、最左前缀匹配原则，上面讲到了
# 2、主键外键一定要建索引
# 3、对 where,on,group by,order by 中出现的列使用索引
# 4、尽量选择区分度高的列作为索引,区分度的公式是count(distinct col)/count(*)，表示字段不重复的比例，
# 5、为较长的字符串使用前缀索引

'''
# 6、不要过多创建索引, 权衡索引个数与DML之间关系，DML也就是插入、删除数据操作。
    这里需要权衡一个问题，建立索引的目的是为了提高查询效率的，但建立的索引过多，
    会影响插入、删除数据的速度，因为我们修改的表数据，索引也需要进行调整重建
'''

'''
# 7、对于like查询，”%”不要放在前面。
    SELECT * FROMhoudunwangWHEREunameLIKE'后盾%' -- 走索引 
    SELECT * FROMhoudunwangWHEREunameLIKE "%后盾%" -- 不走索引
'''

'''
# 8、查询where条件数据类型不匹配也无法使用索引 
    字符串与数字比较不使用索引; 
    CREATE TABLEa(achar(10)); 
    EXPLAIN SELECT * FROMaWHEREa="1" – 走索引 
    EXPLAIN SELECT * FROM a WHERE a=1 – 不走索引 
    正则表达式不使用索引,这应该很好理解,所以为什么在SQL中很难看到regexp关键字的原因
'''

建索引原则：

1.最左前缀匹配原则，非常重要的原则，mysql会一直向右匹配直到遇到范围查询(>、<、between、like)就停止匹配，
比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引，d是用不到索引的，
如果建立(a,b,d,c)的索引则都可以用到，a,b,d的顺序可以任意调整。

2.=和in可以乱序，比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序，
mysql的查询优化器会帮你优化成索引可以识别的形式

3.尽量选择区分度高的列作为索引,区分度的公式是count(distinct col)/count(*)，表示字段不重复的比例，
比例越大我们扫描的记录数越少，唯一键的区分度是1，而一些状态、性别字段可能在大数据面前区分度就是0，
那可能有人会问，这个比例有什么经验值吗？使用场景不同，这个值也很难确定，
一般需要join的字段我们都要求是0.1以上，即平均1条扫描10条记录

4.索引列不能参与计算，保持列“干净”，比如from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，
原因很简单，b+树中存的都是数据表中的字段值，但进行检索时，需要把所有元素都应用函数才能比较，
显然成本太大。所以语句应该写成create_time = unix_timestamp(’2014-05-29’);

5.尽量的扩展索引，不要新建索引。比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改原来的索引即可