目录
二、索引的实现原理（以B树为例，目前基本使用B+树，如非必要，不要深究，跳过）
三、索引的存储形式：B+Tree（如非必要，不要深究，跳过）
6）为什么MySQL使用B+Tree？（为什么B+Tree比B树更合适数据库索引）
一、什么是索引？（索引，是一种机制、数据结构）
1、索引的定义：查询机制
1）索引，是数据库表的字段上添加的，为了提高查询效率而存在的一种机制！
2）一张表可以的一个字段，可以添加一个索引，多个字段联合起来也可以添加索引（索引类型，下面会详细展开）。
3）索引相当于一本书的目录，是为了缩小扫描范围而存在的机制。
4）索引就是一种帮助数据库高效获取数据的数据结构。
举个例子：
对于一本字典来说，查找某个汉字有两种方式：
一是一页一页翻着找，直到找到为止，这种查找方式属于全字典扫描；
二是，先通过目录（索引）去定位一个大概的位置，然后直接定位到这个位置，做局域性扫描，这种查找方式属于通过索引检索，效率较高！
2、索引语句案例解读
例如以下的数据库表：
在该table中，存在id、name、job、salary4个字段，那么在上面的查询操作中：
select * from emp where name=’刘地’;这条SQL语句会去name字段上扫描，此时的name字段就相当于目录（索引）。因为查询的条件是name = ‘刘地’;
如果name字段上没有添加索引（目录），或者说没有给name字段创建索引，MySQL会进行全扫描，会将name字段上的每一个值都比对一边，效率会比较低（这是指没加索引的情况下相对）。
实际上每个字段都可以加索引，加了索引之后的字段就类似以下：
| id(idIndex) | name(nameIndex) | job(jobIndex) | salary(salaryIndex) |
| 15 | 刘地 | 地狼 | 12345 |
3、MYSQL的查询方式：
综上所述，其实MySQL在查询方面主要就是
a、全表扫描；
b、根据索引检索。
同时注意！
在实际中，汉语字典前面的目录是需要排序的，例如按a、b、c、d……进行排序。
为什么排序呢？因为只有排序了，才会有区间查找这一说法。而所谓的缩小查找范围，就是扫描某个区间而已！
在MySQL数据库当中，索引也是需要排序的，并且这个索引的排序和TreeSet数据结构相同。TreeSet（TreeMap）底层是一个自平衡的二叉树！在MySQL当中索引是一个B-Tree数据结构。
遵循左小右大原则存放，采用中序遍历方式遍历取数据。
二、索引的实现原理（以B树为例，目前基本使用B+树，如非必要，不要深究，跳过）
1、初步概述：
假设有一张用户表t_user：
| id(PK) | name | 每一行记录在硬盘上都有一个存储编号 |
| 10 | 刘地 | 0x11110 |
| 120 | 不知火舞 | 0x22200 |
| 99 | 花泽香菜 | ...... |
| 88 | 瑰儿 | ...... |
在任何数据库当中主键上都会自动添加索引对象！id字段上自动有索引，因为id是PK（主键）。另外在MySQL中，一个字段上如果有unique约束的话，也会自动创建索引对象。
简单理解，就是说：
1）在任何数据库当中，任何一张表的任何一条记录在硬盘存储上都有一个硬盘的物理存储编号；
2）在MySQL当中，索引是一个单独的对象，不同的存储引擎以不同的形式存在，在MyISAM存储引擎中，索引存储在一个.MYI文件中，在InnoDB引擎中索引存储在一个逻辑名称叫做tablespace（表空间）当中，而在Memory存储引擎中索引被存储在内存当中。不管索引存储在哪里，索引在MySQL当中都是一个树的形式存在。（自平衡二叉树：B-Tree）。
2、实现步骤：通过步骤了解索引的创建生成以及作用
如图：
1）当我们为id这个字段创建了索引，数据库就会把字段创建为一个树形结构目录，规则是左小右大（从左往右，左边数值小右边数值大）。并且，实际上在物理硬盘中，每个索引实际就是一个数据，在硬盘中会自动给数据记录一条物理记录（0x11111之类的）
2）当我们使用查询语句对该表进行查询，MySQL就会先去每个字段进行索引搜索，发现id字段上存在索引对象，然后通过索引对象idIndex进行查找。
3）通过索引对象定位到查找到101这个id，索引的作用就在于缩小了扫描的范围，就相当于你给让我找101数字，我通过目录去找100开头的区块，那么就不需要去找1-99之类的块，快速定位到这个id 所在区块。
4）定位到id区块之后，找到了该id对应的位置（实际上此时索引工作就结束了），然后直接读取硬盘的记录（物理存储编号0x111111），拿到对应记录数据。
总结：
1）创建索引，数据库创建一个树形结构索引对象，并且索引会自动排序；
2）当执行查询语句，数据库会优先寻找存在索引的字段，当字段被肯定存在索引，就会找该字段索引目录；
3）通过目录对比所求数据，缩小寻找范围，定位这个数据所在的区块，找到数据；
4）直接读取该数据所在位置的物理存储位置，拿出数据，语句执行结束。
以上，就是索引的作用，对比全盘扫描的效率毋庸置疑是很明显，并且对比无序无索引的数据查找也是很明显。
三、索引的存储形式：B+Tree（如非必要，不要深究，跳过）
1、MYSQL中索引的特点：
首先我们在索引定义中知道了，索引具有以下的特点：
1）索引是一种提高效率的机制，帮助数据库高效查找；
2）索引就是一种数据结构；
3）索引是存放在文件系统中的，需要创建存放；
4）索引的存储形式与你的表指定的存放引擎有关。
在上面索引的实现原理中，我们知道索引实际上创建之后，在数据库中形成树结构目录，当我们需要寻找索引对应的某一个数据，现在在MySQL中会通过B+Tree实现中序查找。
2、索引文件的可存放形式：索引数据结构
由索引的特点可以知道，索引需要存放在文件中，那么索引可以存放为什么形式呢？
1）Hash表：
缺点：
a、利用hash存储的话需要将所有的数据文件添加到内存，比较耗费内存空间；
b、如果所有的查询都是等值查询，那么hash确实是很快，但是在企业或实际工作开发中范围查找的数据更多，而不是等值查询，因此hash就不太合适。
Hash虽然也是可以按下标进行查询，但hash是无序的，而如果按范围查询，查询有序的文件结构会更加清晰容易，例如一个实际情况 – 通常我们是按下标存放值，但是hash的无序特性导致实际2个相邻下标的值，经过hash算法存入后在表中距离可能会很远，而查询时按这2个值范围查询，会导致查询的效率低下，它可能需要遍历了整个表才找到另一个值。
2）二叉树、红黑树
二叉树和红黑树的索引格式如图，根节点延伸读取形成树状图，这样的存储结构，会导致假如我需要查询一个树状最底端的数值，那么读取的次数就必须多（也就是不合适范围读取），效率会低。
如果想优化树的索引，要么减少IO的次数，要么减少数据！
3）B-Tree（B树，-只是一个符号不发声）
B树特点：
a、所有键值分布在整棵树中；
b、搜索有可能在非叶子节点结束，在关键字全集内做一次查找，性能逼近二分查找；
c、每个节点最多拥有M个子树；
d、根节点至少拥有2个子树；
e、分支节点至少拥有m/2颗子树，（除根节点和叶子节点外都是分支节点）
f、所有叶子节点都在同一层、每个节点最多可以有m-1个key，并且以升序排列。
示例图说明：
每个节点占用一个磁盘块（就类似一个页page），一个节点上有2个升序排序的关键字和3个指向子树根节点的指针，指针存储的是子节点所在磁盘块的地址。
2个关键字划分成的3个范围域，对应3个指针所指向的子树数据的范围域：以根节点为例，关键字为16和34，p1指针指向的子树数据范围就会小于16，p2指针指向的子树范围就会在16-34之间，而p3则是指向了大于34的子树范围。
查找关键字的过程是这样的：
·根据根节点找到磁盘块1，读入内存。【磁盘I/O操作第1次】
·比较关键字28在区间（16-34），找到磁盘块1的指针p2，
·根据p2指针找到磁盘块3，读入内存。【磁盘I/O操作第2次】
·比较关键字28在区间（25-31），找到磁盘块3的指针p2，
·根据p2指针找到磁盘块8，读入内存。【磁盘I/O操作第3次】
·比较磁盘块8的关键字列表，找到关键字28.
缺点就很明显了：
- 每个节点都有key，同时也包含data，而每个页存储空间是有限的，如果data比较大的话会导致每个节点存储的key数量变小；
- 当存储的数据量很大的时候，会导致深度较大，增加查询时磁盘IO的次数，进而影响查询性能。
4）B+Tree（B+树）：重点！Mysql中默认应用
B+Tree是在BTree的基础之上做的一种优化，变化如下：
a、B+Tree每个节点可以包含更多的节点，这个做的原因有2个，一是为了降低树的高度，二是2将数据范围变为多个区间，区间越多，数据检索越快；
b、非叶子节点存储key，叶子节点存储key和数据；
c、叶子节点两两指针相互连接（符合磁盘的预读特性），顺序查询性能更高
注意：在B+Tree上有2个头指针，一个指向根节点，另一个指向关键字最小的叶子节点，而且所有叶子节点（即数据节点）之间是一种链式环结构，因此可以对B+Tree进行2种查找运算：一种是对于主键的范围查找也分页查找，另一种是从根节点开始，进行随机查找。
3、什么是树？
具体内容可以参考该文章：
https://www.cnblogs.com/tiancai/p/9024351.html
因为我不是这个研究方向的，我就不深入说明，因为说了也记不住的。。
下面我简单做一点点的概要，用于记录：大部分引用于URL链接的内容
·树是一种数据结构，被广泛应用于索引以及表之中，主要功能简单理解就是便于数据的分类查找。
在上面索引文件数据结构中，我们知道索引其实可以分不同结构形式存储，但是为什么在MySQL中我们会使用B+Tree进行存储呢？主要是树的性质优化考虑，下面可以大概了解树的种类：
1）二叉查找树
二叉查找树也称为有序二叉查找树，满足二叉查找树的一般性质，是指一棵空树具有如下性质：
a、任意节点左子树不为空,则左子树的值均小于根节点的值；
b、任意节点右子树不为空,则右子树的值均大于于根节点的值；
c、任意节点的左右子树也分别是二叉查找树；
d、没有键值相等的节点；
上图为一个普通的二叉查找树，按照中序遍历的方式可以从小到大的顺序排序输出：2、3、5、6、7、8。
对上述二叉树进行查找，如查键值为5的记录，先找到根，其键值是6，6大于5，因此查找6的左子树，找到3；而5大于3，再找其右子树；一共找了3次。如果按2、3、5、6、7、8的顺序来找同样需求3次。用同样的方法在查找键值为8的这个记录，这次用了3次查找，而顺序查找需要6次。计算平均查找次数得：顺序查找的平均查找次数为（1+2+3+4+5+6）/ 6 = 3.3次，二叉查找树的平均查找次数为（3+3+3+2+2+1）/6=2.3次。二叉查找树的平均查找速度比顺序查找来得更快。
-- 局限性及应用：
一个二叉查找树是由n个节点随机构成，所以，对于某些情况，二叉查找树会退化成一个有n个节点的线性链。例如下图：
如果我们的根节点选择是最小或者最大的数，那么二叉查找树就完全退化成了线性结构。上图中的平均查找次数为（1+2+3+4+5+5）/6=3.16次，和顺序查找差不多。显然这个二叉树的查询效率就很低，因此若想最大性能的构造一个二叉查找树，需要这个二叉树是平衡的（这里的平衡从一个显著的特点可以看出这一棵树的高度比上一个输的高度要大，在相同节点的情况下也就是不平衡），从而引出了一个新的定义-平衡二叉树AVL。
2）AVL树 – 平衡二叉树
-- 简介：
AVL树是带有平衡条件的二叉查找树，一般是用平衡因子差值判断是否平衡并通过旋转来实现平衡，左右子树树高不超过1，和红黑树相比，它是严格的平衡二叉树，平衡条件必须满足（所有节点的左右子树高度差不超过1）。不管我们是执行插入还是删除操作，只要不满足上面的条件，就要通过旋转来保持平衡，而旋转是非常耗时的，由此我们可以知道AVL树适合用于插入删除次数比较少，但查找多的情况）。
从上面是一个普通的平衡二叉树，这张图我们可以看出，任意节点的左右子树的平衡因子差值都不会大于1。
·局限性
由于维护这种高度平衡所付出的代价比从中获得的效率收益还大，故而实际的应用不多，更多的地方是用追求局部而不是非常严格整体平衡的红黑树。当然，如果应用场景中对插入删除不频繁，只是对查找要求较高，那么AVL还是较优于红黑树。
·应用
1、Windows NT内核中广泛存在。
3）红黑树
-- 简介：
一种二叉查找树，但在每个节点增加一个存储位表示节点的颜色，可以是red或black。通过对任何一条从根到叶子的路径上各个节点着色的方式的限制，红黑树确保没有一条路径会比其它路径长出两倍。它是一种弱平衡二叉树(由于是若平衡，可以推出，相同的节点情况下，AVL树的高度低于红黑树)，相对于要求严格的AVL树来说，它的旋转次数变少，所以对于搜索、插入、删除操作多的情况下，我们就用红黑树。
-- 性质：
a、每个节点非红即黑；
b、根节点是黑的；
c、每个叶节点(叶节点即树尾端NULL指针或NULL节点)都是黑的；
d、如果一个节点是红的,那么它的两儿子都是黑的；
e、对于任意节点而言，其到叶子点树NULL指针的每条路径都包含相同数目的黑节点；
f、每条路径都包含相同的黑节点；
-- 应用：
a、广泛用于C++的STL中，Map和Set都是用红黑树实现的；
b、著名的Linux进程调度Completely Fair Scheduler，用红黑树管理进程控制块，进程的虚拟内存区域都存储在一颗红黑树上，每个虚拟地址区域都对应红黑树的一个节点，左指针指向相邻的地址虚拟存储区域，右指针指向相邻的高地址虚拟地址空间；
c、IO多路复用epoll的实现采用红黑树组织管理sockfd，以支持快速的增删改查；
d、Nginx中用红黑树管理timer，因为红黑树是有序的，可以很快的得到距离当前最小的定时器；
e、Java中TreeMap的实现。
4）B-Tree：B树（内容较长，如非必要，不用看了）
-- 简介：
MySQL中的数据一般是放在磁盘中的，读取数据的时候肯定会有访问磁盘的操作，磁盘中有两个机械运动的部分，分别是盘片旋转和磁臂移动。盘片旋转就是我们市面上所提到的多少转每分钟，而磁盘移动则是在盘片旋转到指定位置以后，移动磁臂后开始进行数据的读写。那么这就存在一个定位到磁盘中的块的过程，而定位是磁盘的存取中花费时间比较大的一块，毕竟机械运动花费的时候要远远大于电子运动的时间。当大规模数据存储到磁盘中的时候，显然定位是一个非常花费时间的过程，但是我们可以通过B树进行优化，提高磁盘读取时定位的效率。
为什么B类树可以进行优化呢？我们可以根据B类树的特点，构造一个多阶的B类树，然后在尽量多的在结点上存储相关的信息，保证层数尽量的少，以便后面我们可以更快的找到信息，磁盘的I/O操作也少一些，而且B类树是平衡树，每个结点到叶子结点的高度都是相同，这也保证了每个查询是稳定的。
总的来说，B/B+树是为了磁盘或其它存储设备而设计的一种平衡多路查找树(相对于二叉，B树每个内节点有多个分支)，与红黑树相比，在相同的的节点的情况下，一颗B/B+树的高度远远小于红黑树的高度(在下面B/B+树的性能分析中会提到)。B/B+树上操作的时间通常由存取磁盘的时间和CPU计算时间这两部分构成，而CPU的速度非常快，所以B树的操作效率取决于访问磁盘的次数，关键字总数相同的情况下B树的高度越小，磁盘I/O所花的时间越少。
-- 性质：
a、定义任意非叶子结点最多只有M个儿子，且M>2；
b、根结点的儿子数为[2, M]；
c、除根结点以外的非叶子结点的儿子数为[M/2, M]；
d、每个结点存放至少M/2-1（取上整）和至多M-1个关键字；（至少2个关键字）
e、非叶子结点的关键字个数=指向儿子的指针个数-1；
f、非叶子结点的关键字：K[1], K[2], …, K[M-1]；且K[i] < K[i+1]；
g、非叶子结点的指针：P[1], P[2], …, P[M]；其中P[1]指向关键字小于K[1]的子树，P[M]指向关键字大于K[M-1]的子树，其它P[i]指向关键字属于(K[i-1], K[i])的子树；
h、所有叶子结点位于同一层；
5）B+Tree：B+树
-- 简介：
B+树是应文件系统所需而产生的一种B树的变形树（文件的目录一级一级索引，只有最底层的叶子节点（文件）保存数据）非叶子节点只保存索引，不保存实际的数据，数据都保存在叶子节点中，这不就是文件系统文件的查找吗?
我们就举个文件查找的例子：有3个文件夹a、b、c， a包含b，b包含c，一个文件yang.c，a、b、c就是索引（存储在非叶子节点）， a、b、c只是要找到的yang.c的key，而实际的数据yang.c存储在叶子节点上。
所有的非叶子节点都可以看成索引部分！
--B+树的性质(下面提到的都是和B树不相同的性质)：
a、非叶子节点的子树指针与关键字个数相同；
b、非叶子节点的子树指针p[i],指向关键字值属于[k[i],k[i+1]]的子树.(B树是开区间,也就是说B树不允许关键字重复,B+树允许重复)；
c、为所有叶子节点增加一个链指针；
d、所有关键字都在叶子节点出现(稠密索引). (且链表中的关键字恰好是有序的)；
e、非叶子节点相当于是叶子节点的索引(稀疏索引),叶子节点相当于是存储(关键字)数据的数据层；
f、更适合于文件系统；
非叶子节点（比如5，28，65）只是一个key（索引），实际的数据存在叶子节点上（5，8，9）才是真正的数据或指向真实数据的指针。
-- 应用
1、B和B+树主要用在文件系统以及数据库做索引，比如MySQL
6）为什么MySQL使用B+Tree？（为什么B+Tree比B树更合适数据库索引）
a、B+Tree的磁盘读写代价更低！
b、B+Tree的查询效率更为稳定！
c、由于B+Tree的数据都存储在叶子节点中，分支均为索引，方便扫库，只需要扫描一次叶子节点即可，但是B树因为其分支节点同样存储着数据，我们要找到具体数据需要进行一次中序查询按序寻找（也就是课件例子），那么B+Tree更合适区间查询，所以通常B+Tree会用于数据库索引。
PS：我在知乎上看到有人是这样说的,我感觉说的也挺有道理的：
他们认为数据库索引采用B+树的主要原因是：B树在提高了IO性能的同时并没有解决元素遍历的我效率低下的问题，正是为了解决这个问题，B+树应用而生。B+树只需要去遍历叶子节点就可以实现整棵树的遍历。而且在数据库中基于范围的查询是非常频繁的，而B树不支持这样的操作或者说效率太低。
四、索引的应用环境：
首先，索引不能随意添加！需要根据实际使用环境而考虑是否需要使用索引。
在MYSQL中，主键约束字段（primarykey）、唯一约束字段上（unique），是会自动创建索引的（要注意索引和约束的区别！不要混淆，索引用于检索查询，约束，则是字段上的一种限制）。
1、索引应用考虑的条件：
1）数据量庞大：
每个数据库所在的硬件环境不一样，怎么判断它是否庞大？需要进行数据测试，这个是受到硬件环境影响，比如阿里云存放数据上亿也并不费力效率很高，对阿里云而言它不大，但是如果是把上亿的数据记录存放在我们自己个人电脑上，那么分分钟导致卡死对吧？这个是硬件影响。
2）该字段被扫描次数频繁：
该字段经常出现在where后面，以条件的形式存在，也就是说这个字段总是被扫描。（例如在用户表中总是用名字查找记录select * from user where name = #{name}，此时就可以考虑name是否需要加索引）。
3）该字段很少DML操作：增删改很少
即这个字段几乎只会用于做查询操作，不会做其他的操作（因为表经过增删改操作之后索引会被重新排序）。
2、索引使用注意：
1）建议不要随意添加索引，因为索引是需要存储空间以及维护的，假如实际数据存量少，但索引多反而导致资源占用多降低系统性能。
2）假如主键字段（primarykey）以及唯一字段（unique）已经足够可以，那么就直接通过这2个约束字段进行查询，效率会更高，不需要给其他字段进行添加索引。
五、索引的使用：
1、创建索引：
1）格式：
CREATE INDEX 索引名 on 表名（字段名）；
2）示例：
CREATE INDEX emp_ename_index on emp(name);
2、删除索引：
1）格式：
DROP INDEX 索引名称 on 表名;
2）示例：
DROP INDEX emp_ename_index on emp;
3、查看索引：
1）全表索引查看：
全表索引查看SQL可以显示出该表每一个存在索引的字段：
SHOW INDEX FROM 表名[FROM 数据库名];当进入数据库中的时候，也可以直接用下面的SQL：
SHOW INDEX FROM 表名;
2）索引信息解析：
| 参数 | 说明 |
| Table | 表示创建索引的数据表名。 |
| Non_unique | 表示该索引是否是唯一索引。若不是唯一索引，则该列的值为 1；若是唯一索引，则该列的值为 0。 |
| Key_name | 表示索引的名称。 |
| Seq_in_index | 表示该列在索引中的位置，如果索引是单列的，则该列的值为 1；如果索引是组合索引，则该列的值为每列在索引定义中的顺序。 |
| Column_name | 表示定义索引的列字段。 |
| Collation | 表示列以何种顺序存储在索引中。在 MySQL 中，升序显示值“A”（升序），若显示为 NULL，则表示无分类。 |
| Cardinality | 索引中唯一值数目的估计值。基数根据被存储为整数的统计数据计数，所以即使对于小型表，该值也没有必要是精确的。基数越大，当进行联合时，MySQL 使用该索引的机会就越大。 |
| Sub_part | 表示列中被编入索引的字符的数量。若列只是部分被编入索引，则该列的值为被编入索引的字符的数目；若整列被编入索引，则该列的值为 NULL。 |
| Packed | 指示关键字如何被压缩。若没有被压缩，值为 NULL。 |
| Null | 用于显示索引列中是否包含 NULL。若列含有 NULL，该列的值为 YES。若没有，则该列的值为 NO。 |
| Index_type | 显示索引使用的类型和方法（BTREE、FULLTEXT、HASH、RTREE）。 |
| Comment | 显示评注。 |
3）字段索引查看：
字段索引查看是通过解析SQL语句，在语句后加上where 结合字段条件进行分析，例如：
EXPLAIN SELECT * FROM emp WHERE id = 13;
-- explain解析概要：
id:选择标识符
select_type:表示查询的类型。
table:输出结果集的表
partitions:匹配的分区
type:表示表的连接类型
possible_keys:表示查询时，可能使用的索引
key:表示实际使用的索引
key_len:索引字段的长度
ref:列与索引的比较
rows:扫描出的行数(估算的行数)
filtered:按表条件过滤的行百分比
Extra:执行情况的描述和说明
该查询结果，是解释id这个主键字段是否存在索引，类型是什么。
当type值不是ALL的时候，说明存在索引，可以看显示的是const（主键索引），后面的ref列是说明索引类型比较。
要注意：字段索引实际上不能用于解释全表进行查询，这会导致展示全表均无索引，因为字段索引的方式，假如只要全表有一个字段不存在索引，则被解析为全表无索引。
4）MySQL8.0隐藏索引
在MySQL8.0版本后，出现了一个新功能，可以通过设置的方式，把索引进行隐藏，不加入检索机制，简单理解，是可以把既存类型的索引进行隐藏，不被优化器使用。
emm，作用是什么？举个例子，假如一张大表，存在几千万数据，需要优化，测试某个已存在索引的字段，实际是否需要索引，你可以设置隐藏，然后解析表语句查看性能，从而判断出实际是否需要保留索引，而不需要进行直接的删除、添加操作进行测试（这也会有性能影响，或者有些企业，生产数据未必允许这样操作）。
这个具体的作用可以参考这个文章：按道理，使用场景应该还是不多。
https://blog.csdn.net/weixin_32459211/article/details/113589309
4、通过数据库连接软件进行所有的图形化操作：
对于上面所有的索引相关的操作，实际上都可以通过数据库软件进行图形化的操作，也是最直接简单的。例如：DBeaver、Navicat等等，针对不同数据库都可以使用。在实际开发中，也是推荐这个方式去操作。
六、索引的类型：重点
针对关系型数据库的索引种类，可以按2个大方面划分，一是从功能逻辑上（下面展开），二是从物理实现上划分（有聚簇索引和非聚簇索引，这里不展开描述）。
1、普通索引：
也称单一索引，只在某一个字段上添加一个索引INDEX，通过该字段检索时可以加速；设置方式：把表emp的username字段，建立索引名为idx_username，
ALTER TABLE emp ADD INDEX idx_username (username);
2、主键索引：
全表只允许存在一个主键索引字段。给字段设置为主键时，默认为主键索引，约束性质也为主键约束。该字段被要求为非空、唯一。设置方式：建立表emp，字段id设置为主键primary key（即为主键索引）。
CREATE TABLE emp(
id INT(11) NOT NULL AUTO_INCREMENT,
PRIMARY KEY (id)
);主键索引，通常建议在表创建时设置，避免后续使用再修改。
3、唯一索引：
通过参数unique，把字段设置为唯一索引，字段值必须唯一，不可重复，允许null值。格式：
把表users的username字段增加为唯一索引。
ALTER TABLE users ADD UNIQUE INDEX idx_username (username);
4、全文索引：只能添加在content、TEXT类型的字段
全文索引一般时针对大文本进行检索而是用的索引模式，通过关键字FULLTEXT指定INDEX为全文索引：
ALTER TABLE articles ADD FULLTEXT INDEX idx_content (content) WITH PARSER ngram;注意，上面创建全文索引时我们指定了使用名为“ngram”的分词器来为content列创建全文索引。
全文索引的使用在目前非常少，这里不多阐述，如果有需要使用时，在按最新的版本去搜索查看用法。
5、复合索引（组合索引）：
使用2个或以上的字段来建立一个索引，就是复合（组合）索引，例如：
CREATE INDEX emp_name_job_salary ON emp(job,salary);组合索引常用于多字段常被同时作为条件进行检索时。
七、常见索引失效的情况：
即什么情况下，你建立的索引未被使用，这个是针对优化的方面思考。
1、模糊查询条件使用%开头：
通常情况下，都不建议使用模糊查询。
2、OR关键字连接的字段存在无索引字段：
OR关键字也建议少用，但是实际上如果OR连接的所有字段均有索引，实际也是可以的。
3、组合索引未使用左列查询：
组合索引的创建形式是：INDEX idx_组合索引名(a列，b列），这里的a列称为左列，如果查询条件中，没有通过a列查询，直接使用b列，那么此时组合索引会失效。
4、where中索引参与了运算：
SELECT * FROM emp WHERE salary +1=9201;此时，索引失效。
5、where中索引使用了函数：
SELECT * FROM emp WHERE LOWER(name) = "xxx";此时索引会失效。
6、其他。。自行搜索
扫一扫
902
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
