Phase2 Day20 事务索引

文章目录

事务
- 1.概念
- 2. 基本操作
- 3.事务的性质
- - 并发执行时可能产生的问题
- 4.隔离级别
InnoDB索引存储引擎
- 1.MySQL架构
- 2.存储引擎
- - 2.1 MyISAM
  - 2.2 InnoDB
  - 2.3Memory
- 3. 磁盘IO原理
- 4.InnoDB数据页格式
索引
- 1.B树索引
- 2.B+树索引
- 3. 索引的优缺点
- 4.InnoDB索引介绍
- - InnoDB聚集索引
  - InnoDB非聚集索引（辅助索引）
  - 聚集索引和辅助索引对比
- 5.索引操作
- 6.回表
- 7. Explain 查看计划信息
- 8.联合索引
- 9.覆盖索引
- 10.创建索引的时机
- 11.索引失效的情况

事务

1.概念

从用户的观点来看，数据库中一些操作的集合被认为是一个独立单元，比如转账操作。这些操作要么全部发生，要么由于出错而全不发生。
构成单一逻辑工作单元的操作集合，我们称为事务 (transaction)。即使有故障，数据库系统也必须保证事务的正确执行——要么执行整个事务，要么属于该事务的操作一个也不执行。

2. 基本操作

START TRANSACTION / BEGIN：开启一个事务，标记事务的起点
COMMIT：提交事务，表示事务成功被执行。
ROLL BACK：回滚事务，回滚到初始状态或者回滚点。
SAVEPOINT：回滚点
RELEASE SAVEPOINT：删除回滚点
SET TRANSACTION: 设置隔离级别

注：

START TRANSACTION 标志事务的开始，在 MySQL 中可以用set @@autocommit=0;替代。
结束事务的情况只有两种：
a. COMMIT：表示事务成功被执行，结束事务。
b. 发生故障：结束事务, 不管有没有设置回滚点，都会回到事务开启前的状态。
ROLLBACK：不表示发生故障, 它也是一个数据库操作，属于事务的一部分。表示回滚事务，回滚到事务开启前的状态，或者中间的某个回滚点。要想 rollback 生效，必须要 commit。

3.事务的性质

原子性（Atomicity）原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。无论是操作系统崩溃，还是计算机停止运行，这项要求都要成立。
一致性（Consistency）事务作为一个原子性操作，它从一个一致性的数据库状态开始运行，事务结束时，数据库的状态必须再次是一致的。
隔离性（Isolation）尽管多个事务可能并发执行，但系统保证，对于任何一对事务Ti和Tj ,在Ti看来， Tj要么在Ti开始之间已经完成，要么在Ti完成之后才开始执行。因此，每个事务都感觉不到系统中有其他事务在并发地执行。
持久性（Durability）一个事务成功完成后，它对数据库的改变必须是永久的，即使出现系统故障

并发执行时可能产生的问题

脏写： 脏写是指当多个事务并发写同一数据时，先执行的事务所写的数据会被后写的数据覆盖。脏写会导致更新丢失。就好像先提交的事务根本没有执行一样

脏读： 如果一个事务A向数据库写数据，但该事务还没提交或终止，另一个事务B就看到了事务A写入数据库的数据，这个现象我们称为脏读

不可重复读： 一个事务有对同一个数据项的多次读取，但是在某前后两次读取之间，另一个事务更新该数据项，并且提交了。在后一次读取时，感知到了提交的更新。这个现象我们称为不可重复读

幻读： 一个事务需要进行前后两次统计，在这两次统计期间，另一个事务插入了新的符合统计条件的记录，并且提交了。导致前后两次统计的数据不一致。这种现象，我们称之为幻读

4.隔离级别

读未提交（read uncommitted）允许读取未提交的数据。
读已提交（read committed）只允许读取已提交数据，但不要求可重复读。比如，在事务两次读取一个数据项期间，另一个事务更新了该数据项并提交。
可重复读（repeatable read）只允许读取已提交数据，而且在一个事务两次读取一个数据项期间，其他事务不得更新该数据。但该事务不要求与其他事务可串行化。比如，在两次统计查询中，另一个事务可以插入一些记录，当这些记录中有符合查询条件的，那么就会产生幻读。
可串行化（serializable）看起来事务就好像是串行执行的一样。一个事务结束后，另一个事务才开始执行

# 查看隔离级别
select @@tx_isolation; # 当前会话的隔离级别
select @@session.tx_isolation;  # 当前会话的隔离级别
select @@global.tx_isolation; # 系统的隔离级别.# 设置隔离级别
set transaction isolation level read uncommitted; # 设置下一个事务的隔离级别
set session transaction isolation level read uncommitted; # 设置会话的隔离级别
set global transaction isolation level read uncommitted; # 设置系统的隔离级别 # read uncommitted
use mydb1;
delete from boys;
set session transaction isolation level read uncommitted;
insert into boys values (1, '张三', null);

注：

MySQL 支持4种隔离级别，默认为 RR (repeatable read);
Oracle 只支持 read committed 和 serializable 两种隔离级别，默认为 read committed

InnoDB索引存储引擎

1.MySQL架构

大体来说，MySQL可以分为 Server 层和存储引擎层
Server 层包括连接器、查询缓存、解析器、优化器和执行器等，涵盖了 MySQL 大多数核心服务功能。
存储引擎层负责数据的存储和提取。其架构模式是插件式的，支持 InnoDB、MyISAM、Mermory 等多个存储引擎

MySQL工作流程

连接器 当你在客户端输入 mysql –u $user –p $pwd 连接 mysql 的时候，接待你的就是连接器。连接器的作用就是和客户端建立连接、获取权限、维持和管理连接。若客户端长时间无响应，则会自动关闭连接（使用select @@wait_timeout; # 28800）查看最大连接时间
查询缓存 建立连接后，就可以执行select语句了。首先MySQL会去查看查询缓存，看下之前是否已经执行过这条查询语句。如果命中缓存，就直接返回。否则就扔给解析器。底层是HashMap，但不推荐使用，因为数据表一更新，查询缓存表中所有数据会失效。可通过select @@query_cache_type;查看是否开启
解析器 MySQL需要知道你想做什么，因此我们就来到了解析器。解析器会做词法分析和语法分析。词法分析主要是分析每个词的含义，语法分析会判断你写的 SQL 语句是否满足 SQL 语法。
优化器 经过解析器，MySQL就知道你想做什么了。但是在开始执行之前，还需要经过优化器的处理。优化器会优化你的SQL语句。生成最终的执行方案 (execution plan)。然后进入执行器阶段。
执行器 执行器首先会判断你对这张表有没有相应的权限。如果没有，就报错。如果有，就调用相应的存储引擎接口，执行语句。然后将结果集返回给客户端。

2.存储引擎

数据的存储和提取是由存储引擎负责的，它负责和文件系统打交道。
MySQL 的存储引擎是插件式的。不同的存储引擎支持不同的特性。
选择合适的存储引擎对应用非常重要
查看MySQL支持哪些存储引擎 SHOW ENGINES;
查看默认存储引擎 SHOW VARIABLES LIKE ‘%storage_engine%’;
查看某张表的存储引擎 SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA=‘db′ANDTABLENAME=′db' AND TABLE_NAME='db′ANDTABLENAME=′table’;

select engine from information_schema.tables
where table_schema = 'mydb1' and table_name = 'boys';

2.1 MyISAM

MySQL 5.5 之前默认的存储引擎
特点：
a. 查询速度很快
b. 支持表锁
c. 支持全文索引 d. 不支持事务
使用 MyISAM 存储表，会生成三个文件：
.frm # 存储表结构，是任何存储引擎都有的
.myd # 存放数据
.myi # 存放索引

2.2 InnoDB

MySQL 5.5 以及以后版本默认的存储引擎。没有特殊应用，Oracle官方推荐使用InnoDB 引擎### 3.磁盘IO原理
特点：
a. 支持事务
b. 支持行锁
c. 支持MVCC
d. 支持崩溃恢复
e. 支持外键一致性约束
使用 InnoDB 存储表，会生成两个文件.
.frm # 存储表结构，是任何存储引擎都有的
.ibd # 存放数据和索引
索引和数据存放在一起，这样的索引叫聚集索引

2.3Memory

特点：
a. 所有数据都存放在内存中，因此数据库重启后会丢失
b. 支持表锁
c. 支持Hash和BTree索引
d. 因为存在内存中，不能放入太大数据，不支持Blob和Text字段
Memory由于数据都放在内存中，以及支持Hash索引，它的查询速度是最快的。
一般使用 Memory 存放临时表
临时表：在单个连接中可见，当连接断开时，临时表也将不复存在

3. 磁盘IO原理

磁盘上的数据可以用一个三维地址标识: 柱面号, 盘号, 块号(磁道上的扇区)

读写数据步骤：

移动磁头到指定的柱面号，这个过程被称为定位或查找。由于是机械移动, 这部分耗时最高, 最大可达 0.1s.
根据盘面号确定从哪个磁盘读取数据
盘组开始旋转，将指定的块号移动到读/写头下，磁盘旋转的速度很快, 一般为7200rpm。旋转一圈大约需要 0.0083s.
读写数据数据通过系统总线传送到内存。一般传输一个字节大概需要 0.02us. 读写 4KB 大约需要 80us.

磁盘读取数据是以盘块(block)为单位的, 一般为4KB。位于同一盘块的所有数据会被一次性全部读取出来。磁盘IO的代价主要花费在第 1 步

4.InnoDB数据页格式

页是 InnoDB 磁盘管理的最小单位。在 InnoDB 存储引擎中, 页默认大小为16KB。可以通过参数 innodb_page_size 将页的大小设置为 4K、8K 和 16K
InnoDB 每次至少会将 1 个页的数据从磁盘读取到内存，每次至少也会将 1 个页的数据从内存写到磁盘。
在InnoDB存储引擎中，有很多种页类型。其中最重要的是数据页，也叫 B-tree Node。里面存储了索引和数据的信息

File Header 主要存储表空间相关信息
Page Header 主要存储数据页的元信息
Infimum + Supremum Records 每个数据页中有两个虚拟行记录用来限定记录的边界，infimum record 是数据页上最小的记录，supremum record 是数据页上最大的记录。
User Records 用户数据，实际存储的行记录。
Free Space 空闲空间。
Page Directory 页目录，存放了记录的相对位置。
File Trailer 位于数据页的最后，用来检测页是否完整地写入磁盘。

行记录是用链表形式组织的，最小最大记录相当于两个哨兵。
Page Directory是一个数组，里面包含很多指向记录的指针(又叫 Slot)，S0指向最小记录的链表, Sn指向最大记录的链表。S1 ~ Sn-1 的每条链的长度范围为 [4, 8]

File Header 里面有两个字段：FIL_PAGE_PREV 和 FIL_PAGE_NEXT 用来表示上一个页和下一个页，因此，页与页之间是用双链表链接的。页内的记录是由单链表从大到小依次链接的

索引

简单来说，索引的目的就是为了提高数据的查询效率，就像书的目录一样。一本800页的书，如果想在书中查找某个知识点。在不借助目录的情况下，估计得找好一会儿。同样，对于数据库的表而言，索引就是它的 ”目录”。
索引：在 MySQL 中也叫做键 (key)，是存储引擎用于快速找到记录的一种数据结构。

1.B树索引

B 树,它是一颗多路平衡查找树。我们描述一颗 B 树时需要指定它的阶数，阶数表示了一个结点最多有多少个孩子，一般用字母m表示。一颗m阶的B树定义如下：

除根结点外，每个节点的度[ceil(m/2),m]2）
根结点的度[2,m]3）
每个结点中的关键字都按照从小到大的顺序排列，每个关键字的左子树中的所有关键字都小于它，而右子树中的所有关键字都大于它
所有叶子结点都位于同一层，或者说根结点到每个叶子结点的路径长度都相同

这是一棵4阶B树，从图中我们可以看出: 索引和数据是一起存放的。假设一行记录是16B，那么一页大概可以存1000行记录。二层的B树可以存1001 * 1001行记录，三层可以存 1000 * 1000 * 1000 行记录。大大减少了树的高度，也就是减少了一次查找IO的次数

但是B树也有缺点：

一行记录的数据很多时，比如1K
范围查找

2.B+树索引

B+ 树是在B树上做了些改进。一棵 m 阶的 B+ 树定义如下：

B+树包含2种类型的结点：内部结点 (也称索引结点) 和叶子结点。根结点即可以是内部结点，也可以是叶子结点。根结点的关键字个数可以只有1个。
B+树与B树最大的不同是内部结点不保存数据，只保存关键字，所有数据 (记录) 都保存在叶子结点中
m阶B+树表示了内部结点最多有m个关键字。至少有 ceiling(m/2)个关键字
内部结点中的key都按照从小到大的顺序排列，叶子结点中的记录也按照key的大小排列
每个叶子结点都存有相邻叶子结点的指针，叶子结点依关键字大小依次链接

而且由于叶子节点是由链表按大小依次连接的 (在InnoDB 中是双链表)。范围查找的时候，也可以避免过多的IO次数

3. 索引的优缺点

好处提高数据检索的效率，降低数据库的IO成本。
a. 查找
b. 排序
c. 分组
d. 表的连接
坏处
a. 占用额外的空间。有时候索引占用的空间甚至比数据占用的空间还多。
b. 虽然索引大大提高了查询的速度，但同时也降低了更新表的速度。因为数据库不仅仅要更新数据，还要更新对应的索引信息。

索引不是越多越好！索引太多，应用程序的性能可能会受到影响; 索引太少，查询速度会变慢。我们应该建立合适的索引，找到一个平衡点

4.InnoDB索引介绍

InnoDB 支持以下三种索引：

B+ 树索引
全文索引
哈希索引（通过select @@innodb_adaptive_hash_index;开启或关闭热点索引）

InnoDB 中的 B+ 树索引又可以分为聚集索引 (clustered index) 和 辅助索引 (secondary index)。它们之间的不同在于，聚集索引的叶子节点存储的是一整行记录的信息，而辅助索引的叶子节点只存放部分信息 (关键字和主键)

InnoDB聚集索引

聚集索引表记录的排列顺序和索引的排列顺序一致，所以查询效率快，只要找到第一个索引值记录，其余就连续性的记录在物理也一样连续存放。聚集索引对应的缺点就是修改慢，因为为了保证表中记录的物理和索引顺序一致，在记录插入的时候，会对数据页重新排序。
聚集索引就是按照每张表的主键构建一棵 B+ 树，同时叶子节点中存放的是整张表的行记录数据。
聚集索引的叶子节点其实就是我们前面讲过的数据页。
在InnoDB中, 记录只能存放在聚集索引中，所以每张表有且只有一个聚集索引。在大多数情况下，查询优化器倾向于采用聚集索引
聚集索引对应的缺点就是修改慢，因为为了保证表中记录的物理和索引顺序一致，在记录插入的时候，会对数据页重新排序。

如果一张表中没有主键，该怎么办呢？
　找第一个定义的唯一键去构建聚集索引。
如果没有定义唯一键，又该怎么办呢？
　Innodb会提供隐藏的主键，根据隐藏的主键去构建聚集索引

InnoDB非聚集索引（辅助索引）

对于辅助索引，叶子节点不包含行记录的全部数据，叶子节点除了包含辅助键以外，还包含聚集索引的键，也就是主键的信息。。非聚集索引层次多，不会造成数据重排。
辅助索引的存在并不影响数据在聚集索引中的组织，因此每张表可以有多个辅助索引。

聚集索引和辅助索引对比

索引是通过树的形式进行描述的，我们可以这样区分聚集与非聚集索引的区别：聚集索引的叶节点就是最终的数据节点，而非聚集索引的叶节只存储辅助键和主键。
在查询的时候，聚集索引可以直接获取到对应的全部列的数据，而非聚集索引在索引没有覆盖到对应的列的时候需要进行二次查询。因此在查询方面，聚集索引的速度往往会更占优势，尤其是要查询键值在某个区间上的时候
非聚集索引和聚集索引插入对比
由于聚集索引的物理顺序上的特殊性，因此如果再在上面创建索引的时候会根据索引列的排序移动全部数据行上面的顺序，会非常地耗费时间以及性能

5.索引操作

创建索引：

创建表的时候指定。会自动给 primary key 和 unique 创建索引。
CREATE [UNIQUE] INDEX 索引名 ON 表名(字段列表);
ALTER 表名 ADD [UNIQUE] INDEX 索引名 (字段列表);

删除索引：

DROP INDEX 索引名 ON 表名;

查看索引：

SHOW INDEX FROM 表名;

6.回表

当通过辅助索引来寻找数据的时候，InnoDB会遍历辅助索引，并通过辅助索引的叶子节点，获取主键。然后再通过聚集索引来找到一个完整的行记录。这个过程我们称之为回表

如果一个辅助索引的高度为3，聚集索引的高度为3。那么我们需要6次IO操作，才可以访问最终的数据

7. Explain 查看计划信息

查询优化器：通过计算分析系统收集的统计信息，提供它认为最优的执行计划(execution plan)—可通过explain，查看这个执行计划的信息

语法：explain + select 语句

id: 每个 select 子句的标识，可以重复。
select_type: select 语句的类型。
simple, primary, union, subquery, derived。
table:显示这一行的数据是关于哪张表的。
partitions: 匹配的分表。
type: 连接类型，又叫 “访问类型”。
常用类型有：ALL, index, range, ref, eq_ref, const, system, NULL (从左到右，性能越来越好)
null：不需要查表就能获取的信息（例如获取系统参数）
System：表中数据只能有一条
const：一般用于等值查询，结果最多一条，并且比较的字段是常量（前提是用到索引）
eq_rdf：一般用于等值查询，结果最多一条，但比较的字段不是常量（前提是用到索引）
ref：一般用于等值查询，结果可能有多条（索引）
range：范围查找
index：遍历辅助索引
all：遍历聚集索引
possible_keys：可以选择的索引。
key: 实际选择的索引。
key_len: 使用索引的长度 (以字节为单位)。
ref: 与索引比较的字段
rows: 大概要检索的行数
Extra: 额外信息
using filesort: MySQL中无法利用索引完成的排序操作称为 ”文件排序”，常见于排序和分组查询。
using temporary: 表示MySQL需要使用临时表来存储结果集，常见于排序和分组查询。
using filesort 和 using temporary, 这两项比较耗时, 需要特别小心

8.联合索引

联合索引是指对表的多个列进行索引。前面的讨论的都是只对表上的一个列进行索引
联合索引的创建方法和单个索引创建的方法一样，不同之处仅在于有多个索引列
先根据第一个索引排序，第一个索引相同，再根据第二个索引排序
联合叶子节点存储的是主键

优点
可能会覆盖索引，直接通过遍历索引取得数据，无需回表
根据联合索引取出数据，已经是有序的了，无需再排序。
最左前缀法则

9.覆盖索引

InnoDB 存储引擎支持覆盖索引 (covering index), 即从辅助索引中就可以得到要查询的信息，而不需要回表
使用覆盖索引的好处是，覆盖索引不包含整行记录的信息，故其大小一般情况下远小于聚集索引，因此可以减少大量的 IO 操作
覆盖索引的另一个好处在对某些统计问题会有所体现，你会发现 InnoDB 不会选择通过查询聚集索引来进行统计。原因是辅助索引小于聚集索引，这样可以减少 IO 的操作

10.创建索引的时机

适合创建索引的时机

字段数值有唯一性限制 (MySQL自动创建了索引)
频繁作为where查询条件的字段, 尤其在数据表很大的情况下
需要经常排序和分组的字段
update, delete的where条件字段
distinct 字段需要创建索引
多表连接的字段也应该创建索引

不适合创建索引的时机

如果不在 where, group by, order by 中出现的字段，就没有必要创建索引
表的记录数太少
区分度不高的字段，我们没有必要创建索引(比如: 性别)
特例：比如有个女儿国，女人数1000000，男人10. 之后我们要经常查询男人的信息，就可以创建索引
频繁更新的字段，不一定要创建索引

11.索引失效的情况

索引字段参与了计算
对索引字段使用函数
or查询（or前后有一个没有索引，索引就会失效）
模糊查询不能以%开头
is not null 和不等于不会使用索引
查找的范围太大，也会导致索引失效

实战策略

尽量使用覆盖索引, 比如尽量不要使用 select *。
尽量使用最左前缀法则
不要在索引列上做运算
范围查找尽量不要太大
尽量不要使用不等于