mysql视频教程栏目介绍真实的索引.

从图中也可以看到，B+树与B树的不同在于：

1. 所有关键字存储在叶子节点，非叶子节点不存储真正的data，从而可以快速定位到叶子结点。
2. 为所有叶子节点增加了一个链指针，意味着所有的值都是按顺序存储的，并且每一个叶子页到根的距离相同，很适合查找范围数据。

**因此，B+Tree可以对<，<=，=，>，>=，BETWEEN，IN，以及不以通配符开始的LIKE使用索引。**

B+树的优点：

比较的次数均衡，减少了I/O次数，提高了查找速度，查找也更稳定。

• B+树的磁盘读写代价更低
• B+树的查询效率更加稳定

  要知道的是，你每次创建表，系统会为你自动创建一个基于ID的聚集索引（上述B+树），存储全部数据；你每次增加索引，数据库就会为你创建一个附加索引（上述B+树），索引选取的字段个数就是每个节点存储数据索引的个数，注意该索引并不存储全部数据。

四、为什么MySQL索引选择了 B+树 而不是 B树？

1. B+树更适合外部存储(一般指磁盘存储),由于内节点(非叶子节点)不存储data，所以一个节点可以存储更多的内节点，每个节点能索引的范围更大更精确。也就是说使用B+树单次磁盘I/O的信息量相比较B树更大，I/O效率更高。
2. mysql是关系型数据库，经常会按照区间来访问某个索引列，B+树的叶子节点间按顺序建立了链指针，加强了区间访问性，所以B+树对索引列上的区间范围查询很友好。而B树每个节点的key和data在一起，无法进行区间查找。

五、程序员，你应该知道的索引知识点

1、回表查询

比如你创建了name， age索引 name_age_index，查询数据时使用了

select * from table where name =&＃39;陈哈哈&＃39; and age = 26;
1 

  由于附加索引中只有name 和 age，因此命中索引后，数据库还必须回去聚集索引中查找其他数据，这就是回表，这也是你背的那条：少用select * 的原因。

2、索引覆盖

结合回表会更好理解，比如上述name_age_index索引，有查询

select name， age from table where name =&＃39;陈哈哈&＃39; and age = 26;
1 

  此时select的字段name，age在索引name_age_index中都能获取到，所以不需要回表，满足索引覆盖，直接返回索引中的数据，效率高。是DBA同学优化时的首选优化方式。

3、最左前缀原则

  B+树的节点存储索引顺序是从左向右存储，在匹配的时候自然也要满足从左向右匹配；通常我们在建立联合索引的时候，也就是对多个字段建立索引，相信建立过索引的同学们会发现，无论是Oracle还是 MySQL 都会让我们选择索引的顺序，比如我们想在a,b,c三个字段上建立一个联合索引，我们可以选择自己想要的优先级，a、b、c,或者是b、a、c 或者是c、a、b等顺序。 为什么数据库会让我们选择字段的顺序呢？不都是三个字段的联合索引么？这里就引出了数据库索引的最左前缀原理。

  在我们开发中经常会遇到明明这个字段建了联合索引，但是SQL查询该字段时却不会使用索引的问题。比如索引abc_index:(a,b,c)是a,b,c三个字段的联合索引，下列sql执行时都无法命中索引abc_index的；

select * from table where c = &＃39;1&＃39;;

select * from table where b =&＃39;1&＃39; and c =&＃39;2&＃39;;
123 

以下三种情况却会走索引:

select * from table where a = &＃39;1&＃39;;

select * from table where a = &＃39;1&＃39; and b = &＃39;2&＃39;;

select * from table where a = &＃39;1&＃39; and b = &＃39;2&＃39;  and c=&＃39;3&＃39;;
12345 

从上面两个例子大家是否阔以看出点眉目？

  是的，索引abc_index:(a,b,c)，只会在(a)、(a,b)、(a,b,c) 三种类型的查询中使用。其实这里说的有一点歧义，其实(a,c)也会走，但是只走a字段索引，不会走c字段。

  另外还有一个特殊情况说明下，下面这种类型的也只会有 a与b 走索引，c不会走。

select * from table where a = &＃39;1&＃39; and b > &＃39;2&＃39;  and c=&＃39;3&＃39;;
1 

  像上面这种类型的sql语句，在a、b走完索引后，c已经是无序了，所以c就没法走索引，优化器会认为还不如全表扫描c字段来的快。

**最左前缀：顾名思义，就是最左优先，上例中我们创建了a_b_c多列索引,相当于创建了(a)单列索引，(a,b)组合索引以及(a,b,c)组合索引。**

  因此，在创建多列索引时，要根据业务需求，where子句中使用最频繁的一列放在最左边。

4、索引下推优化

还是索引name_age_index，有如下sql

select * from table where name like &＃39;陈%&＃39; and age > 26；
1 

该语句有两种执行可能：

• 命中name_age_index联合索引，查询所有满足name以"陈"开头的数据， 然后回表查询所有满足的行。
• 命中name_age_index联合索引，查询所有满足name以"陈"开头的数据，然后顺便筛出age>20的索引，再回表查询全行数据。

显然第2种方式回表查询的行数较少，I/O次数也会减少，这就是索引下推。所以不是所有like都不会命中索引。

六、使用索引时的注意事项

1、索引不会包含有null值的列

  只要列中包含有null值都将不会被包含在索引中，复合索引中只要有一列含有null值，那么这一列对于此复合索引就是无效的。所以我们在数据库设计时建议不要让字段的默认值为null。

2、使用短索引

  对串列进行索引，如果可能应该指定一个前缀长度。例如，如果有一个char(255)的列，如果在前10个或20个字符内，多数值是惟一的，那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。

3、索引列排序

  查询只使用一个索引，因此如果where子句中已经使用了索引的话，那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序操作；尽量不要包含多个列的排序，如果需要最好给这些列创建复合索引。

4、like语句操作

  一般情况下不推荐使用like操作，如果非使用不可，如何使用也是一个问题。like “%陈%” 不会使用索引而like “陈%”可以使用索引。

5、不要在列上进行运算

这将导致索引失效而进行全表扫描，例如

SELECT * FROM table_name WHERE YEAR(column_name)<2017;
1 

6、不使用not in和<>操作

这不属于支持的范围查询条件，不会使用索引。

我的体会

  曾经，我一度以为我很懂MySQL。

  刚入职那年，我还是个孩子，记得第一个需求是做个统计接口，查询近两小时每隔5分钟为一时间段的网站访问量，JSONArray中一共返回24个值，当时菜啊，写了个接口循环二十四遍，发送24条SQL去查（捂脸），由于那个接口，被技术经理嘲讽~~表示他写的SQL比我吃的米都多。虽然我们山东人基本不吃米饭，但我还是羞愧不已。。
然后经理通过调用一个dateTime函数分组查询处理一下，就ok了，效率是我的几十倍吧。从那时起，我就定下目标，深入MySQL学习，万一日后有机会嘲讽回去？

  筒子们，MySQL路漫漫，其修远兮。永远不要眼高手低，一起加油，希望本文能对你有所帮助。

以上就是哭..我以为我很懂MySQL索引的详细内容，更多请关注 第一PHP社区 其它相关文章！