MySql 复习笔记

MySQL 复习笔记,对之前看书和视频进行总结进行分类,同时使用⭐️标记重点程度,使用😭表示遗忘程度,随着面试会逐渐更新

文章目录

1.MySQL引擎

1.1 InnoDB 和 MyISAM 的区别⭐️⭐️⭐️⭐️⭐️⭐️❤️😭

存储引擎比较InnoDBMyISAM
是否支持行级锁支持(默认为行级别)不支持(默认为表级别)
是否支持 MVCC😭😭支持(高并发问题)不支持(简单加锁)
是否支持外键支持不支持
是否支持事务😭😭支持ACID不支持(查询是原子性的)
是否是聚簇索引😭聚簇索引非聚簇索引

⼀般情况下我们选择 InnoDB 都是没有问题的,但是某些情况下你并不在乎并发能 ⼒,也不需要事务⽀持,也不在乎崩溃后的安全恢复问题的话,选择MyISAM也是⼀个不错的选 择。但是⼀般情况下,我们都是需要考虑到这些问题的。😭

2.索引原理以及数据结构

数据库索引是存放在磁盘上的,当数据量较大的时候我们不能把整个索引全部加载到内存中去,只能逐个加载每一个磁盘页,所以我们要减少 io 次数,对于树而言 io 次数就是树的高度,矮胖就是 b 树的特征之一

2.1 ⼆叉搜索树(binary serach tree)⭐️

  1. 若它的左子树不为空,则左子树上所有节点的值都小于根节点的值
  2. 若它的右子树不为空,则右子树上所有节点的值都大于根节点的值
  3. 中序遍历是递增的

2.2 平衡二叉查找树(AVL)⭐️⭐️

  1. 具备二叉排序树的所有性质;

  2. 左子树和右子树深度差的绝对值不超过1;

2.3 B 树(B-树)⭐️

截屏2021-04-25 10.24.16
  1. 类似普通的平衡二叉树,不同的一点是B-树允许每个节点有更多的子节点
  • 数据索引和 data 在一个节点中,分别是 key 和 value
  • 数据索引从左到右递增且不重复

2.4 B+树⭐️⭐️⭐️⭐️⭐️⭐️❤️

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KLPdu5ae-1631847022028)(/Users/yazhouheilong/Library/Application Support/typora-user-images/截屏2021-04-25 10.34.52.png)]

  • 所有的 data 都存放在叶子节点
  • 叶子节点用指针连接,提高访问性能😭😭

2.6 B +树相比 B树的优势⭐️⭐️⭐️⭐️

  • B+树查询效率更加稳定:每次查询都需要遍历到根节点,查询路径相同,查询效率相当
  • B+树空间利用率更高减少 IO 次数:一个节点一般设置为一个页的大小,一页linux一般是4kb,一次io载入一个节点,B+树的中间节点不保存数据,是纯索引,但是B树的中间节点是保存数据和索引的,相对来说,B+树磁盘页能容纳更多节点元素,更“矮胖”
  • 范围查询效率更高: B+树所有的Data域在叶子节点,并且所有叶子节点之间都有一个链指针。 这样遍历叶子节点就能获得全部数据,这样就能进行区间访问啦。在数据库中基于范围的查询是非常频繁的,而B树不支持这样的遍历操作。

2.7 B+ 树与红黑树比较⭐️⭐️

  • B+树更加矮胖,比红黑树,也就是IO 次数更少

  • 磁盘访问原理,节点越大越好:操作系统一般将内存和磁盘分割成固定大小的块,每一块称为一页,内存与磁盘以页为单位交换数据数据库系统将索引的一个节点的大小设置为页的大小,使得一次 I/O 就能完全载入一个节点。如果数据不在同一个磁盘块上,那么通常需要移动制动手臂进行寻道,而制动手臂因为其物理结构导致了移动效率低下,从而增加磁盘数据读取时间。B+ 树相对于红黑树有更低的树高,进行寻道的次数与树高成正比(说明它的节点越小),在同一个磁盘块上进行访问只需要很短的磁盘旋转时间,所以 B+ 树更适合磁盘数据的读取。

  • 磁盘预读原理:为了减少磁盘 I/O 操作,磁盘往往不是严格按需读取,而是每次都会预读。预读过程中,磁盘进行顺序读取,顺序读取不需要进行磁盘寻道,并且只需要很短的磁盘旋转时间,速度会非常快。并且可以利用预读特性,相邻的节点也能够被预先载入。

2. 8 B+ 树存储怎么确定高度?

log(N/K)(N 代表数据的行数目,K 代表一个索引内部的节点的个数)

K = PageSize(操作系统页的整数倍)/(keySize + pointerSize) (分别代表索引的大小和指针的大小如果是 b数的话要再加上一个 datasize)

2.10 平衡二叉树和红黑树

AVL红黑树
平衡绝对平衡(左右字数高度差<=1)弱平衡,没有一条路径会超过别的路径两倍
性质3条四条
适用场景插入删除不频繁,对查找要求较高(只要不平衡就会去旋转达到平衡)插入删除较多的场景用红黑树,TreeMap

2.5 查询索引为 col = 30 的例子⭐️

  • 数据库索引都存储在磁盘上,但是如果数据量较大就不能一下子加载到内存中需要逐个加载
  • 首先load 到内存中,在内存中查找30,二分查找定位到上图的灰色部分,存放的是25 - 30磁盘的地址,继续将这个节点加载到内存中去
  • 一直向下查询到叶子结点,获取到数据

3.MySQL优化⭐️⭐️❤️

3.4 慢查询如何优化⭐️⭐️⭐️⭐️

1.根据慢日志定位慢查询sql,log-slow-queries 选项开启慢查询日志。通过 long_query_time 选项来设置时间值,当我们找到慢查询语句时候一般使用explain分析

3.2 使用 Explain 进行分析😭😭❤️

Explain用来分析 SELECT 查询语句,开发人员可以通过分析 Explain 结果来优化查询语句。

  • key : 使用的索引,如果为null,判断是否建立索引,或者索引是否失效

  • possible_keys列:可能使用到的索引

  • rows : 扫描的行数

  • select_type : 查询类型,有简单查询、联合查询、子查询等

  • type:

    system > const > eq_ref > ref > range > index > ALL,一般来说,得保证查询达到range级别,最好达到ref

    system和const:常量级别,一般达不到

    eq_ref:唯一索引,一般是主键扫描只有一条记录,查ceo

    ref:非唯一索引,匹配某个值的所有行,只用到索引的最左前缀或索引不是主键或唯一索引

    range:范围查询,用到了索引,开始于某个点结束于某个点,比如用到between 和in

    all:全表扫描没有用到索引,select * from table 此时需要建立索引

3.2索引失效?

  1. like 以%开头,索引无效;当like前缀没有%,后缀有%时,索引有效。
  2. or语句前后没有同时使用索引。当or左右查询字段只有一个是索引,该索引失效,只有当or左右查询字段均为索引时,才会生效
  3. 在索引字段上使用not,<>,!=。不等于操作符是永远不会用到索引的,
  4. 对索引字段进行计算操作、字段上使用函数。(索引为 emp(ename,empno,sal))
  5. 索引遇到范围查询(>、<、between、like)就会停止匹配。

3.2.1 联合索引失效的情况😭

(1)    select * from myTest  where a=3 and b=5 and c=4;   ----  abc顺序
abc三个索引都在where条件里面用到了,而且都发挥了作用


(2)    select * from myTest  where  c=4 and b=6 and a=3;
where里面的条件顺序在查询之前会被mysql自动优化,效果跟上一句一样


(3)    select * from myTest  where a=3 and c=7;
a用到索引,b没有用,所以c是没有用到索引效果的


(4)    select * from myTest  where a=3 and b>7 and c=3;     ---- b范围值,断点,阻塞了c的索引
a用到了,b也用到了,c没有用到,这个地方b是范围值,也算断点,只不过自身用到了索引


(5)    select * from myTest  where b=3 and c=4;   --- 联合索引必须按照顺序使用,并且需要全部使用
因为a索引没有使用,所以这里 bc都没有用上索引效果


(6)    select * from myTest  where a>4 and b=7 and c=9;
a用到了  b没有使用,c没有使用

group by c1 | order by c1,由于没有where的铺垫,不使用任何索引

where c1 = '1' group | order by c2,使用c1,c2索引

where c1 = '1' group | order by c3,只使用c1索引

where c1 > '1' group | order by c2,前面也说了,范围搜索会断掉连接,所以也只会使用c1索引

加入group by之后对原来的索引没有影响,但是必须要使用where

3.3 建立索引?

什么时候建立索引?⭐️

频繁查询,更新不频繁,重复较少的字段应该创建索引适合创建索引,索引其实就是对数据进行排序方便查找

小表的话直接全表扫描比较快,如果中到大型的表可以建立索引

  1. 建立聚集索引:就是按照每张表的主键构造一棵B+树,同时叶子节点中存放的即为整张表的行记录数据,也将聚集索引的叶子节点称为数据页

  2. 建立联合索引:联合索引是指对表上的多个列进行索引.(在需要使用多个列作为条件进行查询时,使用多列索引比使用多个单列索引性能更好)从本质上来说,联合索引也是一棵B+树,不同的是联合索引的键值的数量不是1,而是大于等于2。建立组合索引一定要考虑最左前缀原则,如果索引了多例,要遵守最左前缀法则。指的是查询从索引的最左前列开始并且不跳过索引中的列

  3. 前缀索引:当索引是很长的字符序列时,这个索引将会很占内存,而且会很慢,这时候就会用到前缀索引了。所谓的前缀索引就是**取索引的前面几个字母作为索引

3.5 优化返回的参数

只返回必要的列:最好不要使用 SELECT * 语句。

只返回必要的行:使用 LIMIT 语句来限制返回的数据。

4.MysQL 事务

4.1 数据库 ACID 特性⭐️

事务指的是满足 ACID 特性的一组操作,可以通过 Commit 提交一个事务,也可以使用 Rollback 进行回滚。在mysql中,一般我们用begin,rollback,commit来使用,在我的项目中就用到过

  1. 原子性Atomicity) : 事务是最小的执行单位,不允许分割。事务的原子性确保动作要么全部完成,要么完全不起作用;
  2. 一致性Consistency): 执行事务前后,数据保持一致,**例如转账业务中,无论事务是否成功,转账者和收款人的总额应该是不变的;**😭
  3. 隔离性Isolation): 并发访问数据库时,一个用户的事务不被其他事务所干扰,**各并发事务之间数据库是独立的;**😭
  4. 持久性Durabilily): 一个事务被提交之后。它对数据库中数据的改变是持久的,即使数据库发生故障也不应该对其有任何影响。

4.2 并发事务有哪些问题⭐️

在并发环境下,事务的隔离性很难保证,因此会出现很多并发一致性问题。

  • 脏读:当前事务可以读到另外事务未提交的数据。T1 修改一个数据但未提交,T2 随后读取这个数据。如果 T1 撤销了这次修改,那么 T2 读取的数据是脏数据。(读到未提交)
  • 不可重复读:在这一事务还未结束前,另一事务也访问了该同一数据集合并做了修改,由于第二个事务的修改,第一次事务的两次读取的数据可能不一致。T2读取一个数据,T1 对该数据做了修改。如果 T2 再次读取这个数据,此时读取的结果和第一次读取的结果不同。(读修改的数据)
  • 幻读:幻读本质上也属于不可重复读的情况,T1 读取某个范围的数据,T2 在这个范围内插入新的数据,T1 再次读取这个范围的数据,此时读取的结果和和第一次读取的结果不同。(读新增数据)

答题思路:都使用 A 事务和 B 事务来描述

如何解决?封锁操作需要用户自己控制,相当复杂。数据库管理系统提供了事务的隔离级别,让用户以一种更轻松的方式处理并发一致性问题。

4.3 不可重复读和幻读的区别以及解决的办法⭐️5️⃣❤️

  • 幻读是新增,不可重复读是修改或者删除,对于幻读必须要加表级锁,而对于不可重复读只需要加行锁即可

4.4 四大隔离级别⭐️⭐️⭐️❤️❤️😭

READ-UNCOMMITTED(读取未提交): 最低的隔离级别,允许读取尚未提交的数据变更, 可能会导致脏读、幻读或不可重复读。

READ-COMMITTED(读取已提交): 允许读取并发事务已经提交的数据,可以阻⽌脏读,但 是幻读或不可重复读仍有可能发⽣。

REPEATABLE-READ(可重复读): 对同⼀字段的多次读取结果都是⼀致的,除⾮数据是被 本身事务⾃⼰所修改,可以阻⽌脏读和不可重复读,但幻读仍有可能发⽣。

SERIALIZABLE(可串⾏化): 最⾼的隔离级别,完全服从ACID的隔离级别。所有的事务依次逐个执⾏,这样事务之间就完全不可能产⽣⼲扰,也就是说,该级别可以防⽌脏读、不可 重复读以及幻读。

隔离级别😭脏读不可重复读幻读
读未提交✔️✔️✔️
读已提交✖️✔️✔️
可重复读✖️✖️✔️
可串行化✖️✖️✖️

4.5 mysql 默认隔离级别

可重复读

5.MySQL 锁和 MVCC

5.1 封锁的粒度(读锁,写锁)

MySQL 中提供了两种封锁粒度:行级锁以及表级锁。

  • 应该尽量只锁定需要修改的那部分数据,而不是所有的资源。锁定的数据量越少,发生锁争夺的可能性就越小

  • 但是加锁需要消耗资源,锁的各种操作(包括获取锁、释放锁、以及检查锁状态)都会增加系统开销。因此封锁粒度越小,系统开销就越大

  • 在选择封锁粒度时,需要在锁开销和并发程度之间做一个权衡

5.2 MVCC 主要存储结构和实现过程⭐️⭐️❤️ ❤️😭😭

5.2.1 当前读和快照读

当前读:在读的时候加锁属于当前读,也就是读的时候不可以写,读取的是最新的数据

  • select ... lock in share mode
  • select ... for update

快照读

  • 如果读取的行正在执行 DELETEUPDATE 操作,这时读取操作不会去等待行上锁的释放。相反地,InnoDB 存储引擎会去读取行的一个快照数据,对于这种读取历史数据的方式,我们叫它快照读 (snapshot read)

5.2.2 MVCC实现过程

多版本并发控制(Multi-Version Concurrency Control, MVCC)是 MySQL 的 InnoDB 存储引擎实现隔离级别的一种具体方式,用于实现提交读和可重复读这两种隔离级别。而未提交读隔离级别总是读取最新的数据行,要求很低,无需使用 MVCC。可串行化隔离级别需要对所有读取的行都加锁,单纯使用 MVCC 无法实现。

1.隐藏的列

事务id(严格递增)和一个回滚指针(用于配合undo日志,指向上一个旧版本)

2.Undo日志

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-t0FDDvWH-1631847022029)(/Users/yazhouheilong/Library/Application Support/typora-user-images/截屏2021-08-13 19.34.12.png)]

MVCC 的多版本指的是多个版本的快照,快照存储在 Undo 日志中,该日志通过回滚指针 ROLL_PTR 把一个数据行的所有快照连接起来。

3.read view (视图,快照读生成,用来判断哪些版本对当前事务可见)

  • max:目前出现过的最大的事务 ID+1,即下一个将被分配的事务 ID。大于这个 ID 的数据版本均不可见
  • min:活跃事务列表 m_ids 中最小的事务 ID,如果 m_ids 为空,则 m_up_limit_idm_low_limit_id。小于这个 ID 的数据版本均可见
  • list:Read View 创建时其他未提交的活跃事务 ID 列表。创建 Read View时,将当前未提交事务 ID 记录下来,后续即使它们修改了记录行的值,对于当前事务也是不可见的。m_ids 不包括当前事务自己和已提交的事务(正在内存中)

4.判断操作

  1. 如果记录 ID < min,那么表明这条语句在当前事务创建快照之前就提交了,所以该记录行的值对当前事务是可见的
  2. 如果 ID >= max,那么表明最新修改该行的事务(DB_TRX_ID)在当前事务创建快照之后才修改该行,所以该记录行的值对当前事务不可见。跳到步骤 5😭
  3. 如果 min <= ID < max,表明最新修改该行的事务(ID)在当前事务创建快照的时候可能处于“未提交或者“已提交”;所以就要对活跃事务列表 进行查找(源码中是用的二分查找,因为是有序的)
    • 如果在活跃事务列表中能找到ID,表明不可见
    • 在活跃事务列表中找不到记录行对当前事务可见
  4. 继续通过这条语句的回滚指针所指向的 undo log 取出快照记录,用快照记录的 ID 跳到步骤 1 重新开始判断,直到找到满足的快照版本或返回空

5.2.3 RC 和 RR 隔离级别下 MVCC 的差异

  • 在 RC 隔离级别下的 每次select 查询前都生成一个Read View (m_ids 列表),我们想由于比较的对象不同所以两次读到的可能就不一样,所以可能出现不可重复读的错误
  • 在 RR 隔离级别下只在事务开始后 第一次select 数据前生成一个Read View(m_ids 列表),比较的对象一致所以可以实现可重复读

5.2.4MVCC➕Next-key-Lock 防止幻读😭

1、执行普通 select,此时会以 MVCC 快照读的方式读取数据

在快照读的情况下,RR 隔离级别只会在事务开启后的第一次查询生成 Read View ,并使用至事务提交。所以在生成 Read View 之后其它事务所做的更新、插入记录版本对当前事务并不可见,实现了可重复读和防止快照读下的 “幻读”

2、执行 select…for update/lock in share mode、insert、update、delete 等当前读

在当前读下,读取的都是最新的数据,如果其它事务有插入新的记录,并且刚好在当前事务查询范围内,就会产生幻读!InnoDB 使用 Next-key Lock 来防止这种情况。当执行当前读时,会锁定读取到的记录的同时,锁定它们的间隙(一个行锁(record lock)+范围锁(gap lock)),防止其它事务在查询范围内插入数据。只要我不让你插入,就不会发生幻读

注意行锁,和间隙锁锁的是索引(如果没有索引,主键会创建聚簇索引),而不是记录

5.3MySQL常见的锁⭐️😭

5.3.1 MySQL 读写锁(排他锁,共享锁)

写锁(排他锁):当前写操作没有完成前,会阻断其他写锁和读锁

读锁(共享锁):针对同一份数据,多个读取操作可以同时进行,不互相影响

5.3.2 MySQL 行锁 表锁😭

  • 表锁:开销小,加锁快,不会出现死锁。锁粒度大,发生锁冲突的概率最高,并发量最低。
  • 行锁:开销大,加锁慢,会出现死锁😭。锁粒度小,发生锁冲突的概率小,并发度最高。

5.3.3 MySQL乐观锁 悲观锁

悲观锁:行锁和表锁的实现,总是假设最坏的情况,认为每次取数据时都认为其他线程会修改,所以都会加(悲观)锁。一旦加锁,不同线程同时执行时,只能有一个线程执行,其他的线程在入口处等待,直到锁被释放。悲观锁的应用

乐观锁:使用版本号,当我们提交更新的话,如果数据库对应的记录的版本信息和之前获取信息的版本号一致,那么更新,否则认为时过期的数据

5.3.3.1 如何实现 悲观锁?⭐️

使用select for update …commit

5.3.4 意向锁😭

​ 在存在行级锁和表级锁的情况下,事务 T 想要对表 A 加 X 锁,就需要先检测是否有其它事务对表 A 或者表 A 中的任意一行加了锁,那么就需要对表 A 的每一行都检测一次,这是非常耗时的。因此引入了意向锁

  • 一个事务在获得某个数据行对象的 S 锁之前,必须先获得表的 IS 锁或者更强的锁;
  • 一个事务在获得某个数据行对象的 X 锁之前,必须先获得表的 IX 锁。

通过引入意向锁,事务 T 想要对表 A 加 X 锁,只需要先检测是否有其它事务对表 A 加了 X/IX/S/IS 锁,如果加了就表示有其它事务正在使用这个表或者表中某一行的锁,因此事务 T 加 X 锁失败。

6 MySQL 日志

6.1 MySQL 日志有哪些😭

错误日志(error log):记录一些错误信息

二进制日志(bin log):二进制日志用于以二进制格式来记录数据库所有变化的操作,实现数据恢复、主从复制功能。

慢查询日志(slow log):记录运行超时的语句,或者没有使用索引的语句😭

回滚日志(undo log):mvcc中的历史版本数据,保证事务原子性

重做日志(redo log):比如MySQL实例挂了或宕机了,重启时,InnoDB存储引擎会使用redo log`恢复数据,保证数据的持久性与完整性

7 切分

7.1 水平切分和垂直切分

水平切分又称为 Sharding,它是将同一个表中的记录拆分到多个结构相同的表中

垂直切分是将一张表按列切分成多个表,通常是按照列的关系密集程度进行切分,也可以利用垂直切分将经常被使用的列和不经常被使用的列切分到不同的表中。

8.mysql实际操作

8.1 mysql分页查询怎么实现⭐️

查询第5000条数据那一页

select * from table limit (start-1)*limit,limit;

优化:首先使用主键作为偏移,然后查询接下来的页数

select * from table where demo_id > (pageNo-1)*pageSize limit pageSize;

9.索引的使用😭

9.1 索引创建删除的方法😭

1. 主键索引:创建表时自动创建    { 聚集索引:一个表中只有一个聚集索引 }

2. 唯一索引:CREATE UNIQUE INDEX unique_index_warn[索引名称] ON cas_alarm[表名] (warn_id[列名])     

3. 普通索引:CREATE INDEX index_saas_report_service_status[索引名称] ON saas_report_service_status[表名] (service_status[列名]);   

4. 组合索引:CREATE INDEX index_saas_report_service_type[索引名称] ON saas_report_service_status[表名] (service_type[列名],service_status[列名],sort_value[列名]);


删除索引
drop index index_name on table_name ;

9.2 什么是索引,有什么作用

索引的作用就相当于目录的作用。打个比方: 我们在查字典的时候,如果没有目录,那我们就只能一页一页的去找我们需要查的那个字,速度很慢。如果有目录了,我们只需要先去目录里查找字的位置,然后直接翻到那一页就行了。

9.3 索引的优缺点

优点:

  • 使用索引可以大大加快 数据的检索速度(大大减少检索的数据量), 这也是创建索引的最主要的原因。

缺点

  • 创建索引和维护索引需要耗费许多时间。当对表中的数据进行增删改的时候,如果数据有索引,那么索引也需要动态的修改,会降低 SQL 执行效率。
  • 索引需要使用物理文件存储,也会耗费一定空间。

9.4索引的分类

  • 主键索引

    数据表的主键列使用的就是主键索引。一张数据表有只能有一个主键,并且主键不能为 null,不能重复。

  • 二级索引

    二级索引又称为辅助索引,是因为二级索引的叶子节点存储的数据是主键。也就是说,通过二级索引,可以定位主键的位置。

    唯一索引,普通索引,前缀索引等索引属于二级索引。

    PS:不懂的同学可以暂存疑,慢慢往下看,后面会有答案的,也可以自行搜索。

  1. 唯一索引(Unique Key) :唯一索引也是一种约束。唯一索引的属性列不能出现重复的数据,但是允许数据为 NULL,一张表允许创建多个唯一索引。 建立唯一索引的目的大部分时候都是为了该属性列的数据的唯一性,而不是为了查询效率。
  2. 普通索引(Index)普通索引的唯一作用就是为了快速查询数据,一张表允许创建多个普通索引,并允许数据重复和 NULL。
  3. 前缀索引(Prefix) :前缀索引只适用于字符串类型的数据。前缀索引是对文本的前几个字符创建索引,相比普通索引建立的数据更小, 因为只取前几个字符。
  4. 建立联合索引:联合索引是指对表上的多个列进行索引.(在需要使用多个列作为条件进行查询时,使用多列索引比使用多个单列索引性能更好)从本质上来说,联合索引也是一棵B+树,不同的是联合索引的键值的数量不是1,而是大于等于2。建立组合索引一定要考虑最左前缀原则,如果索引了多例,要遵守最左前缀法则。指的是查询从索引的最左前列开始并且不跳过索引中的列。联合索引要把选择性高的放在前面在一个公司里以age 和gender为索引,显然age要放在前面,因为性别就两种选择男或女,选择性不如age。

9.5 聚集索引和非聚集索引

9.5.1聚集索引

聚集索引即索引结构和数据一起存放的索引。主键索引属于聚集索引。

9.5.2 非聚集索引

非聚集索引即索引结构和数据分开存放的索引,二级索引属于非聚集索引

9.5.1聚集索引(InnoDB)和非聚集索引(MyISAM)区别⭐️⭐️😭

  • 都是B+树,非叶子节点存放的是key,叶子节点存放 key 和 data。
  • 聚集索引叶子节点存放的 data 是**数据页,一次查找,非聚集索引叶子节点不存储数据,存放的是数据行的地址,相当于需要二次查找,需要回表
  • innoDb :主键使用的是聚簇索引,二级索引是非聚簇索引,MYISAM的主键和二级索引都是非聚簇索引

9.5.4 非聚簇索引一定回表嘛?

非聚集索引不一定回表查询,覆盖索引就是查询的值正好是select后面想要的值

9.5.5 覆盖索引

覆盖索引即需要查询的字段正好是索引的字段,那么直接根据该索引,就可以查到数据了, 而无需回表查询。

 SELECT name FROM table WHERE name='guang19';
SELECT id FROM table WHERE id=1;
  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值