一、锁
是计算机协调多个进程或线程并发访问某一资源的机制，用于保护并发访问数据的一致性和有效性
1.1、全局锁
对整个数据库实例加锁，加锁后整个实例处于只读状态，后续DML的写语句，DDL语句，更新操作的事务提交都将被阻塞
使用场景：全库逻辑备份（将数据库中的数据备份成一个SQL文件保存在磁盘中
-
若执行备份过程中，还有数据的修改和插入，则备份的数据无法保证数据的一致性和完整性。
例如表订单，表库存，表订单日志，逐个备份该表的过程（备份顺序：订单->库存->日志）中依然有下单的操作，即备份了订单 但库存已经减少等操作 会导致数据库的数据不一致
-
加锁后，DML和DDL无法操作，DQL查询数据 依然可以使用
flush tables with read lock ; # 加全局锁
sudo mysqldump -h 127.0.0.1 -uroot -p123456 -d db01 > db01.sql # 数据备份 shell界面中执行
unlock tables; # 再登录到MySQL，释放锁
数据库中加全局锁，是一个比较重的操作，存在以下问题：
- 如果在主库上备份，那么在备份期间都不能执行更新
- 如果在从库上备份，那么在备份期间从库不能执行主库同步过来的二进制日志（binlog），会导致主从延迟
在InnoDB引擎中，可以在备份时加上参数 --single-transaction 参数来完成不加锁的一致性数据备份
sudo mysqldump -single-transaction -h 127.0.0.1 -uroot -p123456 -d db01 > db01.sql
1.2、表级锁
-
表锁
- 表共享读锁(read lock)
- 表独占写锁(write lock)
lock tables 表名... read/write # 加锁 unlock tables / 客户端断开连接 # 释放锁
-
元数据锁（meta data lock, MDL）
MDL加锁过程是系统自动控制，无需显式使用，在访问一张表的时候会自动加上
主要作用是维护表元数据的数据一致性，在表上有活动事务的时候，不可以对元数据进行写入操作。为了避免DML与 DDL冲突（增删改 DDL：数据库 表 表字段 ，DML：表中数据），保证读写的正确性。
元数据就是表结构，元数据锁就是维护表结构一致性的锁
- 当对一张表进行增删改查的时候 DML语句，加MDL读锁(共享)
- 当对表结构进行变 更操作的时候 DDL语句，加MDL写锁(排他)
查看元数据锁的加锁情况：
select object_type, object_schema, object_name,lock_type, lock_duration from performance_schema.metadata_locks ;
-
意向锁
若两个线程操作一张表，线程A对表加了行锁/表锁，之后 线程B要对表加表锁，线程B需要先遍历表 查看表是否已经被加行锁 或者 表锁。
为了减少类似以上，DML执行时加的行锁与后来要加的表锁冲突的现象。InnoDB引入了意向锁，使表锁不用再检查每行是否被加锁，使用意向锁减少了表锁的检查。
-
意向共享锁(IS)：由语句
select … lock in share mode添加
与表锁共享锁 (read)兼容，与表锁排他锁(write)互斥 -
意向排他锁(IX)由insert、update、delete、select…for update添加 。
与表锁共 享锁(read)及排他锁(write)都互斥，意向锁之间不会互斥
-
通过SQL查看意向锁和行锁的加锁情况：select object_schema, object_name, index_name, lock_type, lock_mode, lock_data from performance_schema.data_locks;
1.3、行级锁
行级锁每次操作锁住对应的行数据。锁定粒度最小，发生锁冲突概率最低，并发度最高。
行级锁应用在 InnoDB存储引擎中，InnoDB的数据是基于索引组织的，行锁是通过对索引上的索引项加锁来实现的，而不是对记录加的锁。对于行级锁，主要分为以下三类：
-
行锁（Record Lock )
锁定
单个行记录的锁，防止其他事务对此行进行update和delete。在 RC、RR隔离级别下都支持
-
共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同数据集的排它锁
-
排他锁（X）：允许获取排他锁的事务更新数据，阻止其他事务获得相同数据集的共享锁和排他锁
-
注意：
- 针对唯一索引进行检索时，对已存在的记录进行等值匹配时，将会自动优化为行锁
- InnoDB的行锁是针对于索引加的锁，若不通过索引条件检索数据，那么InnoDB将对表中的所有记录加锁，此时就会升级为表锁
-
间隙锁（Gap Lock）
锁定索引记录间隙（不含该记录），确保索引记录间隙不变，防止其他事 务在这个间隙进行insert，产生幻读。在RR隔离级别下都支持。
举例：
# -----------------------------------------客户端1-----------------------------------------
begin;
update usr set age = 40 where id = 5;
# 在客户端1 update了一个不存在的id=5后，加上了间隙锁 (3,8)
commit;
# -----------------------------------------客户端2-----------------------------------------
begin;
INSERT INTO usr VALUES (7,'安拉', '17799998819', 'jd1h@126.com', '城市规划', 51,'2', '0', '2001-09-15 00:00:00'); # 阻塞，被间隙锁，直到客户端1 commit
commit;
-
临键锁（Next-Key Lock）
行锁和间隙锁组合，同时锁住数据，并锁住数据前面的间隙Gap。 在RR隔离级别下支持。
默认情况下，InnoDB在 REPEATABLE READ事务隔离级别运行，InnoDB使用 next-key 锁进行搜 索和索引扫描，以防止幻读
举例：
非唯一索引，为了其它事务向间隙中插入一条记录 出现幻读现象，因此会把（3，7）的间隙锁上，把3之前的这块间隙也锁住，3这行数据也锁住
注意：
索引上的等值查询(唯一索引)，给不存在的记录加锁时, 优化为间隙锁 。
索引上的等值查询(非唯一普通索引)，向右遍历时最后一个值不满足查询>需求时，next-key lock 退化为间隙锁。
索引上的范围查询(唯一索引)–会访问到不满足条件的第一个值为止
举例：锁19这行的数据，邻键锁锁上（19，25）以及25这行记录，还有邻键锁锁上正无穷大 以及 (25,+∞) 的间隙
间隙锁锁间隙，不包含对应的数据记录，只锁定该数据记录之前的这部分间隙
邻键锁即包含当前的数据记录，也会锁定该数据记录之前的这部分间隙
间隙锁唯一目的是防止其他事务插入间隙。间隙锁可以共存，一个事务采用的间隙锁不会 阻止另一个事务在同一间隙上采用间隙锁
锁总结
按照锁的粒度进行分类：
- 全局锁：锁定数据库中的所有表（数据库备份
- 表级锁：每次操作锁住整张表
- 读锁/写锁
lock tables 表名... read/write; unlock tables; - 元数据锁 自动加 DML语句 数据的增删改查时 MDL读锁，DDL语句表结构变更 MDL写锁
- MDL读锁：
- shared_read：select, select … lock in share mode,
- shared_write：insert ,update, select … for update
- MDL写锁：alter table
- MDL读锁：
- 意向共享锁/意向排它锁 自动加
- 加意向共享锁：shared_read：select, select … lock in share mode,
- 加意向排它锁：shared_write：insert ,update, select … for update
- 读锁/写锁
- 行级锁：每次操作锁住对应的行数据。只针对索引，如果不是索引 升级成表锁
- 行锁：共享锁/排它锁
- 排它：insert,update,delete, select … for update
- 共享：select … lock in shared mode
- select 不加任何锁
- 间隙锁和邻键锁：间隙锁锁住间隙，邻键锁锁数据和间隙。
- 行锁：共享锁/排它锁
- 乐观锁/悲观锁：
- 乐观锁：查数据时不加锁，提交数据的时候检查是否有其它事务修改了同一条数据。没有修改则提交成功，否则通过undo log回滚或者重试。读多写少
- 悲观锁：查数据加行级锁或者表级锁 share … lock in shared mode; 适合读少写多
二、InnoDB引擎
2.1、逻辑存储结构
-
表空间（ibd文件），一个mysql实例可以对应多个表空间，用于存储记录、索引等数据
-
段，分为数据段、索引段、回滚段，InnoDB是索引组织表，数据段是B+树的非叶子结点，段用来管理多个区
-
区，表空间的单元结构，每个区大小为1M，默认情况下InnoDB存储引擎页大小为16K，即一个区公共有64个连续的页
-
页，是InnoDB存储引擎磁盘管理的最小单元，每个页的大小默认为16KB。为了保证页的连续性，每次InnoDB都会向磁盘申请4-5个区
-
行，InnoDB存储引擎数据是按照行进行存放的
- 记录中的每一列col1，col2，col3
- 两个隐藏列
- Trx id，最后一次操作该行的事务ID
- Roll pointer，每次对改行记录进行改动时，会把旧版本写入undo日志中，该值是指针，通过它可以找到之前没有改动的旧版本
2.2、架构——内存结构
-
Buffer Pool缓冲池
InnoDB存储引擎基于磁盘文件存储，在物理硬盘和在内存中的速度相差很大，为了尽可能弥补这两者之间的I/O效率的差值，就需要把经常使用的数据加载到缓冲池中，避免每次访问都进行非常慢的且大部分都是随机的磁盘I/O。
在InnoDB的缓冲池中不仅缓存了索引页和数据页，还包含了undo页、插入缓存、自适应哈希索引以及 InnoDB的锁信息等等。
-
Change Buffer 更改缓冲区（针对于非唯一的二级索引页）
-
在执行DML（数据 增删改）语句时，如果这些数据Page 没有在Buffer Pool中，不会直接操作磁盘，而会将数据变更存在更改缓冲区 Change Buffer 中，在未来数据被读取时，再将数据合并恢复到Buffer Pool中，再将合并后的数据以一定频率刷新到磁盘中。
意义：与聚集索引不同，二级索引通常是非唯一的，并且以相对随机的顺序插入二级索引。同样，删除和更新 可能会影响索引树中不相邻的二级索引页，如果每一次都操作磁盘，会造成大量的磁盘IO。有了 ChangeBuffer之后，我们可以在缓冲池中进行合并处理，减少磁盘IO
-
-
Adaptive Hash Index 自适应哈希索引
-
用于优化对Buffer Pool数据的查询。MySQL的innoDB引擎中虽然没有直接支持 hash索引，但是提供功能，即自适应hash索引。
hash索引对于等值匹配，一般性能高于B+树，因为hash索引一般只需要一次IO即可，而B+树可能需 要几次匹配，所以hash索引的效率要高，但hash索引又不适合做范围查询、模糊匹配等。
因此InnoDB存储引擎会监控对表上各索引页的查询，如果观察到在某条件下hash索引效率更高， 则建立hash索引，称为自适应hash索引。 自适应哈希索引无需人工干预，是系统根据情况自动完成。
-
-
Log Buffer 日志缓冲区
- Log Buffer：日志缓冲区，用来保存要写入到磁盘中的log日志数据（redo log 、undo log）， 默认大小为 16MB，日志缓冲区的日志会定期刷新到磁盘中。如果需要更新、插入或删除许多行的事务，增加日志缓冲区的大小可以节省磁盘 I/O。
- 参数：
innodb_log_buffer_size：缓冲区大小 - 参数：
innodb_flush_log_at_trx_commit：日志刷新到磁盘时机，取值主要包含以下三个：- 1:日志在每次事务提交时写入并刷新到磁盘，默认值
- 0: 每秒将日志写入并刷新到磁盘一次
- 2: 日志在每次事务提交后写入，并每秒刷新到磁盘一次
2.3、架构——磁盘结构
-
System Tablespace 系统表空间
- 是更改缓冲区Change Buffer 的存储区域。如果表在系统表空间而不是每个表文件或通用表空间中创建的，它也可能包含表和索引数据。(在MySQL5.x版本中还包含InnoDB数据字典、undolog等)
-
File-Per-Table Tablespaces
- 每张表的独立表空间，则每个表的文件表空间包含单个InnoDB表的数据和索引 ，并存储在文件系统上的单个数据文件中。 一个.ibd 对应一个表
-
General Tablespaces 通用表空间
- 需要通过 CREATE TABLESPACE 语法创建通用表空间，在创建表时，可以指定该表空间
# 创建表空间 CREATE TABLESPACE ts_name ADD DATAFILE 'file_name' ENGINE = engine_name; # 创建表时指定表空间 CREATE TABLE xxx ... TABLESPACE ts_name; #-----------举例----------- create tablespace ts_01 add datafile 'mydb01.ibd' engine = innodb; # 创建表空间成功后，后续创建表时 可以指定把表创建至该表空间里 use db1; create table t1( id int primary key auto_increment, name varchar(10)) engine = innodb tablespace ts_01;
- 需要通过 CREATE TABLESPACE 语法创建通用表空间，在创建表时，可以指定该表空间
-
Undo Tablespaces 撤销表空间
- 撤销表空间，MySQL实例在初始化时会自动创建两个默认的undo表空间（初始大小16M），用于存储 undo log日志，undo_001, undo_002
- 撤销表空间，MySQL实例在初始化时会自动创建两个默认的undo表空间（初始大小16M），用于存储 undo log日志，undo_001, undo_002
-
Temporary Tablespaces 临时会话表空间
- InnoDB 使用会话临时表空间和全局临时表空间。存储用户创建的临时表等数据。
-
Doublewrite Buffer Files 双写缓冲区
- 双写缓冲区，innoDB引擎将数据页从Buffer Pool刷新到磁盘前，先将数据页写入双写缓冲区文件中，便于系统异常时恢复数据
- 双写缓冲区，innoDB引擎将数据页从Buffer Pool刷新到磁盘前，先将数据页写入双写缓冲区文件中，便于系统异常时恢复数据
-
Redo Log 重做日志
-
用来实现事务的持久性。该日志文件由两部分组成：重做日志缓冲区（redo log buffer）（在内存结构的Log Buffer中）以及 重做日志文件（redo log），前者是在内存中，后者在磁盘中。
当事务提交之后会把所有修改信息存到该日志中，用于在刷新脏页到磁盘 发生错误时，进行数据恢复使用。以循环方式写入重做日志文件，涉及两个文件
-
内存中的数据和磁盘的数据 是怎么 写入和读取的呢？后台线程
-
Master Thread（核心后台线程）：是MySQL的一个核心后台线程，负责管理和协调其他后台线程的工作，并将缓冲池中的数据异步刷新到磁盘中，保持数据的一致性；脏页的刷新、合并插入缓存、undo页的回收
-
IO Thread（读写线程）：异步非阻塞IO 极大地提高数据库的性能，这些线程负责处理InnoDB存储引擎的IO请求，包括读取和写入磁盘上的数据。
-
Purge Thread（清理线程）：Purge Thread负责回收已完成提交事务的undo log，将其释放以供后续事务使用。
-
Page Cleaner Thread（页清理线程）：该线程负责在InnoDB存储引擎中执行脏页的刷新操作，将脏页写回磁盘，以确保数据的持久性和一致性。协助Master Thread。
2.4、事务原理
事务：一组操作的集合，要么全部成功，要么全部失败：
事务的四大特性：（ACID）原子性，一致性，隔离性，持久性
-
A：事务是不可分割的最小操作单元，要么全部成功，要么全部失败
-
C：事务完成时，必须使所有的数据都保持一致状态
-
I：数据库系统提供的隔离机制，保证事务在不受外部并发操作影响的独立环境下运行
-
D：事务一旦提交或回滚，它对数据库中的数据的改变就是永久的
事务的隔离级别：读未提交，读已提交，可重复读，串行化
-
持久性：redo log。重做日志
- 记录事务提交时，对数据页的物理修改，实现事务的持久性
- 包含两部分：重做日志缓冲（内存结构中的Log Buffer）与 磁盘的重做日志文件，提交后会把所有修改信息保存到该文件中，用于当刷新脏页到磁盘发生错误时 进行数据恢复使用
- update/delete执行：
- 先看内存的BufferPool中有没有该页，如果没有该页则通过后台线程从磁盘中把页读到Buffer Pool
- 直接操作缓冲区中的数据，该页变成脏页
- 首先把数据页的物理变化记录在内存中的RodoLogBuffer，commit 事务提交的时候，redologBuffer会直接把数据页变化刷新到磁盘当中，即ib_logfile0，ib_logfile1中
- 在某个时机 该页以一定频率刷新到磁盘中进行持久化，若此时出错，则可以通过磁盘文件中的redo_log进行数据恢复
- 若脏页顺利写入磁盘，则redolog文件就不再需要，因此每过一段时间就清理一次redo log日志，是循环性的，不是永久的
日志文件都是追加的，是顺序磁盘I/O，效率比数据在磁盘的随机存取快速的多WAL 先写日志 Write-Ahead Logging
-
原子性：undo log。回滚日志
-
用于记录被修改前的信息，作用包括两个：提供回滚 和 MVCC（多版本并发控制）
undo log 和 redo log 记录的物理日志不一样，它是逻辑日志。可以认为当delete一条记录时，undo log会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条对应相反的 update记录（执行update之前 数据长的样子）。当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚
-
Undo log 销毁：undo log在事务执行时产生，事务提交时，并不会立即删除undo log，因为这些日志可能还用于MVCC
-
Undo log 存储：undo log采用段的方式进行管理和记录，存放在段中的rollback segment 回滚段中，内部包含1024个undo log segment
-
2.5、MVCC
-
当前读：读取的是记录的
最新版本，读取时还要保证其他并发事务不能修改当前记录，会对读取的记录进行加锁。对于我们日常的操作，如：select … lock in share mode(共享锁)，select … for update、update、insert、delete(排他锁)都是一种当前读。- 客户端1使用select 语句，客户端2使用 update语句进行更新，因为当前隔离级别是可重复读，因此客户端1无法看到客户端2事务对数据的更改
- 当前读
- 客户端1使用select 语句，客户端2使用 update语句进行更新，因为当前隔离级别是可重复读，因此客户端1无法看到客户端2事务对数据的更改
-
快照读：简单的select（不加锁）就是快照读，快照读
读取的是记录数据的可见版本，有可能是历史数据， 不加锁，是非阻塞读- Read Committed 读已提交：每次select，都生成一个快照读
- Repeatable Read 可重复高读：开启事务后第一个select语句才是快照读的地方。即第一次select查询产生快照读，后面的select查询直接使用前面的快照数据
- Serializable 串行化：快照读会退化为当前读，每次读取都需要加锁
-
MVCC： Multi-Version Concurrency Control，多版本并发控制
- 维护一个数据的多个版本， 使得读写操作没有冲突，快照读 为MySQL实现MVCC提供了一个非阻塞读功能。MVCC的具体实现 依赖于数据库记录中的三个隐式字段、undo log日志、readView
MVCC实现原理：
-
记录中的隐藏字段
-
undo log日志 回滚日志
-
在insert、update、delete的时候产生的便于数据回滚的日志。
当insert的时候，产生的undo log日志只在回滚时需要，在事务提交后，可被立即删除
update、delete时，产生的undo log日志不仅在回滚时需要，在快照读时也需要，不会立即被删除
-
-
undo log 版本链
最终不同事务或相同事务对同一条记录进行修改，会导致该记录的undolog生成一条 记录版本链表。
链表的头部是最新的旧记录，链表尾部是最早的旧记录。
那么每次查询的时候，返回哪一个版本的记录呢？ReadView的作用
-
readView 读视图 决定查询读取 的记录
ReadView（读视图）是 快照读 SQL执行时MVCC提取数据的依据，记录并维护系统当前活跃的事务 （未提交的）id
- 不同的隔离级别，生成ReadView的时机不同：
-
READ COMMITTED：在事务中每一次执行快照读时生成ReadView
-
REPEATABLE READ：仅在事务中第一次执行快照读时生成ReadView，后续复用该ReadView在RR隔离级别下，只是在事务中第一次快照读时生成ReadView，后续都是复用该 ReadView，那么既然ReadView都一样， ReadView的版本链匹配规则也一样， 那么最终快照读返 回的结果也是一样的
-
- 不同的隔离级别，生成ReadView的时机不同：
因此，MVCC的实现原理就是通过 InnoDB表的隐藏字段、UndoLog 版本链、ReadView来实现的。 而MVCC + 锁，则实现了事务的隔离性。 而一致性则是由redolog 与 undolog保证
常用工具
1264
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
