MySQL 之 索引进阶

一、正确使用索引

(1)、一 索引未命中

​ 并非说建立了索引就必定会加快查询速度，若想利用索引达到预想的提升查询速度的效果，在添加索引时，必须注意如下问题：

<1>、范围问题

​ 或者说条件不明确，条件中出现这些符号或关键字：>、>=、<、<=、!= 、between...and...、like

大于号、小于号

不等于 号

between ...and...

like

<2>、 尽可能选择区分度高的列做为索引

​ 区分度的公式是 count( distinct col ) / count(*)，表示字段不重复的比例，比例越大咱们扫描的记录数越少，惟一键的区分度是1，而一些状态、性别字段可能在大数据面前区分度就是0，这个比例有使用场景不一样，这个值也很难肯定，通常须要join的字段咱们都要求是0.1以上，即平均1条扫描10条记录

# 分析缘由
  咱们编写存储过程为表s1批量添加记录，name字段的值均为egon，也就是说name这个字段的区分度很低（gender字段也是同样的，咱们稍后再搭理它）

回忆b+树的结构，查询的速度与树的高度成反比，要想将树的高低控制的很低，须要保证：在某一层内数据项均是按照从左到右，从小到大的顺序依次排开，即左1<左2<左3<...

而对于区分度低的字段，没法找到大小关系，由于值都是相等的，毫无疑问，还想要用b+树存放这些等值的数据，只能增长树的高度，字段的区分度越低，则树的高度越高。极端的状况，索引字段的值都同样，那么b+树几乎成了一根棍。本例中就是这种极端的状况，name字段全部的值均为'egon'

# 如今咱们得出一个结论：为区分度低的字段创建索引，索引树的高度会很高，然而这具体会带来什么影响呢？？？

# 1：若是条件是name='xxxx',那么确定是能够第一时间判断出'xxxx'是不在索引树中的（由于树中全部的值均为'egon’），因此查询速度很快
# 2：若是条件正好是name='egon',查询时，咱们永远没法从树的某个位置获得一个明确的范围，只能往下找，往下找，往下找。。。这与全表扫描的IO次数没有多大区别，因此速度很慢

<3>、索引列不能在条件中参与计算

​ 保持列“干净”，好比from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，缘由很简单，b+树中存的都是数据表中的字段值，但进行检索时，须要把全部元素都应用函数才能比较，显然成本太大。因此语句应该写成create_time = unix_timestamp(’2014-05-29’)

<4>、and / or

# 一、and与or的逻辑
    条件1 and 条件2:全部条件都成立才算成立，但凡要有一个条件不成立则最终结果不成立
    条件1 or 条件2:只要有一个条件成立则最终结果就成立

# 二、and的工做原理
    条件：
        a = 10 and b = 'xxx' and c > 3 and d =4
    索引：
        制做联合索引(d,a,b,c)
    工做原理:
        对于连续多个and：mysql会按照联合索引，从左到右的顺序找一个区分度高的索引字段(这样即可以快速锁定很小的范围)，加速查询，即按照d—>a->b->c的顺序

# 三、or的工做原理
    条件：
        a = 10 or b = 'xxx' or c > 3 or d =4
    索引：
        制做联合索引(d,a,b,c)
    工做原理:
        对于连续多个or：mysql会按照条件的顺序，从左到右依次判断，即a->b->c->d

在左边条件成立可是索引字段的区分度低的状况下（name与gender均属于这种状况），会依次往右找到一个区分度高的索引字段，加速查询

通过分析，在条件为name='egon' and gender='male' and id>333 and email='xxx'的状况下，咱们彻底不必为前三个条件的字段加索引，由于只能用上email字段的索引，前三个字段的索引反而会下降咱们的查询效率

<5>、最左前缀匹配原则

​ 很是重要的原则，对于组合索引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的顺序能够任意调整。

<6>、其余状况

- 使用函数
    select * from tb1 where reverse(email) = 'egon';
            
- 类型不一致
    若是列是字符串类型，传入条件是必须用引号引发来
    select * from tb1 where email = 999;
    
# 排序条件为索引，则select字段必须也是索引字段，不然没法命中
- order by
    select name from s1 order by email desc;
    当根据索引排序时候，select查询的字段若是不是索引，则速度仍然很慢
    select email from s1 order by email desc;
    特别的：若是对主键排序，则仍是速度很快：
        select * from tb1 order by nid desc;
 
- 组合索引最左前缀
    若是组合索引为：(name,email)
    name and email       -- 命中索引
    name                 -- 命中索引
    email                -- 未命中索引

- count(1)或count(列)代替count(*)在mysql中没有差异了

- create index xxxx  on tb(title(19)) # text类型，必须制定长度

(2)、其余注意事项

- 避免使用 select *
- 使用 count(*)
- 建立表时尽可能使用 char 代替 varchar
- 表的字段顺序固定长度的字段优先
- 组合索引代替多个单列索引（因为mysql中每次只能使用一个索引，因此常用多个条件查询时更适合使用组合索引）
- 尽可能使用短索引
- 使用链接（JOIN）来代替子查询(Sub-Queries)
- 连表时注意条件类型需一致
- 索引散列值（重复少）不适合建索引，例：性别不适合

二、 联合索引与覆盖索引

(1)、联合索引

​ 联合索引是指对表上的多个列合起来作一个索引。联合索引的建立方法与单个索引的建立方法同样，不一样之处仅在于有多个索引列，以下

mysql> create table t(
    -> a int,
    -> b int,
    -> primary key(a),
    -> key idx_a_b(a,b)
    -> );
Query OK, 0 rows affected (0.11 sec)

​ 从本质上来讲，联合索引就是一棵B+树，不一样的是联合索引的键值的数量不是1，而是>=2。接着来讨论两个整型列组成的联合索引，假定两个键值得名称分别为a、b如图

​ 能够看到这与以前看到的单个键的B+树并无什么不一样，键值都是排序的，经过叶子结点能够逻辑上顺序地读出全部数据，就上面的例子来讲，即（1,1），（1,2），（2,1），（2,4），（3,1），（3,2），数据按（a,b）的顺序进行了存放。

​ 所以，对于查询 select * from table where a=xxx and b=xxx, 显然是可使用(a,b) 这个联合索引的，对于单个列a的查询 select * from table where a=xxx,也是可使用（a,b）这个索引的。

​ 但对于b列的查询 select * from table where b=xxx,则不可使用（a,b） 索引，其实不难发现缘由，叶子节点上b的值为一、二、一、四、一、2显然不是排序的，所以对于b列的查询使用不到(a,b) 索引。

​ 联合索引的第二个好处是在第一个键相同的状况下，已经对第二个键进行了排序处理。

(2)、覆盖索引

​ InnoDB存储引擎支持覆盖索引（covering index，或称索引覆盖），即从辅助索引中就能够获得查询记录，而不须要查询汇集索引中的记录。

​ 使用覆盖索引的一个好处是：辅助索引不包含整行记录的全部信息，故其大小要远小于汇集索引，所以能够减小大量的IO操做。

---

注意：覆盖索引技术最先是在InnoDB Plugin中完成并实现，这意味着对于InnoDB版本小于1.0的，或者MySQL数据库版本为5.0如下的，InnoDB存储引擎不支持覆盖索引特性。

---

​ 对于InnoDB存储引擎的辅助索引而言，因为其包含了主键信息，所以其叶子节点存放的数据为（primary key1，priamey key2，...,key1，key2，...）。

​ 覆盖索引的另一个好处是对某些统计问题而言的。基于上一小结建立的表buy_log,查询计划以下

mysql> explain select count(*) from buy_log;
+--+-----------+-------+-----+-------------+------+-------+----+----+-----------+
|id|select_type|table  | type|possible_keys|key   |key_len|ref |rows|Extra      |
+--+-----------+-------+-----+-------------+------+-------+----+----+-----------+
| 1| SIMPLE    |buy_log|index| NULL        |userid| 4     |NULL|  7 |Using index|
+--+-----------+-------+-----+-------------+------+-------+----+----+-----------+
1 row in set (0.00 sec)

# Using index表明覆盖索引

​ innodb存储引擎并不会选择经过查询汇集索引来进行统计。因为buy_log表有辅助索引，而辅助索引远小于汇集索引，选择辅助索引能够减小IO操做，故优化器的选择如上key为userid辅助索引

​ 对于（a,b）形式的联合索引，通常是不能够选择b中所谓的查询条件。但若是是统计操做，而且是覆盖索引，则优化器仍是会选择使用该索引，以下

# 联合索引userid_2（userid,buy_date）,通常状况，按照buy_date是没法使用该索引的，但特殊状况下：查询语句是统计操做，且是覆盖索引，则按照buy_date当作查询条件时，也可使用该联合索引
mysql> explain select count(*) from buy_log where buy_date >= '2011-01-01' and buy_date < '2011-02-01';
+--+-----------+-------+-----+-------------+--------+-------+----+----+------------------------+
|id|select_type| table |type |possible_keys| key    |key_len|ref |rows|Extra                   |
+--+-----------+-------+-----+-------------+--------+-------+----+----+------------------------+
| 1| SIMPLE    |buy_log|index| NULL        |userid_2| 8     |NULL|  7 |Using where; Using index|
+--+-----------+-------+-----+-------------+--------+-------+----+----+------------------------+
1 row in set (0.00 sec)

# 合并索引
mysql> explain select count(email) from index_t where   id = 1000000  or email='eva100000@oldboy';
+--+-----------+------+--------------+--------------------------------+---------------+--------+-----+----+-----------------------------------------+
| id | select_type| table  | type                | possible_keys                              | key                   | key_len | ref    |rows | Extra                                                           |
+--+-----------+------+--------------+--------------------------------+---------------+--------+-----+----+-----------------------------------------+
|  1 | SIMPLE      | index_t| index_merge | PRIMARY,email,ind_id,ind_email | PRIMARY,email | 4,51   |NULL|   2    |Using union(PRIMARY,email); Using where |
+--+-----------+------+--------------+--------------------------------+---------------+--------+-----+----+-----------------------------------------+
1 row in set (0.01 sec)