在关系数据库中，索引是一种独自的、物理的对数据库表中一列或多列的值进行排序的一种存储构造，它是某个表中一列或若干列值的汇合和响应的指向表中物理标识这些值的数据页的逻辑指针清单。索引的作用相当于图书的名目，可以依据名目中的页码迅速寻.....

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 ='陈哈哈' and age = 26;
1 

??因为附加索引中只要name 和 age，因而命中索引后，数据库还必需回去汇集索引中查寻其他数据，这就是回表，这也是你背的那条：少用select * 的缘由。

2、索引遮盖

联合回表会更好了解，比方上述name_age_index索引，有查询

select name， age from table where name ='陈哈哈' 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 = '1';

select * from table where b ='1' and c ='2';
123 

下列三种状况却会走索引:

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';
12345 

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

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

??别的还有一个特别状况注明下，下面这品种型的也只会有 a与b 走索引，c不会走。

select * from table where a = '1' and b > '2'  and c='3';
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 '陈%' 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索引的细致内容，更多请关注 百分百源码网 其它相干文章！