其中innodb就是图中的存储引擎。
一、表空间、buffer pool、压缩表
1、页
在磁盘的数据文件中称为数据页，在mysql内存中称为缓存页。不过大小一般都是16k。
页是IO交互的最小单位。（在磁盘文件和buffer pool交互的最小单位）
可以对页的大小进行压缩，KEY_BLOCK_SIZE=4就是压缩为4k，此时这张表就是压缩表。
但不是压缩的越低就越好，不同的场景压缩越低其指标不一样。
row offset array：有序的存放指向各个row的指针，用来快速定位数据页中的各个记录。（相当于一个目录）
数据格式默认是compact，dynamic和compact基本一样，除了在存储大对象时dynamic会对其进行优化。
对于大对象，compact只存大对象的前768个字节超出部分则会存在溢出页中（期间也会触发超8k触发行溢出），而dynamic存满一个页后触发行溢出则存到其他溢出页中，依次存储（行溢出：再创建一个页，将溢出的部分存到其他页，然后进行指针指向记录）。（一般size>页大小的一半，则触发行溢出现象。超过8k则会将超出的部分存到其他页。）
数据存储格式？行溢出？为什么是8k？？？
——一行数据为多大时，会发生行溢出呢？我们知道InnoDB存储引擎表是索引组织的，即B+树结构，这样一个页中至少要保证有2条数据（所以超过页大小一半就触发行溢出，会将溢出的数据放到其他页中并指针指向。这个页剩下的一半存其他数据），否则就变成链表了（？？？目前看不懂），如果只能存放一条数据，那么InnoDB存储引擎会自动将它存放在溢出页中。如果可以在一个页中至少放入两行数据，那么就不会发生行溢出。https://www.jb51.net/article/200618.htm
索引中的页的每个row记录都会包含一个rowid（默认主键，没有mysql则会自动建立一个rowid）、txid（事务id）等等.
2、buffer pool（缓冲池）
用innodb_buffer_pool_size参数来控制大小。
之前的数据页就会被读到缓冲池中（内存）（在缓冲池中叫做缓存页）。
对于标记某个页用（space，page_no）其中space表示表空间id，page_no表示页号。所以要定位到磁盘的页需要知道其对应的表空间+页号。
可以查看每张表对应的表空间id：
查看缓冲池里有哪些页：
但是这个数据可能太大，线上不要轻易去查看。
buffer pool一般越大越好。
在缓冲池中存在一个hash表来存储已经在buffer pool中的缓冲页信息。
mysql的锁是占内存空间的，5.5之后是直接调用操作系统的malloc（）函数申请内存的，而不是向buffer pool申请内存。
压缩后的数据在页中怎么存储的？（即innodb压缩表）
旧的压缩方式：
因为页是被压缩了的，例如一个8k的页被读到bp中，然后这个压缩的页会被解压。这样就可以对这个页进行查询操作。
如果要对这个页进行更新操作:此时这个8k的压缩页被读到bp，然后将对这个页的重做日志redo log（也叫modification log 更新日志）写到这个页的空闲空间中，如果这个页被写满了则再重新进行压缩，如果压缩完还是不够就会重新申请一个同等大小的压缩页用来存储，最后将这些压缩页写回磁盘。这样这些更新时压缩页就不用做解压。
对于没压缩的16k就不做日志写入而是直接去做更新。
注意：16k没压缩的不会做日志记录操作，直接做更新操作。
一般建议可以开启压缩。
新的压缩方式：
透明页压缩，5.7新增的压缩算法。
在linux中，如果有一个文件大小是16k，此时里面的数据占12k，那么此时在文件后面填0至16k满，此时调用linux的fwrite写入磁盘，此时这个文件在磁盘的占用空间就是12k。
而透明页就是利用这点，如果一个16k的页，此时里面的数据被压缩到8k，剩下8k空闲区域，此时我们往其中填0（注意这里的压缩后的数据空间只能是操作系统块大小的倍数，即4k的倍数，如果压缩后的数据大小是6k，哪进磁盘后还是按4*2=8k进行占用），然后写入磁盘，此时在磁盘中这个页只会占用8k。
这样读取/更新这些透明页压缩算法的压缩页时，会解压为16k的页进行读取。这种新的压缩算法比较简洁高效。（都是以默认页大小进行交互存储的，老压缩是以压缩后大小进行存储交互的）
这种透明页压缩是比老压缩算法高效一些的。
一般使用lz4压缩算法进行透明页压缩。
这里压缩还是不太明白？？？？
buffer pool对其中的页进行管理时，都会对buffer pool加一个latch锁（轻量级锁）。
此时为了提高并发能力，可以设置一个innodb_buffer_pool_instances参数为cpu的核数：
如果buffer pool size太小这个参数会被刷为1.
此时如果我们给 buffer pool总的内存是1G，如果我们不配这个参数，那么就是只给一个buffer pool配置1G内存。
如果设置为例如4，那么此时会有4个buffer pool，每个256G。
这样加的latch就会是不同的buffer pool的latch锁（锁粒度减少了）（latch锁的是bp的一些资源）
5.6、5.7版本默认值是8。5.5是1。如果是5.5版本记得要调整其参数。
二、LRU、Master_Thread
buffer pool中有free list、lru list、flush list。
其中lru list又分LRU、unzip_LRU。
这些链表是基于页连接起来的。所以buffer pool基本等于free + LRU。（flush存在LRU中）
free list：管理bp中空闲的页。
lru list：管理已用的页（包含脏页和非脏页）
flush list：存放更新了的脏页。（该链存放的是指针）
链表都是在页中存储上下页节点形成的。所以这些链都是通过各个页的信息连接起来的。
1、LRU
如果一个页被使用了，此时需要将该页在free list上删除，并添加到lru list中，加入lru list是插入到一个midpoint位置上，该位置大概在链长3/8的位置。
最近最少使用算法：如果某个页被free list读到lru就会放到最前面链表头过去。
midpoint LRU：某个页从free list读到lru list，此时先放到midpoint的位置，如果后续有使用会被调到链表头的位置。（这样防止一些扫描进来却没用的页占用表头位置）（mysql默认）
其中midpoint 有参数停顿时间：innodb_old_black_time（待满停顿时间后才能移到链表头）,控制midpoint位置参数：innodb_old_blocks_pct。
MySQL是如何对LRU算法进行优化的？又该如何对MySQL进行调优？_天堂的博客-CSDN博客
预热
可以执行select+使用索引预热常用的表，但是这种方法是比较粗糙的。
5.6开始可以dump出buffer pool的数据，然后重启mysql后load这些数据进入buffer pool
此时dump出来的不是所有数据，而是这些页的space+pageno（还会进行排序，这样读取页的时候可以尽可能的减少读消耗）。
innodb后台线程：
从名字可以大概知道是一些日志线程、读写线程、刷新脏页线程（默认4个）、监控线程、dump线程等等。
可以调整这些线程的个数，例如调大写线程个数：
1、脏页刷新线程：page_cleaner_thread
默认4个，可以通过innodb_io_capacity参数进行控制。
一般每1秒最多刷新8000个脏页。
预读：关于MySQL buffer pool的预读机制 - GeaoZhang - 博客园
CheckPoint
主要用来刷新脏页，将脏页刷新到磁盘。
每个页都有一个LSN，整个mysql实例也有一个LSN（这个LSN也是checkPoint）。当页进行更新时，其LSN页会进行更新。每个数据库宕机恢复时，会读取数据库实例的LSN然后去日志中恢复数据。而全局的LSN是刷到磁盘的页的LSN的最大值。
恢复checkPoint（全局lsn）之后的所有数据（即从120开始恢复，checkpoint之前的已经写入磁盘了），这样就可以防止页2的最新数据丢失。（页2事务提交了就会记录到redo log中，但页此时还没刷到磁盘中）
其中log sequence number表示内存中日志的lsn，
log flushed up to是磁盘中日志记录的最大lsn，
pages flushed up to是bp中页最大的lsn，
last chechpoint at 是全局lsn。
此时可以发现全局lsn是小于等于页最大lsn和日志lsn的？
这个时候我们假如现在有一个页的lsn是80，此时进行第一次更新为100，此时由于是第一次更新全局会进行刷新（全局记录的是第一次更新的lsn），然后全局刷新为100。此时又对该页进行更新，产生了20字节的日志，那么该页的lsn会变为120，而全局lsn因为是第二次更新则不会刷新该值，所以全局还是100，然后该页会被添加到flush list页中。注意，flush list是按照第一次进来链表是的lsn进行排序位置的，所以当第二次更新这个页使得其lsn变为140，但是在flush list中，这个页的lsn还是120。（flush list只按第一次进来的lsn进行排序）
而我们刷新脏页是去flush list中刷新的，此时我们把这个120的页刷新到磁盘中
为什么全局在第二次更新不会记录最新的lsn值？
此时我们回来讲讲全局lsn是怎么改变的？
在这里可以看到newset_modification和oldset_modification，分别代表页最新的lsn和页改第一次的lsn。
而我们全局lsn用的就是oldset_modification，即记录的都是页的改的第一次lsn，而pages flushed up to的lsn是记录的newset_modification。（上面有个例子说页1和页2的情况是页改第一次的情况，才会使得全局lsn刷新）
此时只要保证每个页只更新一次，那么全局和page的lsn就会相等。
全局lsn、日志lsn都被存放到重做日志redo log中。
哪为什么要记录第一次更新的lsn？？
——为了恢复的时候，日志的恢复是对的。现在假如flush list有140、120的页，此时120的页如果再次更新使得lsn变为160，此时如果全局lsn记录的是最新的lsn，那么恢复数据的时候会从160开始恢复，这样就导致140这个可能存在丢失的情况。这里我有一个疑问？如果全局记录的是140，但是我120还没进行刷磁盘的时候就宕机了，此时恢复是从140开始恢复？？？如果是那不是丢失了120的页？？？为什么checkpoint前的数据是都被刷进磁盘的？？？
——checkpoint即全局lsn被记录的时机是页刷到磁盘了。（checkpoint是被记录到redo log文件的。）
MySQL InnoDB Checkpoint技术_weixin_35833012的博客-CSDN博客
这里的check point技术是fuzzy checkpoint。
刷新脏页不一定是都在flush list中进行刷新。
也有一些情况会取lru list中刷新脏页：
当free list没有空闲的页，此时又要申请一个空页就会把LRU最后一个页进行淘汰，如果该页是脏页则进行刷盘操作。
可以用一个参数配置每次淘汰时扫描多个页进行刷盘操作：
即每次没空页时，会找lru尾端1024个页对其中的脏页进行刷盘操作。
double write（双写）
InnoDB关键特性之double write - GeaoZhang - 博客园
redo log恢复的页需要这个页是完整的，如果某个页假如是16k，在写入磁盘写到一半（例如写了4k进磁盘）就发生宕机，此时这个页就是损坏的，此时是不能通过redo log进行恢复的。
即一个页写了两次。此时磁盘的doublewrite可以防止损坏页不能恢复。（默认打开的功能）
提升二级索引增删改的性能。（先存放在内存中（insert buffer会进行持久化），后面辅助索引读进bp在进行合并）
自适应hash索引
建议关闭。页数据改变导致维护代价太大。
自适应hash索引的对象是热点页里面的数据，b+树索引的对象是页。
对于ssd硬盘建议把这个功能关闭。
事务、undo log、redo log
事务原子性：redo保证，持久性：redo+undo，一致性：undo，唯一性：锁机制
事务可以自己手动开启提交（显示事务），如果没有显示提交mysql会隐式的为我们提交事务。（所以隐式提交每次执行sql可以当成一个事务）
事务隔离级别：
事务需要解决三个问题：脏读、不可重复读、幻读。
1、redo log
redo log buffer刷盘时机：
每次刷一个事务日志可能性能比较低，此时mysql有个优化组提交（多个事务日志一起提交）
有两个参数可以控制提交触发的时间或者达到多少个事务就提交：（一般不要调）
mysql的组提交一般不用去调整，mysql已经帮我们优化了可以了。自己去修改可能会导致性能下降。
5.6优化的组提交比5.5提升性能8-10倍。
mysql默认可以有两个redo log日志文件。可以通过innodb_log_file_size指定文件大小；用innodb_log_files_in_group来指定文件个数。
binlog：
其中T1、T2等是事务提交顺序。
binlog日志记录的是sql语句的操作，而redo log日志记录的是对页（space，page_no）的修改。（其记录的对象不同）
而redo log对在一个事务中是可以多次修改页的，所以会出现多个T1。
redo 日志是在事务执行过程就开始写了，而二进制日志binlog是在事务提交最后的时间才开始写。
重做日志一般用于复制等场景，建议开启：
怎么保证redo 和binlog写入的原子性？（redo和binlog写完才进行事务提交）
当redo和binlog都刷盘完之后，此时就要将本次更新的binlog文件名+这次更新在文件中的位置 记录到redo文件中，并在写完后加入commit标志。
那么这个commit标记有什么用，要记住只有图中的5、6、7步都执行完才叫真正的事务完成，如果第5步完成后宕机或第6步完成后宕机，此时redo没有commit标记，那么这个事务也算是没提交成功的，只有redo中有commit标记才表示事务的提交成功。
如果redo、binlog都写完最后没commit就宕机了，恢复时去扫描binlog拿到事务id去创建一个hash表，然后在去redo log扫描checkpoint位置然后也会生成一个事务列表，此时如果事务列表的某个事务存在hash表中（则表示redo和binlog写完成了），则会进行恢复操作。
写某个事务日志是不能跨日志文件写的。
undo ：记录逻辑（redo记录物理），用于事务回滚。
可以看我之前的undo文章
mysql除了支持本地事务外，还主从分布式事务XA。
回滚：
mysql中 XA分布式事务MySQL 中基于 XA 实现的分布式事务 - 简书
锁
锁的概念：
latch锁：（轻量级锁）（用来控制内存中数据结构、临界资源的并发访问，即类似我们java中的锁，锁住的对象是临界区）（latch锁的加锁释放锁过程是很快的，毫秒级别的）
例如现在执行count++操作，此时对于count这个对象可能有并发安全问题，此时就要加上latch锁进行控制（互斥锁）。
lock锁：（锁的是数据库层面的锁，innodb的锁住的对象是行，保护的是数据库中的内容）
lock锁的持续时间是整个事务，如果事务没被提交，会一直持有。
其实两种锁的应用层面是不同的，latch我们可以理解为java中我们对某个对象的并发安全控制，而lock是对于行数据的保护。
lock：
1、排他锁（X）
对某行进行增删改时需要对该行记录加排他锁。
select要加上排他锁可以在语句最后加上for update，不过此时如果其他会话也是可以通过mvcc机制读这条记录的。
2、共享锁（S）
给一条记录加上共享锁：追加lock in share mode
锁等待时间默认是50秒（会话级别的）
可以通过show engine innodb status可以查看mysql中的锁情况：
例如持有3把锁：
想要详细查看各个锁的信息，此时可打开打印详细信息锁的参数：
此时再看：可以看到有个IX表意向锁。还有记录锁（行锁X）且打印相应的行记录（其中trd和d是隐藏列，分别对应事务id和指针）。
这里可以看到各个记录存在heap no 2、3之类的。head no表示数据插入的顺序。而插入的顺序不代表数据大小的顺序。
在一个页中，存在mysql自己生成的heap no 0和1，这是用来存放虚拟的最小记录和最大记录的。如果此时插入heap no 2。则里面heap no的指向是0-2-1。再插入3则变为0-2-3-1。
一般对某行数据进行加锁，是根据page no+heap no来定位的。
此时加锁：
（lock bitmap这个位图是整个页的所有heap no）而heap no是在这个位图中表示的第几位，例如2表示第二位，此时如果位图中的第二位为1则表示为加锁了。
mysql是一个页对应一个锁对象，以页为单位进行锁对象管理的。
不过其占用内存比较小，每个页的锁对象大概几十个字节。
mysql——innodb（学习笔记）_忘记过去的人，必将重蹈覆辙-CSDN博客
意向锁：
意向锁都是表级别的。
意向锁之间都是不互斥的。innodb不仅仅有行锁，还有意向锁等表锁。
如果我们要像表a的第n行加一个x锁，此时第一步就是要对表a加一个IX锁，然后在对行n加X锁。S和IS类似。为什么之前说意向锁是不互斥的，就是因为意向锁顾名思义就是我之后有要加某个锁的意向，即先预先说明下我下面可能要加X锁或者S锁。
意向锁和行锁中：只要意向共享锁+共享锁、意向独占锁+独占锁（互斥锁）是不互斥的。
行锁中：只要共享锁+共享锁不互斥。
而且共享锁和互斥锁是存在行级和表级的。
所以如果此时又有一个线程要进来给a表加一个S锁，此时表a就同时存在IX和S，此时互斥所以加锁不成功，就会进行等待。
加锁是需要进行层级加锁的，先对表加锁、然后是行数据。
查看mysql中锁等待的情况：
去sys.innodb_lock_waits表中查看各个锁等待的情况：
自增锁：对于自增列的并发处理的。
在5.7中自增列有数据回溯问题（5.7在每次启动是去执行MAX（auto_inc_col）函数获取最大值，全表扫描）。8.0对自增的最大值做持久化解决了这个问题。
如果我们以自增列做索引时，需要将自增列作为最左的索引字段，否则会报错：
如下面a为自增列，以a和b建组合索引，此时a不是在最左列则会报错。
自增锁其实实际上就是latch锁，执行完语句就释放，不会因为事务是否提交才释放锁。
innodb_autoinc_lock_mode参数的设置对应意义：默认是1（这里被我设置为2了）MySQL自增锁模式innodb_autoinc_lock_mode参数理解调优 - WidgetBox - 博客园
innodb的RR事务级别是可以解决幻读的问题的。
可以想想是怎么解决幻读的？
锁的算法
锁算法主要分为：记录锁、范围锁、范围+记录锁。
1、记录锁
对于行数据进行加锁，实际上是对其索引进行加锁。记录锁就是加了X锁。
2、范围锁
例如现在主键索引有记录2、4、6、8四行记录。
此时加上范围锁可以是（2，100）2到100范围内的记录加X锁。
注意记录锁和范围锁是兼容的。即线程a对行2-100持范围锁，那么此时线程b同样可以对行2持记录锁但是不能进行数据的修改（只能进行加锁不能进行数据修改）。但是如果线程a已经对2-100持范围锁，此时线程b要去修改这个范围的行例如行2就需要等待访问锁的释放。
3、范围+记录锁。（也是innodb在RR级别解决幻读的关键）
例如对2-100加范围锁，且对2这条记录加记录锁。
该锁和前面的两种锁算法不兼容。
RR事务隔离级别用的锁算法大部分使用next-key锁算法（范围+记录），这个算法有一个问题就是插入的性能优点慢。有小部分情况下会进行优化使用record锁（语句使用的索引是唯一索引，且只返回一条记录的情况下）。
RC事务级别的锁大部分是记录锁。
在RC事务级别中可以看到查看mysql中锁的情况时，这里写着rec but not gap，则表示是record锁算法。
RR级别下怎么解决幻读的：（RR级别，所以一般都是用next-key算法）
mysql加锁是一条记录一条记录进行加锁的，所以这里不是直接4-8，然后再对6进行加锁。
那么为什么要去锁住（6，8）的区间？不是锁主6就行了吗？？（为了解决幻读情况）
此时如果在这个事务执行过程中，其他事务新插入一条6的记录，此时会放到原本6的后面，即放到了（6，8）的区间了。
那么这个时候就会产生幻读的情况（幻读：第二次读取读到原先不存在的数据），此时innodb的RR级别是可以防止幻读的，所以此时会对（6，8）进行加gap锁（新插入的6是存在这个区间的），防止其他事务插入同样的6。这样就不会产生幻读的情况了。（解决幻读就是对返回的记录的后面一个区间加上gap锁防止插入相同的数据）（这里也有一个情况就是4-6、6-8这个区间被加gap锁，那么此时插入4、5、7之类的记录也是不行的需要等待）
（主键索引也是类似的推导过程，锁算法其实锁的是索引 。又因为二级索引的叶子索引是key+主键，二级索引会对二级索引+主键索引都进行加锁（这里主键锁的只是4这个值，记录锁））
如果是RC时只会对6的记录使用记录锁，只锁住这一行。
延续前面的例子，我们知道被主键索引被锁住是4，二级索引被锁住的是（4，6】、
（6、8）。
那么此时我们插入（主键、二级索引列）的值为（3，4）此时不能插入，因为二级索引列中有4这个记录，此时插入会放在相同的4之后，所以就会在4-6的范围内。
那么此时再插入（1，4）发现可以插入。这个时候就有疑问了，4不是在4-6区间吗，怎么可以插入成功？？？？
其实在二级索引中，所谓的（4，6】、（6、8）。真实的情况下是
（（4，2），（6，4）】、（（6，4），（8，6））。即二级索引因为叶子节点且包含主键值，所以此时如果（4，1）插入不属于（（4，2），（6，4）】区间，可以插入成功。
但是（4，2）这种里面已经有的值还是属于（（4，2），（6，4）】区间不能插入。
（所以前面说的二级索引中4插入位置是不一定在原有4之后的，要搭配主键一起看。）
假如现在现在二级索引列b有值4、6、8、10。
让后我们执行b=12 for update；这时12这条记录是没有的，此时查看mysql中锁的情况：
可以发现此时锁的是heap no 1，即我们之前说的mysql自己生成的虚拟列最大记录。
如果加上虚拟列，b的真实数据是{min、4、6、8、10、max}。
而此时12不存在这些数据中，此时会在max记录进行加锁，此时则会锁住（10，max】、（max，正无穷）区间。所以此时插入大于10的都不行。（等于10的要搭配主键一起看是否能插入）。
同理，此时如果b=7 for update，
此时则会在8上加gap锁（gap before rec即锁住前面区间），即锁住了（6，8）区间。
如果lock_mode后面没有提示使用什么锁，则默认是net-key锁。
在RC级别中，如果对不存在的记录加锁，此时不会加任何锁，因为RC不需要解决幻读问题。
如果我们现在查询时没用索引？？
例如我们现在往表再假如一个列c，然后执行c=100 for update；（100的记录存在，且其对应的主键列值为4）。1、RC情况下：
此时我查看加锁情况：
这里可以知道此时如果sql没用到索引，此时会对对应的主键进行加锁。
2、RR情况下：
查看锁情况：
此时会发现锁住的范围：
即相当于锁住了所有记录。此时锁的代价就会很大。
那为什么要锁全表？？？
这也是为了防止幻读。我们都知道，c不是索引，非唯一的二级索引列会锁主键和二级索引，所以重复的值也不用锁全表就可以保证幻读问题，而非索引字段此时的范围太大需要锁全部。
在RC级别下：
此时会话1先删除小于等于7，此时对这四个值加记录锁。所以会话2是可以插入的。
此时我们再看看这个过程binlog日志是怎么记录的：（记录先提交的）
此时因为会话2先提交，此时先记录insert 2，然后再记录del 。
那么此时如果mysql中存在主从结构，需要用binlog日志做同步。此时就会出现：
此时先insert 2，所以slave的数据是1、2、3、5、7。然后再执行del操作，此时所有记录都会被删掉。那么此时就存在主从数据不一致的问题了。
那么此时怎么解决？？
此时就要设置一个参数为row。
此时binlog记录时，就不是直接记录del 小于等于7，而是记录del 1、del 3、del 5、del 7。
这样就不会存在数据不一致的情况了。
（RC级别下的binlog_format一定要设置为row，防止主从数据不一致的情况）
此时要是del操作比较久，那会不会存在删到一半，insert 2插入了，然后把2也删了？？
——不管是RC或者RR，del的过程是不会看到2的插入的。（readview或者锁机制决定了看不到），所以不存在因为del太久把2也给删了的情况。
readview：用来判断某条记录的可见性。
RR级别的MVVC机制+readview可以解决幻读？？？
- RR隔离级别，如果事务中都是快照读，或者全都是当前读，都不会产生幻读。只有当前读和快照读混用，才会产生幻读。
- MVCC保证快照读不会幻读
- next-key lock（间隙锁）保证当前读不会产生幻读
插入意向锁算法：
在RC中：
在事务中插入一条数据：
然后查看mysql中锁情况，发现没有加锁的信息。
此时再开一个事务去select 刚才插入的 那条记录，此时却需要进行等待。再次去查看锁情况发现之前的那个insert语句的锁信息又出现了。
那么为什么之前insert的时候查看锁信息是没有的？？？
——innodb对其做了优化，insert的锁是隐式锁，就是不创建锁对象（减少内存消耗），当其他会话用到该记录了需要等待，此时才创建锁对象转换为显式锁。（类似于懒加载）
插入意向锁提升插入性能：
死锁：
等待图：自动进行死锁检测
会根据锁的信息链+事务等待链推断出是不是存在死锁回路。
如果存在则回滚某个事务（通过undo的量来判断回滚的事务，回滚量比较少的）。
show engine innodb status只会显示最后一次死锁的信息。
如果要记录所有死锁信息：开启参数innodb_print_all_deadlocks
可以在配置文件中配置：
这样死锁的信息都会记录到错误日志里面。
其中innodb_deadlock_detect参数可以关闭自动死锁检测。
mysql8.0新语法：
如果某行数据被锁了，此时使用下面进行加锁：
notwait就是不进行阻塞等待直接返回错误信息。
skip locked：对被加锁的行数据直接跳过。
a
206
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
