首页  流程图  详情

mysql

2022-08-09 11:56:45   37  举报





mysql的结构，事务，锁机制等等一系列汇总....

MySQL

作者其他创作

大纲/内容

ROW

ib_logfile1

WAL:writer-ahead-Logging先写日志，在写磁盘

1.业务1执行update操作后，事务A向数据库拉取原数据存放到UndoBuffer 中 2.更新的数据存放到缓冲区User中，此时还没有提交事务A 3.事务B发起了一个select操作，我们直接读取Undo buff中的快照数据 4.如果事务A发出rollback 操作，那我们可以直接使用Undobuff 中的旧数据进行回滚 5.如果事务A做了commit操作，那cache中的User在某一时刻会持久到Disk中

获取version

Caches & Buffer（global and engine specific caches && buffer）

red

data

Federated

buffer-pool（缓冲池）

约束一致性数据一致性

并发事务处理四：\"MVCC\"在事务1开始写操作的时候会copy一个记录的副本，其他事务读操作会读取这个记录副本，因此不会影响其他事务对此记录的读取，实现写和读并行

数据库

t2.ibd

Undo Buff

查询缓存

Undo Log

查询执行引擎

cluster

No-leaf node segment(d索引段)

16k

索引原理二HASH结构

1非叶子节点不存储data数据，只存储索引值，这样便于存储更多的索引值2叶子节点包含了所有的索引值和data数据3叶子节点用指针连接，提高区间的访问性能与B树比较：B+树进行范围查找时，只需要查找定位两个节点的索引值，然后利用叶子节点的指针进行遍历即可。而B树需要遍历范围内所有的节点和数据，显然B+Tree效率高

某一个事务发生后，就会产出新数据存放到redo buff中，当事务提交后就会将数据写入到redo Log中，此时还不会立刻写入磁盘，如果服务器出现问题，我们就可以使用red log 恢复数据写入到磁盘中，保证了数据的完整性。

产生死锁与解决方案

表锁死锁产生原因：事务A： >表A(锁)->表B(锁)事务B： >表B(锁)->表BA锁)解决：这种死锁比较常见，是由于程序的BUG产生的，除了调整的程序的逻辑没有其它的办法。仔细分析程序的逻辑，对于数据库的多表操作时，尽量按照相同的顺序进行处理，尽量避免同时锁定两个资源，如操作A和B两张表时，总是按先A后B的顺序处理，必须同时锁定两个资源时，要保证在任何时刻都应该按照相同的顺序来锁定资源。

Archive

Extent

User3 name='王五'

write

🔐

复合

WAL

Cache/Buffer

在InnoDB中使用了大量的AIO（Async IO）来做读写处理，这样可以极大提高数据库的性能。在InnoDB1.0版本之前共有4个IO Thread，分别是write，read，insert buffer和log thread，后来版本将read thread和write thread分别增大到了4个，一共有10个了

Parser（Query Translation、Object Privilege）

B更新version

预处理器

Tr1

Master thread是InnoDB的主线程，负责调度其他各线程，优先级最高。作用是将缓冲池中的数据异步刷新到磁盘，保证数据的一致性。包含：脏页的刷新（page cleaner thread）、undo页回收（purge thread）、redo日志刷新（log thread）、合并写缓冲等。内部有两个主处理，分别是每隔1秒和10秒处理。

MyISAM

事务A

BTree

持久

索引存储结构

mysql事务和锁机制

Tr2

发送sql

InnoDb

IO Thread

结果

Disk

A更新version

A获取version

二分查找法也叫作折半查找法，它是在有序数组中查找指定数据的搜索算法。它的优点是等值查询、范围查询性能优秀，缺点是更新数据、新增数据、删除数据维护成本高。

name='李四'

并发事务处理二：排它锁或叫互斥锁，先进入的事务独占数据项以后，其他事务被阻塞，等待前面的事务释放锁。

Undo TableSpaces

一个表至少有两个段，一个数据段一个索索段

innodb_file_per_table=ON开启时创建表存在独立空间

osc

field1

要么全部执行要不全部不执行

Innodb 线程模型

HASH函数

Rollback-segment(回滚段)

name='王五'

R Tree

General TableSpace(通用表空间)

唯一索引外键约束check约束

文件

MVCC

数据完整性

name='赵六'

恢复新数据

t1.ibd

使用乐观锁不冲突流程：事务A获取版本号，做业务处理后更新版本号事务B在事务A后获取版本号，业务处理后更新版本号

聚集(聚簇)

ON-Disk-structuces(磁盘结构)

7为我们要查询的结果mid=（L-R）/2 =4

mysql 索引汇总

Gap/RRROW/RC

merge

sys-TableSpace（系统表空间：ibdata1）

File-per-table-TableSpace(独立表空间)

myIsam

Innodb数据存储结构

隔离性

备份新数据

Redo Log

IInnodb_引擎完整结构

并发事务处理一：最初的实现都是以排下队的形式处理并发事务的，性能很差

operating-system-cache操作系统缓存

事务特性原型

索引键值类型

事务提交之后，其使用的undo日志将不再需要，因此需要Purge Thread回收已经分配的undo页。

name='张三'

Roll pointer

一致性

Undo_002

索引类型

RedoLog工作原理

Pluggable Storage Enginesmemory index & storage management

隔离级别

Leaf node segment(数据段)

Temporary TableSpaces(临时表空间 )

.............

备份旧数据

Field pointers

HASH

提交固化错误操作

主键

API接口

第一次查询

使用乐观锁冲突流程：事务A获取版本号，做业务处理后更新版本号事务B在事务A没有提交前同时获取版本号，业务处理后更新版本号发现version版本已经被更新了，此时不会产生异常，也不会有记录被更新

B更新版本号时产生冲突

mysql集群架构

缓存命中直接返回

Redo Buff

.....

Segment 1

读未提交读提交可重复读可串行化

行锁死锁产生原因1：如果在事务中执行了一条没有索引条件的查询，引发全表扫描，把行级锁上升为全表记录锁定（等价于表级锁），多个这样的事务执行后，就很容易产生死锁和阻塞，最终应用系统会越来越慢，发生阻塞或死锁。解决：SQL语句中不要使用太复杂的关联多表的查询；使用explain“执行计划\"对SQL语句进行分析，对于有全表扫描和全表锁定的SQL语句，建立相应的索引进行优化。-----------------------------------------------------------------------------------产生原因2：两个事务分别想拿到对方持有的锁，互相等待，于是产生死锁。事务A->锁 id=1 需要id=2事务B->锁id=2 需要id=1解决：在同一个事务中，尽可能做到一次锁定所需要的所有资源按照id对资源排序，然后按顺序进行处理

Redo/Undo

乐观锁原理

原子性

新解析树

User.db

事务B

加载

这是一个简单的例子，通过二分进行一次查询就定位到了我们要查询的 7的下标

Undo Buffer

应用层次结构

查询优化器

③COMMIT/ROLLBACK