Mysql超详细知识梳理-索引篇
2022-04-22 19:08:38 0 举报AI智能生成
登录查看完整内容
Mysql超详细知识梳理-索引原理分析
作者其他创作
大纲/内容
分支主题
Select语句执行流程
官方介绍索引是帮助MySQL高效获取数据的数据结构。更通俗的说，数据库索引好比是一本书前面的目录，能加快数据库的查询速度
一般来说索引本身也很大，不可能全部存储在内存中，因此索引往往是存储在磁盘上的文件中的（可能存储在单独的索引文件中，也可能和数据一起存储在数据文件中）。
我们通常所说的索引，包括聚集索引、覆盖索引、组合索引、前缀索引、唯一索引等，没有特别说明，默认都是使用B+树结构组织（多路搜索树，并不一定是二叉的）的索引。
索引是什么
可以提高数据检索的效率，降低数据库的IO成本，类似于书的目录。
被索引的列会自动进行排序，包括【单列索引】和【组合索引】，只是组合索引的排序要复杂一些。
如果按照索引列的顺序进行排序，对应order by语句来说，效率就会提高很多。
通过索引列对数据进行排序，降低数据排序的成本，降低了CPU的消耗。
优势：
索引会占据磁盘空间
索引虽然会提高查询效率，但是会降低更新表的效率。比如每次对表进行增删改操作，MySQL不仅要保存数据，还有保存或者更新对应的索引文件。
劣势：
索引的优势和劣势
索引介绍
是一种特殊的唯一索引，索引列中的值必须是唯一的，不允许有空值。
ALTER TABLE table_name ADD PRIMARY KEY (column_name);
主键索引
MySQL中基本索引类型，没有什么限制，允许在定义索引的列中插入重复值和空值，纯粹为了查询数据更快一点。
ALTER TABLE table_name ADD INDEX index_name (column_name) ;
普通索引
索引列中的值必须是唯一的，但是允许为空值。
CREATE UNIQUE INDEX index_name ON table(column_name) ;
唯一索引
innodb 从1.2.x 开始才增加了全文索引支持。而MySQL5.6版本中innodb的版本才升级到 1.2.x。
https://dev.mysql.com/doc/refman/5.7/en/innodb-fulltext-index.html
MyISAM和InnoDB中都可以使用全文索引。
ALTER TABLE `t_fulltext` ADD FULLTEXT INDEX `idx_content`(`content`);
创建全文索引
可以使用MATCH() ... AGAINST语法执行全文搜索。
SELECT * FROM t_fulltext WHERE MATCH(content) AGAINST('开课吧');
使用全文索引
全文索引
MySQL在5.7之后的版本支持了空间索引，而且支持OpenGIS几何数据模型。MySQL在空间索引这方面遵循OpenGIS几何数据模型规则。
空间索引
ALTER TABLE table_name ADD INDEX index_name (column1(length));
前缀索引
在表中的多个字段组合上创建的索引
组合索引的使用，需要遵循最左前缀原则（最左匹配原则）。
一般情况下，建议使用组合索引代替单列索引（主键索引除外，具体原因后面知识点讲解）。
组合索引
分类
DROP INDEX index_name ON table
删除索引
SHOW INDEX FROM table_name \\G
查看索引
使用
索引的分类与使用
索引的数据结构，至少需要支持两种最常用的查询需求：
1. 等值查询：根据某个值查找数据，比如：select * from t_user where age=76;
2. 范围查询：根据某个范围区间查找数据，比如：select * from t_user where age>=76 and age<=86;
同时需要考虑时间和空间因素。在执行时间方面，我们希望通过索引，查询数据的时间尽可能小；在存储空间方面，我们希望索引不要消耗太多的内存空间和磁盘空间。
索引的要求
常用的数据结构：Hash表，二叉树，平衡二叉查找树（红黑树是一个近似平衡二叉树），B树，B+树。
Hash表，Java中的HashMap就是Hash表结构，以键值对的方式存储数据。我们使用Hash表存储表数据Key可以存储索引列，Value可以存储行记录或者行磁盘地址。
Hash表在等值查询时效率很高，时间复杂度为O(1)；但是不支持范围快速查找，范围查找时还是只能通过扫描全表方式。
1）Hash表
二叉树特点：每个节点最多有2个分叉，左子树和右子树数据顺序左小右大。
将age列构建二叉树，检索age=76的数据，只需要三次IO就可以查询到结果：30->86->76，查询效率貌似看是提升了一倍，可以看到二叉树的检索复杂度和树高相关。
那是不是任何列使用二叉树效率都会提升呢？答案是否定的。比如，将id列构建二叉树，可以看到二叉树退化为一个单向链表，查询id=6的数据，需要全表扫描。
2）二叉查找树
平衡二叉树是采用二分法思维，平衡二叉查找树除了具备二叉树的特点，最主要的特征是树的左右两个子树的层级最多相差1。在插入删除数据时通过左旋/右旋操作保持二叉树的平衡，不会出现左子树很高、右子树很矮的情况。
使用平衡二叉查找树查询的性能接近于二分查找法，时间复杂度是 O(log2n)。查询id=6，只需要两次IO。
1. 时间复杂度和树高相关。树有多高就需要检索多少次，每个节点的读取，都对应一次磁盘 IO 操作。树的高度就等于每次查询数据时磁盘 IO 操作的次数。磁盘每次寻道时间为10ms，在表数据量大时，查询性能就会很差。（1百万的数据量，log2n约等于20次磁盘IO，时间20*10=0.2s）
2. 平衡二叉树不支持范围查询快速查找，范围查询时需要从根节点多次遍历，查询效率不高。
平衡二叉树存在的问题
3）平衡二叉查找树
假如key为bigint=8字节，每个节点有两个指针，每个指针为4个字节，一个节点占用的空间16个字节（8+4*2=16）。
我们知道，MySQL的InnoDB存储引擎一次IO会读取的一页16K的数据量，而二叉树一次IO有效数据量只有16字节，空间利用率极低。
为了最大化利用一次IO空间，一个朴素的想法是在每个节点存储多个元素，在每个节点尽可能多的存储数据。每个节点可以存储1000个索引（16k/16=1000），这样就将二叉树改造成了多叉树，通过增加树的叉树，将树从高瘦变为矮胖。构建1百万条数据，树的高度只需要2层就可以（1000*1000=1百万），也就是说只需要2次磁盘IO就可以查询到数据。磁盘IO次数变少了，查询数据的效率也就提高了。
MySQL的数据是存储在磁盘文件中的，查询处理数据时，需要先把磁盘中的数据加载到内存中，磁盘 IO操作非常耗时，所以我们优化的重点就是尽量减少磁盘 IO 操作。访问二叉树的每个节点就会发生一次IO，如果想要减少磁盘IO操作，就需要尽量降低树的高度。那如何降低树的高度呢？
1. B树的节点中存储着多个元素，每个内节点有多个分叉。
2. 节点中的元素包含键值和数据，节点中的键值从大到小排列。也就是说，在所有的节点都储存数据。
3. 父节点当中的元素不会出现在子节点中。
4. 所有的叶子结点都位于同一层，叶节点具有相同的深度，叶节点之间没有指针连接。
这种数据结构我们称为B树，B树是一种多叉平衡查找树，如下图主要特点：
以下面的B树为例，我们的键值为表主键，具备唯一性。
假如我们查询值等于15的数据。查询路径磁盘块1->磁盘块2->磁盘块7。
第一次磁盘IO：将磁盘块1加载到内存中，在内存中从头遍历比较，15<17，走左路，到磁盘寻址磁盘块2。
第二次磁盘IO：将磁盘块2加载到内存中，在内存中从头遍历比较，12<15，到磁盘中寻址定位到磁盘块7。
第三次磁盘IO：将磁盘块7加载到内存中，在内存中从头遍历比较，15=15，找到15，取出data，如果data存储的行记录，取出data，查询结束。如果存储的是磁盘地址，还需要根据磁盘地址到磁盘中取出数据，查询终止。
相比二叉平衡查找树，在整个查找过程中，虽然数据的比较次数并没有明显减少，但是磁盘IO次数会大大减少。同时，由于我们的比较是在内存中进行的，比较的耗时可以忽略不计。B树的高度一般2至3层就能满足大部分的应用场景，所以使用B树构建索引可以很好的提升查询的效率。
等值查询
1. B树不支持范围查询的快速查找，如果我们想要查找15和26之间的数据，查找到15之后，需要回到根节点重新遍历查找，需要从根节点进行多次遍历，查询效率有待提高。
2. 如果data存储的是行记录，行的大小随着列数的增多，所占空间会变大。这时，一个页中可存储的数据量就会变少，树相应就会变高，磁盘IO次数就会变大。
B树的缺点：
4）B树：改造二叉树
B树：非叶子节点和叶子节点都会存储数据。
B+树：只有叶子节点才会存储数据，非叶子节点至存储键值。叶子节点之间使用双向指针连接，最底层的叶子节点形成了一个双向有序链表。
在B树基础上，MySQL在B树的基础上继续改造，使用B+树构建索引。B+树和B树最主要的区别在于非叶子节点是否存储数据的问题
B+树的最底层叶子节点包含所有索引项。
B+树查找数据，由于数据都存放在叶子节点，所以每次查找都需要检索到叶子节点，才能查询到数据。
B树查找数据时，如果在内节点中查找到数据，可以立即返回，比如查找值等于17的数据，在根节点中直接就可以找到，不需要再向下查找，具备中路返回的特点。
假如我们查询值等于15的数据。查询路径磁盘块1->磁盘块2->磁盘块5。
第一次磁盘IO：将磁盘块1加载到内存中，在内存中从头遍历比较，15<28，走左路，到磁盘寻址磁盘块2。
第二次磁盘IO：将磁盘块2加载到内存中，在内存中从头遍历比较，10<15<17，到磁盘中寻址定位到磁盘块5。
第三次磁盘IO：将磁盘块5加载到内存中，在内存中从头遍历比较，15=15，找到15，取出data，如果data存储的行记录，取出data，查询结束。如果存储的是磁盘地址，还需要根据磁盘地址到磁盘中取出数据，查询终止。
假如我们想要查找15和26之间的数据。查找路径是磁盘块1->磁盘块2->磁盘块5。
1.首先查找值等于15的数据，将值等于15的数据缓存到结果集。这一步和前面等值查询流程一样，发生了三次磁盘IO。
2.查找到15之后，底层的叶子节点是一个有序列表，我们从磁盘块5，键值15开始向后遍历筛选所有符合筛选条件的数据。
3.第四次磁盘IO：根据磁盘5后继指针到磁盘中寻址定位到磁盘块6，将磁盘6加载到内存中，在内存中从头遍历比较，15<17<26，15<26<=26，将data缓存到结果集。
4. 主键具备唯一性（后面不会有<=26的数据），不需再向后查找，查询终止。将结果集返回给用户。
范围查询
可以看到B+树可以保证等值和范围查询的快速查找，MySQL的索引就采用了B+树的数据结构。
5）B+树：改造B树
数据结构的选用
数据结构及算法基础
MyISAM的数据文件和索引文件是分开存储的。MyISAM使用B+树构建索引树时，叶子节点中存储的键值为索引列的值，数据为索引所在行的磁盘地址。
表t_user_myisam的索引存储在索引文件t_user_myisam.MYI中数据文件存储在数据文件t_user_myisam.MYD中。
我们以t_user_myisam为例，来说明。t_user_myisam的id列为主键，age列为普通索引。
select * from t_user_myisam where id=30;
1. 先在主键树中从根节点开始检索，将根节点加载到内存，比较30<56，走左路。（1次磁盘IO）
2. 将左子树节点加载到内存中，比较20<30<49，向下检索。（1次磁盘IO）
3. 检索到叶节点，将节点加载到内存中遍历，比较20<30，30=30。查找到值等于30的索引项。（1次磁盘IO）
4. 从索引项中获取磁盘地址，然后到数据文件t_user_myisam.MYD中获取对应整行记录。（1次磁盘IO）
5. 将记录返给客户端。
磁盘IO次数：3+1次。
等值查询数据
select * from t_user_myisam where id between 30 and 49;
3. 检索到叶节点，将节点加载到内存中遍历比较20<30，30<=30<49。查找到值等于30的索引项。根据磁盘地址从数据文件中获取行记录缓存到结果集中。（2次磁盘IO）我们的查询语句时范围查找，需要向后遍历底层叶子链表，直至到达最后一个不满足筛选条件。
4. 向后遍历底层叶子链表，将下一个节点加载到内存中，遍历比较，30<49<=49，根据磁盘地址从数据文件中获取行记录缓存到结果集中。（2次磁盘IO）
5. 最后得到两条符合筛选条件，将查询结果集返给客户端。
磁盘IO次数：2+检索叶子节点数量+记录数。
范围查询数据
MyISAM在查询时，会将索引节点缓存在MySQL缓存中，而数据缓存依赖于操作系统自身的缓存。
1）主键索引
查询数据时，由于辅助索引的键值不唯一，可能存在多个拥有相同的记录，所以即使是等值查询，也需要按照范围查询的方式在辅助索引树中检索数据。
2）辅助索引
MyISAM索引实现（非聚集索引）
每个InnoDB表都有一个聚簇索引 ，聚簇索引使用B+树构建，叶子节点存储的数据是整行记录。
1. 在表上定义主键PRIMARY KEY，InnoDB将主键索引用作聚簇索引。
2. 如果表没有定义主键，InnoDB会选择第一个不为NULL的唯一索引列用作聚簇索引。
3. 如果以上两个都没有，InnoDB 会使用一个6 字节长整型的隐式字段 ROWID字段构建聚簇索引。该ROWID字段会在插入新行时自动递增。
一般情况下，聚簇索引等同于主键索引，当一个表没有创建主键索引时，InnoDB会自动创建一个ROWID字段来构建聚簇索引。InnoDB创建索引的具体规则如下：
除聚簇索引之外的所有索引都称为辅助索引。在InnoDB中，辅助索引中的叶子节点存储的数据是该行的主键值都。 在检索时，InnoDB使用此主键值在聚簇索引中搜索行记录。
InnoDB索引简介
InnoDB的数据和索引存储在一个文件t_user_innodb.ibd中。InnoDB的数据组织方式，是聚簇索引。
我们以t_user_innodb为例，来说明。t_user_innodb的id列为主键，age列为普通索引。
主键索引的叶子节点会存储数据行，辅助索引只会存储主键值。InnoDB要求表必须有一个主键索引(MyISAM 可以没有)。
select * from t_user_innodb where id=30;
3. 检索到叶节点，将节点加载到内存中遍历，比较20<30，30=30。查找到值等于30的索引项，直接可以获取整行数据。将改记录返回给客户端。（1次磁盘IO）
磁盘IO次数：3次。
select * from t_user_innodb where id between 30 and 49;
3. 检索到叶节点，将节点加载到内存中遍历比较20<30，30<=30<49。查找到值等于30的索引项。获取行数据缓存到结果集中。（1次磁盘IO）
4. 向后遍历底层叶子链表，将下一个节点加载到内存中，遍历比较，30<49<=49，获取行数据缓存到结果集中。（1次磁盘IO）
5. 最后得到2条符合筛选条件，将查询结果集返给客户端。
可以看到，因为在主键索引中直接存储了行数据，所以InnoDB在使用主键查询时可以快速获取行数据。当表很大时，与在索引树中存储磁盘地址的方式相比，因为不用再去磁盘中获取数据，所以聚簇索引通常可以节省磁盘IO操作。
磁盘IO次数：2次+检索叶子节点数量。
除聚簇索引之外的所有索引都称为辅助索引，InnoDB的辅助索引只会存储主键值而非磁盘地址。
底层叶子节点的按照（age，id）的顺序排序，先按照age列从小到大排序，age列相同时按照id列从小到大排序。
使用辅助索引需要检索两遍索引：首先检索辅助索引获得主键，然后使用主键到主索引中检索获得记录。
以表t_user_innodb的age列为例，age索引的索引结果如下图。
select * from t_user_innodb where age=22;
1. 先在索引树中从根节点开始检索，将根节点加载到内存，比较22<77，走左路。（1次磁盘IO）
2. 将左子树节点加载到内存中，比较22<34，向下检索。（1次磁盘IO）
第一项5：5<22不符合要求，丢弃。
第二项22：等于22，符合要求，获取主键id=18，去主键索引树中检索id=18的数据放入结果集中。（回表：3次磁盘IO）。
第三项22：等于22，符合要求，获取主键id=49，去主键索引树中检索id=49的数据放入结果集中。（回表：3次磁盘IO）
3. 检索到叶节点，将节点加载到内存中从前往后遍历比较。（1次磁盘IO）
第一项34：34>22不符合要求，丢弃。查询结束。
4. 向后遍历底层叶子链表，将下一个节点加载到内存中，遍历比较。（1次磁盘IO）
根据在辅助索引树中获取的主键id，到主键索引树检索数据的过程称为回表查询。
磁盘IO次数：2次+检索叶子节点数量+记录数*3。
select * from t_user_innodb where age between 30 and 49;
辅助索引的范围查询流程和等值查询基本一致，先使用辅助索引到叶子节点检索到第一个符合条件的索引项，然后向后遍历，直到遇到第一个不符合条件的索引项，终止。
检索过程中需要将符合筛选条件的id值，依次到主键索引检索将检索的数据放入结果集中。
最后将查询结果返回客户端。
所以组合索引的最底层叶子节点中不存在完全相同的索引项。
1.组合索引存储结构
select * from t_multiple_index where a=13 and b=16 and c=4;
2. 将左子树节点加载到内存中，先比较a列，a=13，比较b列b=14，14<16，走右路，向下检索。（1次磁盘IO）
3. 达到叶节点，将节点加载到内存中从前往后遍历比较。（1次磁盘IO）
4. 最后得到1条符合筛选条件，将查询结果集返给客户端。
2.组合索引的查找方式
在组合索引树中，最底层的叶子节点按照第一列a列从左到右递增排列，但是b列和c列是无序的，b列只有在a列值相等的情况下小范围内递增有序，而c列只能在a，b两列相等的情况下小范围内递增有序。
所以当我们使用 where a=13 and b=16 and c=4去查询数据的时候，B+树会先比较a列来确定下一步应该搜索的方向，往左还是往右。如果a列相同再比较b列。但是如果查询条件没有a列，B+树就不知道第一步应该从哪个节点查起。
select * from t_multiple_index where a=13;select * from t_multiple_index where a=13 and b=16;select * from t_multiple_index where a=13 and b=16 and c=4;select * from t_multiple_index where a=13 and b>13;select * from t_multiple_index where a>11 and b=14;select * from t_multiple_index where a=16 and c=4;
所以联合索引只能从第一列开始查找，比如以下三个查询都可以使用idx_abc索引树，检索数据。
select * from t_multiple_index where b=16 and c=4;select * from t_multiple_index where c=4;
而如果查询条件不包含a列，比如筛选条件只有(b，c)或者c列是无法使用组合索引的。下面的查询没有用到索引。
最左前缀匹配原则和联合索引的索引存储结构和检索方式是有关系的。
组合索引的最左前缀匹配原则：使用组合索引查询时，mysql会一直向右匹配直至遇到范围查询(>、<、between、like)就停止匹配。
select * from t_multiple_index where b=16 and c=4 and a=13;#等价于下面的sql，优化器会按照索引的顺序优化select * from t_multiple_index where a=13 and b=16 and c=4 ;
另外，我们还需要注意的是，书写SQL条件的顺序，不一定是执行时候的where条件顺序。优化器会帮助我们优化成索引可以识别的形式。比如:
一颗索引树等价与三颗索引树，从另一方面了说，组合索引也为我们节省了磁盘空间。所以在业务中尽量选用组合索引，能使用组合索引就不要使用单列索引。
3.最左前缀匹配原则
1. 频繁出现在where条件中的列，建议创建组合索引。
2. 频繁出现在order by和group by语句中的列，建议按照顺序去创建组合索引。
3. 常出现在select语句中的列，也建议创建组合索引。
对于第1种情况和第3种情况，组合索引创建的顺序对其来说是等价的，这种情况下组合索引中的顺序，是很重要的。由于组合索引会使用到最左前缀原则，使用频繁的列在创建索引时排在前面。
下面的SQL语句除了建ab联合索引，还有更好的方案吗？select * from t where a=1 and b>2 order by c
思考题
4.组合索引创建原则
3）组合索引
select中列数据，如果可以直接在辅助索引树上全部获取，也就是说索引树已经“覆盖”了我们的查询需求，这时MySQL就不会白费力气的回表查询，这中现象就是覆盖索引。使用explain工具查看执行计划，可以看到extra中“Using index”，代表使用了覆盖索引。
前面我们提到，根据在辅助索引树查询数据时，首先通过辅助索引找到主键值，然后需要再根据主键值到主键索引中找到主键对应的数据。这个过程称为回表。使用辅助索引查询比基于主键索引的查询多检索了一棵索引树，那是不是所有使用辅助索引的查询都需要回表查询呢？
上面的查询语句用到了覆盖索引进行全表扫描。MySQL基于成本考虑，会使用了覆盖索引进行全表扫描，使用覆盖索引可以减少了磁盘IO次数，显著提升查询性能。
覆盖索引相比与主键索引一个索引项占用的空间少，覆盖索引一个叶子节点中的就可以比主键索引存放更多的数据量，相应的存放数据用到的总叶子树很少一些。
改为如下语句。大家猜猜这时会不会用到组合索引？
覆盖索引是一种很常用的优化手段。
4）覆盖索引(不用回表）
#optimizer_switch优化相关参数开关mysql> show VARIABLES like 'optimizer_switch'\\G;#关闭ICPSET optimizer_switch = 'index_condition_pushdown=off';#开启ICPSET optimizer_switch = 'index_condition_pushdown=on';
可以通过参数optimizer_switch控制ICP的开始和关闭。
ICP可以减少存储引擎必须访问基表的次数以及MySQL服务器必须访问存储引擎的次数。可用于InnoDB 和 MyISAM 表，对于InnoDB表ICP仅用于辅助索引。
MySQl在使用组合索引在检索数据时是使用最左前缀原则来定位记录，那不满足最左前缀的索引列，MySQL会怎么处理？
MySQL首先会在组合索引中定位到第一个满足a=13 and b>=15的索引项，MySQL之后会怎么处理呢？使用explain工具，查看执行计划，extra列中的“Using index condition”执行器表示使用了索引条件下推ICP。
ICP是MySQL 5.6引入的新特性，在使用ICP和不使用ICP时MySQL的执行情况会有所不同。
关闭ICP，使用explain工具，查看执行计划，extra列中的“Using where”执行器表示没有使用了索引条件下推ICP。
具体步骤如下：
5. 最终获取一条记录，返回给客户端。
可以看到，在不使用ICP时，回表查询了3次，然后在服务层筛选后（筛选3次），最后返回客户端。
使用ICP时，具体步骤如下：
4. 最终获取一条记录，返回给客户端。
可以看到，在使用ICP时，回表查询了2次，然后在服务层筛选后（筛选2次），最后返回客户端。
在MySQL 5.6 引入了ICP，可以在索引遍历过程中，对where中包含的索引条件先做判断，只有满足条件的才会回表查询读取行数据。这么做可以减少回表查询，从而减少磁盘IO次数。
以InnoDB的辅助索引为例，来讲解ICP的作用
不使用ICP，不满足最左前缀的索引条件的比较是在存储引擎层进行的，非索引条件的比较是在Server层进行的。
使用ICP，所有的索引条件的比较是在存储引擎层进行的，非索引条件的比较是在Server层进行的。
对比使用ICP和不使用ICP，可以看到使用ICP可以有效减少回表查询次数和返回给服务层的记录数，从而减少了磁盘IO次数和服务层与存储引擎的交互次数。
5）索引条件下推ICP
InnoDB索引实现（聚集索引）
MySQL索引实现
索引原理分析
1. 频繁出现在where 条件判断，order排序，group by分组字段
2. select 频繁查询的列，排序字段，考虑是否需要创建联合索引（覆盖索引，不回表）
3. 多表join关联查询，on字段两边的字段都要创建索引
哪些情况需要创建索引
1、表记录太少 索引是要有存储的开销
2、频繁更新 索引要维护
3、查询字段使用频率不高
哪些情况不需要创建索引
1. 表记录很少不需创建索引 （索引是要有存储的开销）.
（1）空间：浪费空间。每个索引都是一个索引树，占据大量的磁盘空间。
更新（插入/Delete/Update）变慢。需要更新所有的索引树。
太多的索引也会增加优化器的选择时间。
（2）时间：
所以索引虽然能够提高查询效率，索引并不是越多越好，应该只为需要的列创建索引。
2. 一个表的索引个数不能过多。
频繁更新的字段引发频繁的页分裂和页合并，性能消耗比较高。
3. 频繁更新的字段不建议作为索引。
比如性别，男，女；比如状态。区分度太低时，会导致扫描行数过多，再加上回表查询的消耗。如果使用索引，比全表扫描的性能还要差。这些字段一般会用在组合索引中。
姓名，手机号就非常适合建索引。
4. 区分度低的字段，不建议建索引。（仅供参考）
主键索引树一个页节点是16K，主键字段越长，一个页可存储的数据量就会越少，比较臃肿，查询时尤其是区间查询时磁盘IO次数会增多。辅助索引树上叶子节点存储的数据是主键值，主键值越长，一个页可存储的数据量就会越少，查询时磁盘IO次数会增多，查询效率会降低。
5. 在InnoDB存储引擎中，主键索引建议使用自增的长整型，避免使用很长的字段。
更新数据时会发生频繁的页分裂，页内数据不紧凑，浪费磁盘空间。
6. 不建议用无序的值作为索引。例如身份证、UUID
（1）1个组合索引等同于多个索引效果，节省空间。
（2）可以使用覆盖索引
优点
创建原则：组合索引应该把把频繁的列，区分度高的值放在前面。频繁使用代表索引的利用率高，区分度高代表筛选粒度大，可以尽量缩小筛选范围。
7. 尽量创建组合索引，而不是单列索引。
索引优化建议
不管一张表有几个索引，在查询的时候，最多只能使用一个索引，除了index-merge这种情况
索引创建原则
1.全值匹配我最爱
带头索引不能死，中间索引不能断如果索引了多个列，要遵守最佳左前缀法则。指的是查询从索引的最左前列开始 并且不跳过索引中的列。
2.最佳左前缀法则
不要进行这些操作：计算、函数、自动/手动类型转换，不然会导致索引失效而转向全表扫描
3.不要在索引上做计算
不能继续使用索引中范围条件（bettween、<、>、in等）右边的列
4.范围条件右边的列失效
尽量使用覆盖索引（只查询索引的列），也就是索引列和查询列一致，减少select *
5.尽量使用覆盖索引
索引字段上使用（！= 或者 < >）判断时，会导致索引失效而转向全表扫描
6.索引字段上不要使用不等于
索引字段上使用 is null / is not null 判断时，会导致索引失效而转向全表扫描
7.索引字段上不要判断null（看区分度）
索引字段使用like以通配符开头（‘%字符串’）时，会导致索引失效而转向全表扫描
like以通配符结束相当于范围查找，索引不会失效。与范围条件（bettween、<、>、in等）不同的是：不会导致右边的索引失效。
解决like ‘%字符串%’时，索引失效问题的方法？ 使用覆盖索引可以解决。
8.索引字段使用like不以通配符开头
索引字段是字符串，但查询时不加单引号，会导致索引失效而转向全表扫描
本质是因为做了隐式转换，相当于使用了函数
9.索引字段字符串要加单引号
索引字段使用 or 时，会导致索引失效而转向全表扫描
用or分割开的条件， 如果or前的条件中的列有索引，而后面的列中没有索引，那么涉及的索引都不会被用到。
只要or条件中连续字段有任意一个没有索引，其他字段索引全部失效，and不会失效
10.索引字段少用or
例如某一列有大量重复数据，哪怕建立了索引，如果查询条件是重复的那个数据，Mysql底层执行器执行计划的时候，发现12条11条都是这个重复数据，还不如全表扫描快，所以就放弃索引，直接走全表扫描。
11.如果MySQL评估使用索引比全表更慢，则不使用索引。
原理和11一样，mysql数据库底层会自动判断，如果走全表扫描快就走全表扫描。
is null 如果走了索引，原因就是发现某列所有值、或大部分值都是非空的，那空在这个字段里面意味着少量的，这个时候就会走索引
is not null，相反因为当前字段所有值或大部分值都是非空的，所以is not null还不如走全表扫描
12.is NULL ， is NOT NULL 有时索引失效。
13.in 走索引， not in 索引失效。
全值匹配我最爱，最左前缀要遵守；带头大哥不能死，中间兄弟不能断；索引列上不计算，范围之后全失效；Like百分写最右，覆盖索引不写星；不等空值还有OR，索引失效要少用。
索引使用口诀
索引失效分析
索引失效
Mysql索引篇
收藏
0 条评论
回复 删除
下一页
