Mysql海量数据存储与优化

MySQL存储引擎

存储引擎在MySQL的体系架构中位于第三层，负责MySQL中的数据的存储和提取，是与文件打交道的
子系统，它是根据MySQL提供的文件访问层抽象接口定制的一种文件访问机制，这种机制就叫作存储引
擎。
使用show engines命令，就可以查看当前数据库支持的引擎信息。
在5.5版本之前默认采用MyISAM存储引擎，从5.5开始采用InnoDB存储引擎。
InnoDB：支持事务，具有提交，回滚和崩溃恢复能力，事务安全
MyISAM：不支持事务和外键，访问速度快
Memory：利用内存创建表，访问速度非常快，因为数据在内存，而且默认使用Hash索引，但是
一旦关闭，数据就会丢失
Archive：归档类型引擎，仅能支持insert和select语句
Csv：以CSV文件进行数据存储，由于文件限制，所有列必须强制指定not null，另外CSV引擎也不
支持索引和分区，适合做数据交换的中间表
BlackHole: 黑洞，只进不出，进来消失，所有插入数据都不会保存
Federated：可以访问远端MySQL数据库中的表。一个本地表，不保存数据，访问远程表内容。
MRG_MyISAM：一组MyISAM表的组合，这些MyISAM表必须结构相同，Merge表本身没有数据，
对Merge操作可以对一组MyISAM表进行操作。
3.1 InnoDB和MyISAM对比
InnoDB和MyISAM是使用MySQL时最常用的两种引擎类型，我们重点来看下两者区别。
事务和外键
InnoDB支持事务和外键，具有安全性和完整性，适合大量insert或update操作
MyISAM不支持事务和外键，它提供高速存储和检索，适合大量的select查询操作
锁机制
InnoDB支持行级锁，锁定指定记录。基于索引来加锁实现。
MyISAM支持表级锁，锁定整张表。
索引结构
InnoDB使用聚集索引（聚簇索引），索引和记录在一起存储，既缓存索引，也缓存记录。
MyISAM使用非聚集索引（非聚簇索引），索引和记录分开。
并发处理能力
MyISAM使用表锁，会导致写操作并发率低，读之间并不阻塞，读写阻塞。
InnoDB读写阻塞可以与隔离级别有关，可以采用多版本并发控制（MVCC）来支持高并发
存储文件
InnoDB表对应两个文件，一个.frm表结构文件，一个.ibd数据文件。InnoDB表最大支持64TB；
MyISAM表对应三个文件，一个.frm表结构文件，一个MYD表数据文件，一个.MYI索引文件。从
MySQL5.0开始默认限制是256TB。
适用场景
MyISAM
不需要事务支持（不支持）
并发相对较低（锁定机制问题）
数据修改相对较少，以读为主
数据一致性要求不高
InnoDB
需要事务支持（具有较好的事务特性）
行级锁定对高并发有很好的适应能力
数据更新较为频繁的场景
数据一致性要求较高
硬件设备内存较大，可以利用InnoDB较好的缓存能力来提高内存利用率，减少磁盘IO
总结
两种引擎该如何选择？
是否需要事务？有，InnoDB
是否存在并发修改？有，InnoDB
是否追求快速查询，且数据修改少？是，MyISAM
在绝大多数情况下，推荐使用InnoDB

InnoDB存储结构
从MySQL 5.5版本开始默认使用InnoDB作为引擎，它擅长处理事务，具有自动崩溃恢复的特性，在日
常开发中使用非常广泛。下面是官方的InnoDB引擎架构图，主要分为内存结构和磁盘结构两大部分

内存结构主要包括Buffer Pool、Change Buffer、Adaptive Hash Index和Log Buffer四大组件。
Buffer Pool：缓冲池，简称BP。BP以Page页为单位，默认大小16K，BP的底层采用链表数
据结构管理Page。在InnoDB访问表记录和索引时会在Page页中缓存，以后使用可以减少磁
盘IO操作，提升效率。
Page管理机制
Page根据状态可以分为三种类型：
free page ： 空闲page，未被使用
clean page：被使用page，数据没有被修改过
dirty page：脏页，被使用page，数据被修改过，页中数据和磁盘的数据产生了不
一致
针对上述三种page类型，InnoDB通过三种链表结构来维护和管理
free list ：表示空闲缓冲区，管理free page
flush list：表示需要刷新到磁盘的缓冲区，管理dirty page，内部page按修改时间
排序。脏页即存在于flush链表，也在LRU链表中，但是两种互不影响，LRU链表负
责管理page的可用性和释放，而flush链表负责管理脏页的刷盘操作。
lru list：表示正在使用的缓冲区，管理clean page和dirty page，缓冲区以
midpoint为基点，前面链表称为new列表区，存放经常访问的数据，占63%；后
面的链表称为old列表区，存放使用较少数据，占37%。
改进型LRU算法维护
普通LRU：末尾淘汰法，新数据从链表头部加入，释放空间时从末尾淘汰
改性LRU：链表分为new和old两个部分，加入元素时并不是从表头插入，而是从中间
midpoint位置插入，如果数据很快被访问，那么page就会向new列表头部移动，如果
数据没有被访问，会逐步向old尾部移动，等待淘汰。
每当有新的page数据读取到buffer pool时，InnoDb引擎会判断是否有空闲页，是否足
够，如果有就将free page从free list列表删除，放入到LRU列表中。没有空闲页，就会
根据LRU算法淘汰LRU链表默认的页，将内存空间释放分配给新的页。
Buffer Pool配置参数
show variables like ‘%innodb_page_size%’; //查看page页大小
show variables like ‘%innodb_old%’; //查看lru list中old列表参数
show variables like ‘%innodb_buffer%’; //查看buffer pool参数
建议：将innodb_buffer_pool_size设置为总内存大小的60%-80%，
innodb_buffer_pool_instances可以设置为多个，这样可以避免缓存争夺。
Change Buffer：写缓冲区，简称CB。在进行DML操作时，如果BP没有其相应的Page数据，
并不会立刻将磁盘页加载到缓冲池，而是在CB记录缓冲变更，等未来数据被读取时，再将数
据合并恢复到BP中。
ChangeBuffer占用BufferPool空间，默认占25%，最大允许占50%，可以根据读写业务量来
进行调整。参数innodb_change_buffer_max_size;
当更新一条记录时，该记录在BufferPool存在，直接在BufferPool修改，一次内存操作。如
果该记录在BufferPool不存在（没有命中），会直接在ChangeBuffer进行一次内存操作，不
用再去磁盘查询数据，避免一次磁盘IO。当下次查询记录时，会先进性磁盘读取，然后再从
ChangeBuffer中读取信息合并，最终载入BufferPool中。
写缓冲区，仅适用于非唯一普通索引页，为什么？
如果在索引设置唯一性，在进行修改时，InnoDB必须要做唯一性校验，因此必须查询磁盘，
做一次IO操作。会直接将记录查询到BufferPool中，然后在缓冲池修改，不会在
ChangeBuffer操作。
Adaptive Hash Index：自适应哈希索引，用于优化对BP数据的查询。InnoDB存储引擎会监
控对表索引的查找，如果观察到建立哈希索引可以带来速度的提升，则建立哈希索引，所以
称之为自适应。InnoDB存储引擎会自动根据访问的频率和模式来为某些页建立哈希索引。
Log Buffer：日志缓冲区，用来保存要写入磁盘上log文件（Redo/Undo）的数据，日志缓冲
区的内容定期刷新到磁盘log文件中。日志缓冲区满时会自动将其刷新到磁盘，当遇到BLOB
或多行更新的大事务操作时，增加日志缓冲区可以节省磁盘I/O。
LogBuffer主要是用于记录InnoDB引擎日志，在DML操作时会产生Redo和Undo日志。
LogBuffer空间满了，会自动写入磁盘。可以通过将innodb_log_buffer_size参数调大，减少
磁盘IO频率
innodb_flush_log_at_trx_commit参数控制日志刷新行为，默认为1
0 ： 每隔1秒写日志文件和刷盘操作（写日志文件LogBuffer–>OS cache，刷盘OS
cache–>磁盘文件），最多丢失1秒数据
1：事务提交，立刻写日志文件和刷盘，数据不丢失，但是会频繁IO操作
2：事务提交，立刻写日志文件，每隔1秒钟进行刷盘操作

InnoDB磁盘结构
InnoDB磁盘主要包含Tablespaces，InnoDB Data Dictionary，Doublewrite Buffer、Redo Log
和Undo Logs。
表空间（Tablespaces）：用于存储表结构和数据。表空间又分为系统表空间、独立表空间、
通用表空间、临时表空间、Undo表空间等多种类型；
系统表空间（The System Tablespace）
包含InnoDB数据字典，Doublewrite Buffer，Change Buffer，Undo Logs的存储区
域。系统表空间也默认包含任何用户在系统表空间创建的表数据和索引数据。系统表空
间是一个共享的表空间因为它是被多个表共享的。该空间的数据文件通过参数
innodb_data_file_path控制，默认值是ibdata1:12M:autoextend(文件名为ibdata1、
12MB、自动扩展)。
独立表空间（File-Per-Table Tablespaces）
默认开启，独立表空间是一个单表表空间，该表创建于自己的数据文件中，而非创建于
系统表空间中。当innodb_file_per_table选项开启时，表将被创建于表空间中。否则，
innodb将被创建于系统表空间中。每个表文件表空间由一个.ibd数据文件代表，该文件
默认被创建于数据库目录中。表空间的表文件支持动态（dynamic）和压缩
（commpressed）行格式。
通用表空间（General Tablespaces）
通用表空间为通过create tablespace语法创建的共享表空间。通用表空间可以创建于
mysql数据目录外的其他表空间，其可以容纳多张表，且其支持所有的行格式。
撤销表空间（Undo Tablespaces）
撤销表空间由一个或多个包含Undo日志文件组成。在MySQL 5.7版本之前Undo占用的
是System Tablespace共享区，从5.7开始将Undo从System Tablespace分离了出来。
InnoDB使用的undo表空间由innodb_undo_tablespaces配置选项控制，默认为0。参
数值为0表示使用系统表空间ibdata1;大于0表示使用undo表空间undo_001、
undo_002等。
临时表空间（Temporary Tablespaces） CREATE TABLESPACE ts1 ADD DATAFILE ts1.ibd Engine=InnoDB; //创建表空 间ts1 CREATE TABLE t1 (c1 INT PRIMARY KEY) TABLESPACE ts1; //将表添加到ts1 表空间
分为session temporary tablespaces 和global temporary tablespace两种。session
temporary tablespaces 存储的是用户创建的临时表和磁盘内部的临时表。global
temporary tablespace储存用户临时表的回滚段（rollback segments ）。mysql服务
器正常关闭或异常终止时，临时表空间将被移除，每次启动时会被重新创建。
数据字典（InnoDB Data Dictionary）
InnoDB数据字典由内部系统表组成，这些表包含用于查找表、索引和表字段等对象的元数
据。元数据物理上位于InnoDB系统表空间中。由于历史原因，数据字典元数据在一定程度上
与InnoDB表元数据文件（.frm文件）中存储的信息重叠。
双写缓冲区（Doublewrite Buffer）
位于系统表空间，是一个存储区域。在BufferPage的page页刷新到磁盘真正的位置前，会先
将数据存在Doublewrite 缓冲区。如果在page页写入过程中出现操作系统、存储子系统或
mysqld进程崩溃，InnoDB可以在崩溃恢复期间从Doublewrite 缓冲区中找到页面的一个好
备份。在大多数情况下，默认情况下启用双写缓冲区，要禁用Doublewrite 缓冲区，可以将
innodb_doublewrite设置为0。使用Doublewrite 缓冲区时建议将innodb_flush_method设
置为O_DIRECT。
MySQL的innodb_flush_method这个参数控制着innodb数据文件及redo log的打开、
刷写模式。有三个值：fdatasync(默认)，O_DSYNC，O_DIRECT。设置O_DIRECT表示
数据文件写入操作会通知操作系统不要缓存数据，也不要用预读，直接从Innodb
Buffer写到磁盘文件。
默认的fdatasync意思是先写入操作系统缓存，然后再调用fsync()函数去异步刷数据文
件与redo log的缓存信息。
重做日志（Redo Log）
重做日志是一种基于磁盘的数据结构，用于在崩溃恢复期间更正不完整事务写入的数据。
MySQL以循环方式写入重做日志文件，记录InnoDB中所有对Buffer Pool修改的日志。当出
现实例故障（像断电），导致数据未能更新到数据文件，则数据库重启时须redo，重新把数
据更新到数据文件。读写事务在执行的过程中，都会不断的产生redo log。默认情况下，重
做日志在磁盘上由两个名为ib_logfile0和ib_logfile1的文件物理表示。
撤销日志（Undo Logs）
撤消日志是在事务开始之前保存的被修改数据的备份，用于例外情况时回滚事务。撤消日志
属于逻辑日志，根据每行记录进行记录。撤消日志存在于系统表空间、撤消表空间和临时表
空间中。
MySQL 5.7 版本
将 Undo日志表空间从共享表空间 ibdata 文件中分离出来，可以在安装 MySQL 时由用
户自行指定文件大小和数量。
增加了 temporary 临时表空间，里面存储着临时表或临时查询结果集的数据。
Buffer Pool 大小可以动态修改，无需重启数据库实例。
MySQL 8.0 版本
将InnoDB表的数据字典和Undo都从共享表空间ibdata中彻底分离出来了，以前需要
ibdata中数据字典与独立表空间ibd文件中数据字典一致才行，8.0版本就不需要了。
temporary 临时表空间也可以配置多个物理文件，而且均为 InnoDB 存储引擎并能创建
索引，这样加快了处理的速度。
用户可以像 Oracle 数据库那样设置一些表空间，每个表空间对应多个物理文件，每个
表空间可以给多个表使用，但一个表只能存储在一个表空间中。
将Doublewrite Buffer从共享表空间ibdata中也分离出来了

InnoDB线程模型

IO Thread
在InnoDB中使用了大量的AIO（Async IO）来做读写处理，这样可以极大提高数据库的性能。在
InnoDB1.0版本之前共有4个IO Thread，分别是write，read，insert buffer和log thread，后来
版本将read thread和write thread分别增大到了4个，一共有10个了。
read thread ： 负责读取操作，将数据从磁盘加载到缓存page页。4个
write thread：负责写操作，将缓存脏页刷新到磁盘。4个
log thread：负责将日志缓冲区内容刷新到磁盘。1个
insert buffer thread ：负责将写缓冲内容刷新到磁盘。1个
Purge Thread
事务提交之后，其使用的undo日志将不再需要，因此需要Purge Thread回收已经分配的undo
页。
show variables like ‘%innodb_purge_threads%’;
Page Cleaner Thread
作用是将脏数据刷新到磁盘，脏数据刷盘后相应的redo log也就可以覆盖，即可以同步数据，又能
达到redo log循环使用的目的。会调用write thread线程处理。
show variables like ‘%innodb_page_cleaners%’;
Master Thread
Master thread是InnoDB的主线程，负责调度其他各线程，优先级最高。作用是将缓冲池中的数
据异步刷新到磁盘 ，保证数据的一致性。包含：脏页的刷新（page cleaner thread）、undo页
回收（purge thread）、redo日志刷新（log thread）、合并写缓冲等。内部有两个主处理，分别
是每隔1秒和10秒处理。
每1秒的操作：
刷新日志缓冲区，刷到磁盘
合并写缓冲区数据，根据IO读写压力来决定是否操作
刷新脏页数据到磁盘，根据脏页比例达到75%才操作（innodb_max_dirty_pages_pct，
innodb_io_capacity） 每10秒的操作：
刷新脏页数据到磁盘
合并写缓冲区数据
刷新日志缓冲区
删除无用的undo页

Undolog and binlog and redoLog
Undo Log
3.5.1 Undo Log介绍
Undo：意为撤销或取消，以撤销操作为目的，返回指定某个状态的操作。
Undo Log：数据库事务开始之前，会将要修改的记录存放到 Undo 日志里，当事务回滚时或者数
据库崩溃时，可以利用 Undo 日志，撤销未提交事务对数据库产生的影响。
Undo Log产生和销毁：Undo Log在事务开始前产生；事务在提交时，并不会立刻删除undo
log，innodb会将该事务对应的undo log放入到删除列表中，后面会通过后台线程purge thread进
行回收处理。Undo Log属于逻辑日志，记录一个变化过程。例如执行一个delete，undolog会记
录一个insert；执行一个update，undolog会记录一个相反的update。
Undo Log存储：undo log采用段的方式管理和记录。在innodb数据文件中包含一种rollback
segment回滚段，内部包含1024个undo log segment。可以通过下面一组参数来控制Undo log存
储。
3.5.2 Undo Log作用
实现事务的原子性
Undo Log 是为了实现事务的原子性而出现的产物。事务处理过程中，如果出现了错误或者用户执
行了 ROLLBACK 语句，MySQL 可以利用 Undo Log 中的备份将数据恢复到事务开始之前的状态。
实现多版本并发控制（MVCC）
Undo Log 在 MySQL InnoDB 存储引擎中用来实现多版本并发控制。事务未提交之前，Undo Log
保存了未提交之前的版本数据，Undo Log 中的数据可作为数据旧版本快照供其他并发事务进行快
照读。
事务A手动开启事务，执行更新操作，首先会把更新命中的数据备份到 Undo Buffer 中。
事务B手动开启事务，执行查询操作，会读取 Undo 日志数据返回，进行快照读
3.6 Redo Log和Binlog
Redo Log和Binlog是MySQL日志系统中非常重要的两种机制，也有很多相似之处，下面介绍下两者细
节和区别。
3.6.1 Redo Log日志
Redo Log介绍
show variables like ‘%innodb_undo%’;
Redo：顾名思义就是重做。以恢复操作为目的，在数据库发生意外时重现操作。
Redo Log：指事务中修改的任何数据，将最新的数据备份存储的位置（Redo Log），被称为重做
日志。
Redo Log 的生成和释放：随着事务操作的执行，就会生成Redo Log，在事务提交时会将产生
Redo Log写入Log Buffer，并不是随着事务的提交就立刻写入磁盘文件。等事务操作的脏页写入
到磁盘之后，Redo Log 的使命也就完成了，Redo Log占用的空间就可以重用（被覆盖写入）。
Redo Log工作原理
Redo Log 是为了实现事务的持久性而出现的产物。防止在发生故障的时间点，尚有脏页未写入表
的 IBD 文件中，在重启 MySQL 服务的时候，根据 Redo Log 进行重做，从而达到事务的未入磁盘
数据进行持久化这一特性。
Redo Log写入机制
Redo Log 文件内容是以顺序循环的方式写入文件，写满时则回溯到第一个文件，进行覆盖写。
如图所示：
write pos 是当前记录的位置，一边写一边后移，写到最后一个文件末尾后就回到 0 号文件开
头；
checkpoint 是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数
据文件；
write pos 和 checkpoint 之间还空着的部分，可以用来记录新的操作。如果 write pos 追上
checkpoint，表示写满，这时候不能再执行新的更新，得停下来先擦掉一些记录，把 checkpoint
推进一下。
Redo Log相关配置参数
每个InnoDB存储引擎至少有1个重做日志文件组（group），每个文件组至少有2个重做日志文
件，默认为ib_logfile0和ib_logfile1。可以通过下面一组参数控制Redo Log存储：
show variables like ‘%innodb_log%’;
Redo Buffer 持久化到 Redo Log 的策略，可通过 Innodb_flush_log_at_trx_commit 设置：
0：每秒提交 Redo buffer ->OS cache -> flush cache to disk，可能丢失一秒内的事务数
据。由后台Master线程每隔 1秒执行一次操作。
1（默认值）：每次事务提交执行 Redo Buffer -> OS cache -> flush cache to disk，最安
全，性能最差的方式。
2：每次事务提交执行 Redo Buffer -> OS cache，然后由后台Master线程再每隔1秒执行OS
cache -> flush cache to disk 的操作。
一般建议选择取值2，因为 MySQL 挂了数据没有损失，整个服务器挂了才会损失1秒的事务提交数
据。
3.6.2 Binlog日志
Binlog记录模式
Redo Log 是属于InnoDB引擎所特有的日志，而MySQL Server也有自己的日志，即 Binary
log（二进制日志），简称Binlog。Binlog是记录所有数据库表结构变更以及表数据修改的二进制
日志，不会记录SELECT和SHOW这类操作。Binlog日志是以事件形式记录，还包含语句所执行的
消耗时间。开启Binlog日志有以下两个最重要的使用场景。
主从复制：在主库中开启Binlog功能，这样主库就可以把Binlog传递给从库，从库拿到
Binlog后实现数据恢复达到主从数据一致性。
数据恢复：通过mysqlbinlog工具来恢复数据。
Binlog文件名默认为“主机名_binlog-序列号”格式，例如oak_binlog-000001，也可以在配置文件
中指定名称。文件记录模式有STATEMENT、ROW和MIXED三种，具体含义如下。
ROW（row-based replication, RBR）：日志中会记录每一行数据被修改的情况，然后在
slave端对相同的数据进行修改。
优点：能清楚记录每一个行数据的修改细节，能完全实现主从数据同步和数据的恢复。
缺点：批量操作，会产生大量的日志，尤其是alter table会让日志暴涨。
STATMENT（statement-based replication, SBR）：每一条被修改数据的SQL都会记录到
master的Binlog中，slave在复制的时候SQL进程会解析成和原来master端执行过的相同的
SQL再次执行。简称SQL语句复制。
优点：日志量小，减少磁盘IO，提升存储和恢复速度
缺点：在某些情况下会导致主从数据不一致，比如last_insert_id()、now()等函数。
MIXED（mixed-based replication, MBR）：以上两种模式的混合使用，一般会使用
STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作使用ROW模式保存
binlog，MySQL会根据执行的SQL语句选择写入模式。
Binlog文件结构
MySQL的binlog文件中记录的是对数据库的各种修改操作，用来表示修改操作的数据结构是Log
event。不同的修改操作对应的不同的log event。比较常用的log event有：Query event、Row event、Xid event等。binlog文件的内容就是各种Log event的集合。
Binlog文件中Log event结构如下图所示：
Binlog写入机制
根据记录模式和操作触发event事件生成log event（事件触发执行机制）
将事务执行过程中产生log event写入缓冲区，每个事务线程都有一个缓冲区
Log Event保存在一个binlog_cache_mngr数据结构中，在该结构中有两个缓冲区，一个是
stmt_cache，用于存放不支持事务的信息；另一个是trx_cache，用于存放支持事务的信息。
事务在提交阶段会将产生的log event写入到外部binlog文件中。
不同事务以串行方式将log event写入binlog文件中，所以一个事务包含的log event信息在
binlog文件中是连续的，中间不会插入其他事务的log event。
Binlog文件操作
Binlog状态查看
show variables like ‘log_bin’;
开启Binlog功能
mysql> set global log_bin=mysqllogbin; ERROR 1238 (HY000): Variable ‘log_bin’ is a read only variable
需要修改my.cnf或my.ini配置文件，在[mysqld]下面增加log_bin=mysql_bin_log，重启
MySQL服务。
#log-bin=ON #log-bin-basename=mysqlbinlog binlog-format=ROW log-bin=mysqlbinlog
使用show binlog events命令
show binary logs; //等价于show master logs; show master status; show binlog events; show binlog events in ‘mysqlbinlog.000001’;
使用mysqlbinlog 命令
mysqlbinlog “文件名” mysqlbinlog “文件名” > “test.sql”
使用 binlog 恢复数据
//按指定时间恢复 mysqlbinlog –start-datetime=”2020-04-25 18:00:00” –stop- datetime=”2020-04-26 00:00:00” mysqlbinlog.000002 | mysql -uroot -p1234 //按事件位置号恢复 mysqlbinlog –start-position=154 –stop-position=957 mysqlbinlog.000002 | mysql -uroot -p1234
mysqldump：定期全部备份数据库数据。mysqlbinlog可以做增量备份和恢复操作。
删除Binlog文件
purge binary logs to ‘mysqlbinlog.000001’; //删除指定文件 purge binary logs before ‘2020-04-28 00:00:00’; //删除指定时间之前的文件 reset master; //清除所有文件
可以通过设置expire_logs_days参数来启动自动清理功能。默认值为0表示没启用。设置为1表示超
出1天binlog文件会自动删除掉。
Redo Log和Binlog区别
Redo Log是属于InnoDB引擎功能，Binlog是属于MySQL Server自带功能，并且是以二进制
文件记录。
Redo Log属于物理日志，记录该数据页更新状态内容，Binlog是逻辑日志，记录更新过程。
Redo Log日志是循环写，日志空间大小是固定，Binlog是追加写入，写完一个写下一个，不
会覆盖使用。
Redo Log作为服务器异常宕机后事务数据自动恢复使用，Binlog可以作为主从复制和数据恢
复使用。Binlog没有自动crash-safe能力。

MySQL索引原理
索引类型
索引可以提升查询速度，会影响where查询，以及order by排序。MySQL索引类型如下：
从索引存储结构划分：B Tree索引、Hash索引、FULLTEXT全文索引、R Tree索引
从应用层次划分：普通索引、唯一索引、主键索引、复合索引
从索引键值类型划分：主键索引、辅助索引（二级索引）
从数据存储和索引键值逻辑关系划分：聚集索引（聚簇索引）、非聚集索引（非聚簇索引）
普通索引
这是最基本的索引类型，基于普通字段建立的索引，没有任何限制。
创建普通索引的方法如下：
CREATE INDEX ON tablename (字段名);
ALTER TABLE tablename ADD INDEX [索引的名字] (字段名);
CREATE TABLE tablename ( […], INDEX [索引的名字] (字段名) );
1.2 唯一索引
与”普通索引”类似，不同的就是：索引字段的值必须唯一，但允许有空值 。在创建或修改表时追加唯一
约束，就会自动创建对应的唯一索引。
创建唯一索引的方法如下：
CREATE UNIQUE INDEX ON tablename (字段名);
ALTER TABLE tablename ADD UNIQUE INDEX [索引的名字] (字段名);
CREATE TABLE tablename ( […], UNIQUE [索引的名字] (字段名) ;
1.3 主键索引
它是一种特殊的唯一索引，不允许有空值。在创建或修改表时追加主键约束即可，每个表只能有一个主
键。
创建主键索引的方法如下：
CREATE TABLE tablename ( […], PRIMARY KEY (字段名) );
ALTER TABLE tablename ADD PRIMARY KEY (字段名);
1.4 复合索引
单一索引是指索引列为一列的情况，即新建索引的语句只实施在一列上；用户可以在多个列上建立索
引，这种索引叫做组复合索引（组合索引）。复合索引可以代替多个单一索引，相比多个单一索引复合
索引所需的开销更小。
索引同时有两个概念叫做窄索引和宽索引，窄索引是指索引列为1-2列的索引，宽索引也就是索引列超
过2列的索引，设计索引的一个重要原则就是能用窄索引不用宽索引，因为窄索引往往比组合索引更有
效。
创建组合索引的方法如下：
CREATE INDEX ON tablename (字段名1，字段名2…);
ALTER TABLE tablename ADD INDEX [索引的名字] (字段名1，字段名2…);
CREATE TABLE tablename ( […], INDEX [索引的名字] (字段名1，字段名2…) );
复合索引使用注意事项：
何时使用复合索引，要根据where条件建索引，注意不要过多使用索引，过多使用会对更新操作效
率有很大影响。
如果表已经建立了(col1，col2)，就没有必要再单独建立（col1）；如果现在有(col1)索引，如果查
询需要col1和col2条件，可以建立(col1,col2)复合索引，对于查询有一定提高。
1.5 全文索引
查询操作在数据量比较少时，可以使用like模糊查询，但是对于大量的文本数据检索，效率很低。如果
使用全文索引，查询速度会比like快很多倍。在MySQL 5.6 以前的版本，只有MyISAM存储引擎支持全
文索引，从MySQL 5.6开始MyISAM和InnoDB存储引擎均支持。
创建全文索引的方法如下：
CREATE FULLTEXT INDEX ON tablename (字段名);
ALTER TABLE tablename ADD FULLTEXT [索引的名字] (字段名);
CREATE TABLE tablename ( […], FULLTEXT KEY [索引的名字] (字段名) ;
和常用的like模糊查询不同，全文索引有自己的语法格式，使用 match 和 against 关键字，比如
全文索引使用注意事项：
全文索引必须在字符串、文本字段上建立。
全文索引字段值必须在最小字符和最大字符之间的才会有效。（innodb：3-84；myisam：4-
84）
全文索引字段值要进行切词处理，按syntax字符进行切割，例如b+aaa，切分成b和aaa
全文索引匹配查询，默认使用的是等值匹配，例如a匹配a，不会匹配ab,ac。如果想匹配可以在布
尔模式下搜索a*
第2节 索引原理
MySQL官方对索引定义：是存储引擎用于快速查找记录的一种数据结构。需要额外开辟空间和数据维护
工作。
索引是物理数据页存储，在数据文件中（InnoDB，ibd文件），利用数据页(page)存储。
索引可以加快检索速度，但是同时也会降低增删改操作速度，索引维护需要代价。
索引涉及的理论知识：二分查找法、Hash和B+Tree。
2.1 二分查找法
二分查找法也叫作折半查找法，它是在有序数组中查找指定数据的搜索算法。它的优点是等值查询、范
围查询性能优秀，缺点是更新数据、新增数据、删除数据维护成本高。
首先定位left和right两个指针
select * from user where match(name) against(‘aaa’); select * from user where match(name) against(‘a*’ in boolean mode);
计算(left+right)/2
判断除2后索引位置值与目标值的大小比对
索引位置值大于目标值就-1，right移动；如果小于目标值就+1，left移动
举个例子，下面的有序数组有17 个值，查找的目标值是7，过程如下：
第一次查找
第二次查找
第三次查找
第四次查找
2.2 Hash结构
Hash底层实现是由Hash表来实现的，是根据键值 存储数据的结构。非常适合根据key查找
value值，也就是单个key查询，或者说等值查询。其结构如下所示：
从上面结构可以看出，Hash索引可以方便的提供等值查询，但是对于范围查询就需要全表扫描了。
Hash索引在MySQL 中Hash结构主要应用在Memory原生的Hash索引 、InnoDB 自适应哈希索引。
InnoDB提供的自适应哈希索引功能强大，接下来重点描述下InnoDB 自适应哈希索引。
InnoDB自适应哈希索引是为了提升查询效率，InnoDB存储引擎会监控表上各个索引页的查询，当
InnoDB注意到某些索引值访问非常频繁时，会在内存中基于B+Tree索引再创建一个哈希索引，使得内
存中的 B+Tree 索引具备哈希索引的功能，即能够快速定值访问频繁访问的索引页。
InnoDB自适应哈希索引：在使用Hash索引访问时，一次性查找就能定位数据，等值查询效率要优于
B+Tree。
自适应哈希索引的建立使得InnoDB存储引擎能自动根据索引页访问的频率和模式自动地为某些热点页
建立哈希索引来加速访问。另外InnoDB自适应哈希索引的功能，用户只能选择开启或关闭功能，无法
进行人工干涉。
show engine innodb status G; show variables like ‘%innodb_adaptive%’;
2.3 B+Tree结构
MySQL数据库索引采用的是B+Tree结构，在B-Tree结构上做了优化改造。
B-Tree结构
索引值和data数据分布在整棵树结构中
每个节点可以存放多个索引值及对应的data数据
树节点中的多个索引值从左到右升序排列
B树的搜索：从根节点开始，对节点内的索引值序列采用二分法查找，如果命中就结束查找。没有
命中会进入子节点重复查找过程，直到所对应的的节点指针为空，或已经是叶子节点了才结束。
B+Tree结构
非叶子节点不存储data数据，只存储索引值，这样便于存储更多的索引值
叶子节点包含了所有的索引值和data数据
叶子节点用指针连接，提高区间的访问性能
相比B树，B+树进行范围查找时，只需要查找定位两个节点的索引值，然后利用叶子节点的指针进
行遍历即可。而B树需要遍历范围内所有的节点和数据，显然B+Tree效率高。
2.4 聚簇索引和辅助索引
聚簇索引和非聚簇索引：B+Tree的叶子节点存放主键索引值和行记录就属于聚簇索引；如果索引值和行
记录分开存放就属于非聚簇索引。
主键索引和辅助索引：B+Tree的叶子节点存放的是主键字段值就属于主键索引；如果存放的是非主键值
就属于辅助索引（二级索引）。
在InnoDB引擎中，主键索引采用的就是聚簇索引结构存储。
聚簇索引（聚集索引）
聚簇索引是一种数据存储方式，InnoDB的聚簇索引就是按照主键顺序构建 B+Tree结构。B+Tree
的叶子节点就是行记录，行记录和主键值紧凑地存储在一起。 这也意味着 InnoDB 的主键索引就
是数据表本身，它按主键顺序存放了整张表的数据，占用的空间就是整个表数据量的大小。通常说
的主键索引就是聚集索引。
InnoDB的表要求必须要有聚簇索引：
如果表定义了主键，则主键索引就是聚簇索引
如果表没有定义主键，则第一个非空unique列作为聚簇索引
否则InnoDB会从建一个隐藏的row-id作为聚簇索引
辅助索引
InnoDB辅助索引，也叫作二级索引，是根据索引列构建 B+Tree结构。但在 B+Tree 的叶子节点中
只存了索引列和主键的信息。二级索引占用的空间会比聚簇索引小很多， 通常创建辅助索引就是
为了提升查询效率。一个表InnoDB只能创建一个聚簇索引，但可以创建多个辅助索引。
非聚簇索引
与InnoDB表存储不同，MyISAM数据表的索引文件和数据文件是分开的，被称为非聚簇索引结
构。

查询优化
MySQL 提供了一个 EXPLAIN 命令，它可以对 SELECT 语句进行分析，并输出 SELECT 执行的详细信
息，供开发人员有针对性的优化。例如：
EXPLAIN 命令的输出内容大致如下：
select_type
表示查询的类型。常用的值如下：
SIMPLE ： 表示查询语句不包含子查询或union
PRIMARY：表示此查询是最外层的查询
UNION：表示此查询是UNION的第二个或后续的查询
EXPLAIN SELECT * from user WHERE id 、>=、 long_query_time，就会把
这条执行语句记录到慢查询日志里面。long_query_time 参数的默认值是 10s，该参数值可
以根据自己的业务需要进行调整。
如何判断是否应用了索引？
SQL语句是否使用了索引，可根据SQL语句执行过程中有没有用到表的索引，可通过 explain
命令分析查看，检查结果中的 key 值，是否为NULL。
应用了索引是否一定快？
下面我们来看看下面语句的 explain 的结果，你觉得这条语句有用上索引吗？比如
虽然使用了索引，但是还是从主键索引的最左边的叶节点开始向右扫描整个索引树，进行了
全表扫描，此时索引就失去了意义。
而像 select * from user where id = 2; 这样的语句，才是我们平时说的使用了索引。它表示
的意思是，我们使用了索引的快速搜索功能，并且有效地减少了扫描行数。
查询是否使用索引，只是表示一个SQL语句的执行过程；而是否为慢查询，是由它执行的时间决定
的，也就是说是否使用了索引和是否是慢查询两者之间没有必然的联系。
我们在使用索引时，不要只关注是否起作用，应该关心索引是否减少了查询扫描的数据行数，如果
扫描行数减少了，效率才会得到提升。对于一个大表，不止要创建索引，还要考虑索引过滤性，过
滤性好，执行速度才会快。
提高索引过滤性
假如有一个5000万记录的用户表，通过sex=’男’索引过滤后，还需要定位3000万，SQL执行速度也
不会很快。其实这个问题涉及到索引的过滤性，比如1万条记录利用索引过滤后定位10条、100
条、1000条，那他们过滤性是不同的。索引过滤性与索引字段、表的数据量、表设计结构都有关
系。
下面我们看一个案例：
优化1 perl mysqldumpslow.pl -t 5 -s at C:ProgramDataMySQLDataOAK-slow.log select * from user where id>0; 表：student 字段：id,name,sex,age 造数据：insert into student (name,sex,age) select name,sex,age from student; SQL案例：select * from student where age=18 and name like ‘张%’;（全表扫 描）alter table student add index(name); //追加name索引
优化3
慢查询原因总结
全表扫描：explain分析type属性all
全索引扫描：explain分析type属性index
索引过滤性不好：靠索引字段选型、数据量和状态、表设计
频繁的回表查询开销：尽量少用select *，使用覆盖索引
4.3 分页查询优化
一般性分页
般的分页查询使用简单的 limit 子句就可以实现。limit格式如下：
第一个参数指定第一个返回记录行的偏移量，注意从0开始；
第二个参数指定返回记录行的最大数目；
如果只给定一个参数，它表示返回最大的记录行数目；
思考1：如果偏移量固定，返回记录量对执行时间有什么影响？
结果：在查询记录时，返回记录量低于100条，查询时间基本没有变化，差距不大。随着查询记录
量越大，所花费的时间也会越来越多。
思考2：如果查询偏移量变化，返回记录数固定对执行时间有什么影响？

优化2 alter table student add index(age,name); //追加age,name索引 可以看到，index condition pushdown 优化的效果还是很不错的。再进一步优化，我们可以把名 字的第一个字和年龄做一个联合索引，这里可以使用 MySQL 5.7 引入的虚拟列来实现。 //为user表添加first_name虚拟列，以及联合索引(first_name,age) alter table student add first_name varchar(2) generated always as (left(name, 1)), add index(first_name, age); explain select * from student where first_name=’张’ and age=18; SELECT * FROM 表名 LIMIT [offset,] rows select * from user limit 10000,1; select * from user limit 10000,10; select * from user limit 10000,100; select * from user limit 10000,1000; select * from user limit 10000,10000;
结果：在查询记录时，如果查询记录量相同，偏移量超过100后就开始随着偏移量增大，查询时间
急剧的增加。（这种分页查询机制，每次都会从数据库第一条记录开始扫描，越往后查询越慢，而
且查询的数据越多，也会拖慢总查询速度。）
分页优化方案
第一步：利用覆盖索引优化
第二步：利用子查询优化
原因：使用了id做主键比较(id>=)，并且子查询使用了覆盖索引进行优化。
MySQL事务和锁
第1节 ACID 特性
在关系型数据库管理系统中，一个逻辑工作单元要成为事务，必须满足这 4 个特性，即所谓的 ACID：
原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）。

1.1 原子性
原子性：事务是一个原子操作单元，其对数据的修改，要么全都执行，要么全都不执行。
修改—》Buffer Pool修改—》刷盘。可能会有下面两种情况：
事务提交了，如果此时Buffer Pool的脏页没有刷盘，如何保证修改的数据生效？ Redo
如果事务没提交，但是Buffer Pool的脏页刷盘了，如何保证不该存在的数据撤销？Undo
每一个写事务，都会修改BufferPool，从而产生相应的Redo/Undo日志，在Buffer Pool 中的页被刷到
磁盘之前，这些日志信息都会先写入到日志文件中，如果 Buffer Pool 中的脏页没有刷成功，此时数据
库挂了，那在数据库再次启动之后，可以通过 Redo 日志将其恢复出来，以保证脏页写的数据不会丢
失。如果脏页刷新成功，此时数据库挂了，就需要通过Undo来实现了。
1.2 持久性
持久性：指的是一个事务一旦提交，它对数据库中数据的改变就应该是永久性的，后续的操作或故障不
应该对其有任何影响，不会丢失。
如下图所示，一个“提交”动作触发的操作有：binlog落地、发送binlog、存储引擎提交、flush_logs，
check_point、事务提交标记等。这些都是数据库保证其数据完整性、持久性的手段。
select * from user limit 1,100; select * from user limit 10,100; select * from user limit 100,100; select * from user limit 1000,100; select * from user limit 10000,100; select * from user limit 10000,100; select id from user limit 10000,100; select * from user limit 10000,100; select * from user where id>= (select id from user limit 10000,1) limit 100;
MySQL的持久性也与WAL技术相关，redo log在系统Crash重启之类的情况时，可以修复数据，从而保
障事务的持久性。通过原子性可以保证逻辑上的持久性，通过存储引擎的数据刷盘可以保证物理上的持
久性。
1.3 隔离性
隔离性：指的是一个事务的执行不能被其他事务干扰，即一个事务内部的操作及使用的数据对其他的并
发事务是隔离的。
InnoDB 支持的隔离性有 4 种，隔离性从低到高分别为：读未提交、读提交、可重复读、可串行化。锁
和多版本控制（MVCC）技术就是用于保障隔离性的（后面课程详解）。
1.4 一致性
一致性：指的是事务开始之前和事务结束之后，数据库的完整性限制未被破坏。一致性包括两方面的内
容，分别是约束一致性和数据一致性。
约束一致性：创建表结构时所指定的外键、Check、唯一索引等约束，可惜在 MySQL 中不支持
Check 。
数据一致性：是一个综合性的规定，因为它是由原子性、持久性、隔离性共同保证的结果，而不是
单单依赖于某一种技术。
一致性也可以理解为数据的完整性。数据的完整性是通过原子性、隔离性、持久性来保证的，而这3个
特性又是通过 Redo/Undo 来保证的。逻辑上的一致性，包括唯一索引、外键约束、check 约束，这属
于业务逻辑范畴。
ACID 及它们之间的关系如下图所示，4个特性中有3个与 WAL 有关系，都需要通过 Redo、Undo 日志
来保证等。
WAL的全称为Write-Ahead Logging，先写日志，再写磁盘。
第2节 事务控制的演进
2.1 并发事务
事务并发处理可能会带来一些问题，比如：更新丢失、脏读、不可重复读、幻读等。
更新丢失
当两个或多个事务更新同一行记录，会产生更新丢失现象。可以分为回滚覆盖和提交覆盖。
回滚覆盖：一个事务回滚操作，把其他事务已提交的数据给覆盖了。
提交覆盖：一个事务提交操作，把其他事务已提交的数据给覆盖了。
脏读
一个事务读取到了另一个事务修改但未提交的数据。
不可重复读
一个事务中多次读取同一行记录不一致，后面读取的跟前面读取的不一致。
幻读
一个事务中多次按相同条件查询，结果不一致。后续查询的结果和面前查询结果不同，多了或少了
几行记录。
2.3 排队
最简单的方法，就是完全顺序执行所有事务的数据库操作，不需要加锁，简单的说就是全局排队。序列
化执行所有的事务单元，数据库某个时刻只处理一个事务操作，特点是强一致性，处理性能低。
2.2 排他锁
引入锁之后就可以支持并发处理事务，如果事务之间涉及到相同的数据项时，会使用排他锁，或叫互斥
锁，先进入的事务独占数据项以后，其他事务被阻塞，等待前面的事务释放锁。
注意，在整个事务1结束之前，锁是不会被释放的，所以，事务2必须等到事务1结束之后开始。
2.3 读写锁
读和写操作：读读、写写、读写、写读。
读写锁就是进一步细化锁的颗粒度，区分读操作和写操作，让读和读之间不加锁，这样下面的两个事务
就可以同时被执行了。
读写锁，可以让读和读并行，而读和写、写和读、写和写这几种之间还是要加排他锁。
2.4 MVCC
多版本控制MVCC，也就是Copy on Write的思想。MVCC除了支持读和读并行，还支持读和写、写和读
的并行，但为了保证一致性，写和写是无法并行的。
在事务1开始写操作的时候会copy一个记录的副本，其他事务读操作会读取这个记录副本，因此不会影
响其他事务对此记录的读取，实现写和读并行。
一、MVCC概念
MVCC（Multi Version Concurrency Control）被称为多版本控制，是指在数据库中为了实现高并发的
数据访问，对数据进行多版本处理，并通过事务的可见性来保证事务能看到自己应该看到的数据版本。
多版本控制很巧妙地将稀缺资源的独占互斥转换为并发，大大提高了数据库的吞吐量及读写性能。
如何生成的多版本？每次事务修改操作之前，都会在Undo日志中记录修改之前的数据状态和事务号，
该备份记录可以用于其他事务的读取，也可以进行必要时的数据回滚。
二、MVCC实现原理
MVCC最大的好处是读不加锁，读写不冲突。在读多写少的系统应用中，读写不冲突是非常重要的，极
大的提升系统的并发性能，这也是为什么现阶段几乎所有的关系型数据库都支持 MVCC 的原因，不过目
前MVCC只在 Read Commited 和 Repeatable Read 两种隔离级别下工作。
在 MVCC 并发控制中，读操作可以分为两类: 快照读（Snapshot Read）与当前读 （Current Read）。
快照读：读取的是记录的快照版本（有可能是历史版本），不用加锁。（select）
当前读：读取的是记录的最新版本，并且当前读返回的记录，都会加锁，保证其他事务不会再并发
修改这条记录。（select… for update 或lock in share mode，insert/delete/update）
为了让大家更直观地理解 MVCC 的实现原理，举一个记录更新的案例来讲解 MVCC 中多版本的实现。
假设 F1～F6 是表中字段的名字，1～6 是其对应的数据。后面三个隐含字段分别对应该行的隐含ID、事
务号和回滚指针，如下图所示。
具体的更新过程如下：
假如一条数据是刚 INSERT 的，DB_ROW_ID 为 1，其他两个字段为空。当事务 1 更改该行的数据值
时，会进行如下操作，如下图所示。
用排他锁锁定该行；记录 Redo log；
把该行修改前的值复制到 Undo log，即图中下面的行；
修改当前行的值，填写事务编号，使回滚指针指向 Undo log 中修改前的行。
接下来事务2操作，过程与事务 1 相同，此时 Undo log 中会有两行记录，并且通过回滚指针连在一
起，通过当前记录的回滚指针回溯到该行创建时的初始内容，如下图所示。
MVCC已经实现了读读、读写、写读并发处理，如果想进一步解决写写冲突，可以采用下面两种方案：
乐观锁
悲观锁
第3节 事务隔离级别
3.1 隔离级别类型
前面提到的“更新丢失”、”脏读”、“不可重复读”和“幻读”等并发事务问题，其实都是数据库一致性问题，
为了解决这些问题，MySQL数据库是通过事务隔离级别来解决的，数据库系统提供了以下 4 种事务隔
离级别供用户选择。
读未提交
Read Uncommitted 读未提交：解决了回滚覆盖类型的更新丢失，但可能发生脏读现象，也就是
可能读取到其他会话中未提交事务修改的数据。
已提交读
Read Committed 读已提交：只能读取到其他会话中已经提交的数据，解决了脏读。但可能发生
不可重复读现象，也就是可能在一个事务中两次查询结果不一致。
可重复度
Repeatable Read 可重复读：解决了不可重复读，它确保同一事务的多个实例在并发读取数据
时，会看到同样的数据行。不过理论上会出现幻读，简单的说幻读指的的当用户读取某一范围的数
据行时，另一个事务又在该范围插入了新行，当用户在读取该范围的数据时会发现有新的幻影行。
可串行化
Serializable 串行化：所有的增删改查串行执行。它通过强制事务排序，解决相互冲突，从而解决
幻度的问题。这个级别可能导致大量的超时现象的和锁竞争，效率低下。
数据库的事务隔离级别越高，并发问题就越小，但是并发处理能力越差（代价）。读未提交隔离级别最
低，并发问题多，但是并发处理能力好。以后使用时，可以根据系统特点来选择一个合适的隔离级别，
比如对不可重复读和幻读并不敏感，更多关心数据库并发处理能力，此时可以使用Read Commited隔
离级别。
事务隔离级别，针对Innodb引擎，支持事务的功能。像MyISAM引擎没有关系。
事务隔离级别和锁的关系
1）事务隔离级别是SQL92定制的标准，相当于事务并发控制的整体解决方案，本质上是对锁和MVCC使
用的封装，隐藏了底层细节。
2）锁是数据库实现并发控制的基础，事务隔离性是采用锁来实现，对相应操作加不同的锁，就可以防
止其他事务同时对数据进行读写操作。
3）对用户来讲，首先选择使用隔离级别，当选用的隔离级别不能解决并发问题或需求时，才有必要在
开发中手动的设置锁。
MySQL默认隔离级别：可重复读
Oracle、SQLServer默认隔离级别：读已提交
一般使用时，建议采用默认隔离级别，然后存在的一些并发问题，可以通过悲观锁、乐观锁等实现处
理。
3.2 MySQL隔离级别控制
MySQL默认的事务隔离级别是Repeatable Read，查看MySQL当前数据库的事务隔离级别命令如下：
或show variables like ‘tx_isolation’;
设置事务隔离级别可以如下命令：
第4节 锁机制和实战
4.1 锁分类
在 MySQL中锁有很多不同的分类。
从操作的粒度可分为表级锁、行级锁和页级锁。
表级锁：每次操作锁住整张表。锁定粒度大，发生锁冲突的概率最高，并发度最低。应用在
MyISAM、InnoDB、BDB 等存储引擎中。
行级锁：每次操作锁住一行数据。锁定粒度最小，发生锁冲突的概率最低，并发度最高。应
用在InnoDB 存储引擎中。
页级锁：每次锁定相邻的一组记录，锁定粒度界于表锁和行锁之间，开销和加锁时间界于表
锁和行锁之间，并发度一般。应用在BDB 存储引擎中。
从操作的类型可分为读锁和写锁。
读锁（S锁）：共享锁，针对同一份数据，多个读操作可以同时进行而不会互相影响。
写锁（X锁）：排他锁，当前写操作没有完成前，它会阻断其他写锁和读锁。
IS锁、IX锁：意向读锁、意向写锁，属于表级锁，S和X主要针对行级锁。在对表记录添加S或X锁之
前，会先对表添加IS或IX锁。
S锁：事务A对记录添加了S锁，可以对记录进行读操作，不能做修改，其他事务可以对该记录追加
S锁，但是不能追加X锁，需要追加X锁，需要等记录的S锁全部释放。
X锁：事务A对记录添加了X锁，可以对记录进行读和修改操作，其他事务不能对记录做读和修改操
作。
从操作的性能可分为乐观锁和悲观锁。
乐观锁：一般的实现方式是对记录数据版本进行比对，在数据更新提交的时候才会进行冲突
检测，如果发现冲突了，则提示错误信息。
悲观锁：在对一条数据修改的时候，为了避免同时被其他人修改，在修改数据之前先锁定，
再修改的控制方式。共享锁和排他锁是悲观锁的不同实现，但都属于悲观锁范畴。
4.2 行锁原理
在InnoDB引擎中，我们可以使用行锁和表锁，其中行锁又分为共享锁和排他锁。InnoDB行锁是通过对
索引数据页上的记录加锁实现的，主要实现算法有 3 种：Record Lock、Gap Lock 和 Next-key Lock。 select @@tx_isolation; set tx_isolation=’READ-UNCOMMITTED’; set tx_isolation=’READ-COMMITTED’; set tx_isolation=’REPEATABLE-READ’; set tx_isolation=’SERIALIZABLE’;
RecordLock锁：锁定单个行记录的锁。（记录锁，RC、RR隔离级别都支持）
GapLock锁：间隙锁，锁定索引记录间隙，确保索引记录的间隙不变。（范围锁，RR隔离级别支
持）
Next-key Lock 锁：记录锁和间隙锁组合，同时锁住数据，并且锁住数据前后范围。（记录锁+范
围锁，RR隔离级别支持）
在RR隔离级别，InnoDB对于记录加锁行为都是先采用Next-Key Lock，但是当SQL操作含有唯一索引
时，Innodb会对Next-Key Lock进行优化，降级为RecordLock，仅锁住索引本身而非范围。
1）select … from 语句：InnoDB引擎采用MVCC机制实现非阻塞读，所以对于普通的select语句，
InnoDB不加锁
2）select … from lock in share mode语句：追加了共享锁，InnoDB会使用Next-Key Lock锁进行处
理，如果扫描发现唯一索引，可以降级为RecordLock锁。
3）select … from for update语句：追加了排他锁，InnoDB会使用Next-Key Lock锁进行处理，如果扫
描发现唯一索引，可以降级为RecordLock锁。
4）update … where 语句：InnoDB会使用Next-Key Lock锁进行处理，如果扫描发现唯一索引，可以
降级为RecordLock锁。
5）delete … where 语句：InnoDB会使用Next-Key Lock锁进行处理，如果扫描发现唯一索引，可以降
级为RecordLock锁。
6）insert语句：InnoDB会在将要插入的那一行设置一个排他的RecordLock锁。
下面以“update t1 set name=‘XX’ where id=10”操作为例，举例子分析下 InnoDB 对不同索引的加锁行
为，以RR隔离级别为例。
主键加锁
加锁行为：仅在id=10的主键索引记录上加X锁。
唯一键加锁
加锁行为：现在唯一索引id上加X锁，然后在id=10的主键索引记录上加X锁。
非唯一键加锁
加锁行为：对满足id=10条件的记录和主键分别加X锁，然后在(6,c)-(10,b)、(10,b)-(10,d)、(10,d)-
(11,f)范围分别加Gap Lock。
无索引加锁
加锁行为：表里所有行和间隙都会加X锁。（当没有索引时，会导致全表锁定，因为InnoDB引擎
锁机制是基于索引实现的记录锁定）。
4.3 悲观锁
悲观锁（Pessimistic Locking），是指在数据处理过程，将数据处于锁定状态，一般使用数据库的锁机
制实现。从广义上来讲，前面提到的行锁、表锁、读锁、写锁、共享锁、排他锁等，这些都属于悲观锁
范畴。
表级锁
表级锁每次操作都锁住整张表，并发度最低。常用命令如下：
手动增加表锁
查看表上加过的锁
删除表锁
表级读锁：当前表追加read锁，当前连接和其他的连接都可以读操作；但是当前连接增删改操作
会报错，其他连接增删改会被阻塞。
lock table 表名称 read|write,表名称2 read|write; show open tables; unlock tables;
表级写锁：当前表追加write锁，当前连接可以对表做增删改查操作，其他连接对该表所有操作都
被阻塞（包括查询）。
总结：表级读锁会阻塞写操作，但是不会阻塞读操作。而写锁则会把读和写操作都阻塞。
共享锁（行级锁-读锁）
共享锁又称为读锁，简称S锁。共享锁就是多个事务对于同一数据可以共享一把锁，都能访问到数
据，但是只能读不能修改。使用共享锁的方法是在select … lock in share mode，只适用查询语
句。
总结：事务使用了共享锁（读锁），只能读取，不能修改，修改操作被阻塞。
排他锁（行级锁-写锁）
排他锁又称为写锁，简称X锁。排他锁就是不能与其他锁并存，如一个事务获取了一个数据行的排
他锁，其他事务就不能对该行记录做其他操作，也不能获取该行的锁。
使用排他锁的方法是在SQL末尾加上for update，innodb引擎默认会在update，delete语句加上
for update。行级锁的实现其实是依靠其对应的索引，所以如果操作没用到索引的查询，那么会锁
住全表记录。
总结：事务使用了排他锁（写锁），当前事务可以读取和修改，其他事务不能修改，也不能获取记录
锁（select… for update）。如果查询没有使用到索引，将会锁住整个表记录。
4.4 乐观锁
乐观锁是相对于悲观锁而言的，它不是数据库提供的功能，需要开发者自己去实现。在数据库操作时，
想法很乐观，认为这次的操作不会导致冲突，因此在数据库操作时并不做任何的特殊处理，即不加锁，
而是在进行事务提交时再去判断是否有冲突了。
乐观锁实现的关键点：冲突的检测。
悲观锁和乐观锁都可以解决事务写写并发，在应用中可以根据并发处理能力选择区分，比如对并发率要
求高的选择乐观锁；对于并发率要求低的可以选择悲观锁。
乐观锁实现原理
使用版本字段（version）
先给数据表增加一个版本(version) 字段，每操作一次，将那条记录的版本号加 1。version
是用来查看被读的记录有无变化，作用是防止记录在业务处理期间被其他事务修改。
使用时间戳（Timestamp）
与使用version版本字段相似，同样需要给在数据表增加一个字段，字段类型使用timestamp
时间戳。也是在更新提交的时候检查当前数据库中数据的时间戳和自己更新前取到的时间戳
进行对比，如果一致则提交更新，否则就是版本冲突，取消操作。
乐观锁案例
下面我们使用下单过程作为案例，描述下乐观锁的使用。
第一步：查询商品信息
第二部：根据商品信息生成订单
第三部：修改商品库存
除了自己手动实现乐观锁之外，许多数据库访问框架也封装了乐观锁的实现，比如
hibernate框架。MyBatis框架大家可以使用OptimisticLocker插件来扩展。
4.5 死锁与解决方案
下面介绍几种常见的死锁现象和解决方案：
一、表锁死锁
产生原因：
select (quantity,version) from products where id=1; insert into orders … insert into items … update products set quantity=quantity-1,version=version+1 where id=1 and version=#{version};
用户A访问表A（锁住了表A），然后又访问表B；另一个用户B访问表B（锁住了表B），然后企图
访问表A；这时用户A由于用户B已经锁住表B，它必须等待用户B释放表B才能继续，同样用户B要
等用户A释放表A才能继续，这就死锁就产生了。
用户A–》A表（表锁）–》B表（表锁）
用户B–》B表（表锁）–》A表（表锁）
解决方案：
这种死锁比较常见，是由于程序的BUG产生的，除了调整的程序的逻辑没有其它的办法。仔细分
析程序的逻辑，对于数据库的多表操作时，尽量按照相同的顺序进行处理，尽量避免同时锁定两个
资源，如操作A和B两张表时，总是按先A后B的顺序处理， 必须同时锁定两个资源时，要保证在任
何时刻都应该按照相同的顺序来锁定资源。
二、行级锁死锁
产生原因1：
如果在事务中执行了一条没有索引条件的查询，引发全表扫描，把行级锁上升为全表记录锁定（等
价于表级锁），多个这样的事务执行后，就很容易产生死锁和阻塞，最终应用系统会越来越慢，发
生阻塞或死锁。
解决方案1：
SQL语句中不要使用太复杂的关联多表的查询；使用explain“执行计划”对SQL语句进行分析，对于
有全表扫描和全表锁定的SQL语句，建立相应的索引进行优化。
产生原因2：
两个事务分别想拿到对方持有的锁，互相等待，于是产生死锁。
解决方案2：
在同一个事务中，尽可能做到一次锁定所需要的所有资源
按照id对资源排序，然后按顺序进行处理
三、共享锁转换为排他锁
产生原因：
事务A 查询一条纪录，然后更新该条纪录；此时事务B 也更新该条纪录，这时事务B 的排他锁由于
事务A 有共享锁，必须等A 释放共享锁后才可以获取，只能排队等待。事务A 再执行更新操作时，
此处发生死锁，因为事务A 需要排他锁来做更新操作。但是，无法授予该锁请求，因为事务B 已经
有一个排他锁请求，并且正在等待事务A 释放其共享锁。
事务A: select * from dept where deptno=1 lock in share mode; //共享锁,1
update dept set dname=’java’ where deptno=1;//排他锁,3
事务B: update dept set dname=’Java’ where deptno=1;//由于1有共享锁，没法获取排他锁，需
等待，2
解决方案：
对于按钮等控件，点击立刻失效，不让用户重复点击，避免引发同时对同一条记录多次操
作；
使用乐观锁进行控制。乐观锁机制避免了长事务中的数据库加锁开销，大大提升了大并发量
下的系统性能。需要注意的是，由于乐观锁机制是在我们的系统中实现，来自外部系统的用
户更新操作不受我们系统的控制，因此可能会造成脏数据被更新到数据库中；
四、死锁排查
MySQL提供了几个与锁有关的参数和命令，可以辅助我们优化锁操作，减少死锁发生。
查看死锁日志
通过show engine innodb statusG命令查看近期死锁日志信息。
使用方法：1、查看近期死锁日志信息；2、使用explain查看下SQL执行计划
查看锁状态变量
通过show status like’innodb_row_lock%‘命令检查状态变量，分析系统中的行锁的争夺
情况
Innodb_row_lock_current_waits：当前正在等待锁的数量
Innodb_row_lock_time：从系统启动到现在锁定总时间长度
Innodb_row_lock_time_avg： 每次等待锁的平均时间
Innodb_row_lock_time_max：从系统启动到现在等待最长的一次锁的时间
Innodb_row_lock_waits：系统启动后到现在总共等待的次数
如果等待次数高，而且每次等待时间长，需要分析系统中为什么会有如此多的等待，然后着
手定制优化

除了自己手动实现乐观锁之外，许多数据库访问框架也封装了乐观锁的实现，比如
hibernate框架。MyBatis框架大家可以使用OptimisticLocker插件来扩展。