首页 > 其他分享> 文章详细

索引

2022-06-06 14:33:03 阅读：112 来源： 互联网

标签：name 索引 user 失效 WHERE SELECT

检索效率、存储资源、索引维护

索引是个什么东东？

　　索引就像指向表行的指针，是一种允许查询操作快速确定哪些行符合WHERE子句中的条件，并检索到这些行的其他列值的数据结构。

索引分类？

　　普通索引、唯一索引、主键索引、外键索引、全文索引、符合索引(联合索引)。

使用索引的优缺点？

　　在大数据量的查询中。合理使用索引的优点非常明显不仅能大幅提高匹配where条件的检索效率，还能用于排序和分组操作的加速。

　　当索引使用不当是也有较大的坏处的哦：比如索引必定会增加存储资源的消耗；同时也增大了插入、更新和删除操作的维护成本，因为每个增删改操作后相应列的索引都必须被更新

使用时我们要注意的？

　　①只要创建索引就一定会走索引吗？：不一定。比如在使用联合索引的时候，如果没有遵从“最左前缀”的原则进行搜索，则索引是不起作用的。比如：我在id、name、age字段上成功建立了一个名字为：Multidx联合索引。索引行按id、name、age的顺序存放，索引可以搜索id、(id,name)、(id,name,age)字段组合。如果列不构成索引最左面的前缀,那么MySQL不能使用局部索引,如（age）或者（name,age）组合则不能使用该索引查询。

　　②什么情况会造成索引失效？：

 1 1、使用!= 或 <>
 3 例如：name字段设置了索引，使用：SELECT * FROM `user` WHERE `name` != '冰峰'; SQL语句查询，时进行了全表扫描，导致索引失效，最好可以看到type类型为all.


 7 2、最左前缀原则
 9 最左前缀原则：使用联合索引(id,name,age)查询数据,判断条件需遵循最左原则，根据id查询匹配行，否则索引失效。
12 
13 3、字段类型不一致索引失效
15 SELECT * FROM `user` WHERE height= 175; height为varchar类型导致索引失效，尤其多张表时注意。
18 
19 4、函数导致索引失效
21 SELECT * FROM `user` WHERE DATE(create_time) = '2020-09-03';
23 create_time字段设置索引，那就无法使用函数，否则索引失效。
24
27 5、运算符导致索引失效
29 如果你对列进行了（+，-，*，/，!）, 那么都将不会走索引。
31 SELECT * FROM `user` WHERE age - 1 = 20;
34 
35 6、or引起索引失效
37 SELECT * FROM `user` WHERE `name` = '张三' OR height = '175';
39 OR导致索引是在特定情况下的，并不是所有的OR都是使索引失效，如果OR连接的是同一个字段，那么索引不会失效，反之索引失效。

43 7、模糊查询导致索引失效
45 SELECT * FROM `user` WHERE `name` LIKE '%冰';
47 模糊搜索如果你前缀也进行模糊搜索，那么不会走索引。
48 
51 8、NOT IN、NOT EXISTS导致索引失效
53 SELECT s.* FROM `user` s WHERE NOT EXISTS (SELECT * FROM `user` u WHERE u.name = s.`name` AND u.`name` = '冰峰')
55 SELECT * FROM `user` WHERE `name` NOT IN ('冰峰');
57 这两种用法，也将使索引失效。但是NOT IN 还是走索引的，千万不要误解为 IN 全部是不走索引的。
58 
61 9、IS NULL不走索引，IS NOT NULL走索引
63 SELECT * FROM `user` WHERE address IS NULL
65 不走索引。
66 
69 SELECT * FROM `user` WHERE address IS NOT NULL;
71 走索引。

索引的底层数据结构？

　　索引可选的底层数据结构包括：-二叉树 -红黑树 -hash -B Tree但mysql索引的底层用的并不是二叉树和红黑树。因为二叉树和红黑树在某些场景下都会暴漏一些缺陷。

首先，二叉树在某些场景下会退化成链表，而链表的查找需要从头部开始遍历，而这就失去了加索引的意义。不使用红黑树的原因：红黑树作为底层数据结构在面对这些表数据动辄数百万数千万的场景时，会导致索引树的层数很高。索引从根节点开始查找，而如果我们需要查找的数据在底层的叶子节点上，那么树的高度是多少就要进行多少次查找，数据存在磁盘上，访问需要进行磁盘的IO，这会导致效率过低。而B+树由B树和索引顺序访问方法演化而来，它是为磁盘或其他直接存取辅助设备设计的一种平衡查找树，在B+树中，索引记录节点都是按照值的大小顺序存放在同一层的叶子节点，各叶子节点通过指针进行链接。

B+树索引在数据库中的一个特点就是高扇出性，例如在InnoDB存储引擎中，每个页的大小为16KB。在数据库中你，B+树的高度一般都在2~4层，这意味着查找某一键值最多只需要2到4次IO操作，还可结束。因为现在一般的磁盘每秒至少可以做100次IO操作，2~4次的IO操作意味着查询时间只需要0.02~0.04秒。

数据库的索引结构为什么不用哈希表？

　　MySQL中的索引是B+树实现的；哈希表的查询效率的确最高，时间复杂度O(1)，但是它要求将所有数据载入内存，而数据库存储的数据量级可能会非常大，全部载入内存基本是不可能实现的；B+树可以分段加载需要的节点数据，可以在内存资源有限的前提下，极大提高查询效率。

索引怎么实现的B+树，为什么选这个数据结构呢？

　　索引本质上就是通过预排序+树形结构来加快检索的效率，而MySQL中使用InnoDB和MyISAM引擎时都使用了B+树实现索引。它是一棵平衡多路查找树，是在二叉查找树基础上的改进数据结构。在二叉查找树上查找以恶数据时，最坏情况的查找次数为树的深度，当数据量很大时，查询次数可能还是很大，造成大量的磁盘IO，从而影响查询效率；为了减少磁盘IO的次数，必须降低树的深度，因此在二叉查找树技术上将树改成了多叉加上一些限制条件，就形成了B树； B+树中所有叶子节点值的总集就是全部关键字集合；B+树为所有叶子节点增加了链接,从而实现了快速的范围查找；在B+树中,所有记录节点都是按键值的大小顺序存放在同一层的叶子节点上,由各叶子节点指针进行连接。在数据库中,B+树的高度一般都在2～4层,这也就是说查找某一键值的行记录时最多只需要2到4次 IO。这很不错,因为当前一般的机械磁盘每秒至少可以做100次IO,2～4次的IO意味着查询时间只需0.02～0.04秒。在数据库中,B+树索引还可以分为聚集索引和辅助索引,但不管是聚集索引还是辅助索引,其内部都是B+树的,即高度平衡的,叶子节点存放着所有的数据。聚集索引与辅助索引不同的是,叶子节点存放的是否是一整行的信息。

标签：name,索引,user,失效,WHERE,SELECT
来源： https://www.cnblogs.com/sunjincode/p/16348089.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9

索引