有赞商城网站建设,建设网站一般多少钱,大型网站设计首页实例,深圳燃气公司电话号码MySQL之InnoDB引擎 简介逻辑存储结构InnoDB架构内存架构缓冲池LRU List、Free List和Flush List更改缓冲区#xff08;在5.x版本之前叫做插入缓冲区#xff09;自适应hash日志缓冲区 磁盘架构System TablespaceFile Per Table TabspaceGeneral TablespceUndo TablespaceTemp … MySQL之InnoDB引擎 简介逻辑存储结构InnoDB架构内存架构缓冲池LRU List、Free List和Flush List更改缓冲区在5.x版本之前叫做插入缓冲区自适应hash日志缓冲区 磁盘架构System TablespaceFile Per Table TabspaceGeneral TablespceUndo TablespaceTemp TablespaceDoublewrite Buffer FilesRedo Log 后台线程Master ThreadIO ThreadPurge ThreadPage Cleaner Thread 事务原理特性持久性redo log来保证原子性undo log来保证隔离性MVCC和锁前置概念当前读快照读 MVCC隐藏字段undo日志undo日志版本链readview Checkpoint技术思考 简介
InnoDB通过使用多版本并发控制MVCC来获得更高的并发性并实现了SQL标准的四种隔离级别。设计主要目标是面向在线事务处理OLTP使用next-key-locking策略来避免幻读。提供插入缓冲insert buffer、二次写double write、自适应哈希索引adaptive hash index、预读read ahead、刷新邻接页Flush Neighbor Page等高性能高可用的功能。如果没有显式定义主键引擎会生成一个6字节的row-id作为主键。InnoDB存储引擎是多线程模型后台有多个不同的线程负责处理不同的任务。大量使用AIO来处理IO请求这样可以极大提高数据库的性能。InnoDB是通过LSNLog Seqence Number来标记版本的。LSN是8个字节的数字。每个页、重做日志、Checkpoint都有LSN。
逻辑存储结构 表空间Tablespace-段Segment-区Extent-页Page-Row行 表空间ibd文件一个mysql实例可以对应多个表空间用于存储记录、索引等数据。 段分为数据段Leaf node segment和索引段Non-leaf node segment、回滚段Rollback segmentInnoDB是索引组织表数据段就是B数的叶子节点索引段就是B树的非叶子节点。段用来管理多个区。 区表空间的单元结构每个区的大小为1M默认情况下InnoDB存储引擎页大小为16KB即一个区中共有64个连续的页。 页InnoDB存储引擎磁盘管理的最小单元每个页的大小默认为16KB。为了保证页的连续性InnoDB存储引擎每次空磁盘申请4-5个区。 行InnoDB存储引擎数据是按行进行存放的。Trx_id每次对莫条记录进行改动时都会把对应的事务id赋值给trx_id隐藏列。Roll_pointer每次对某条引记录进行改动时都会把旧的版本写入到undo日志中然后这个隐藏列就相当于一个指针可以通过它来找到该记录修改前的信息。
InnoDB架构 内存架构
缓冲池
InnoDB的记录按照页的方式进行管理底层采用链表的数据结构进行管理。缓冲池就是一块内存区域用来弥补磁盘速度慢对数据库性能的影响。数据库读页操作时先将磁盘读到的页放入缓冲池将页FIX到缓冲池下次在读取就走内存内存没有就走磁盘。对于页的修改首先在缓冲池修改然后再以一定的频率刷新到磁盘不是每次页更新都会发生而是通过一种Checkpoint的机制刷新回磁盘。减少磁盘IO加快处理速度。缓冲池的数据页类型有如下几种索引页和数据页占的最多 索引页数据页undo页插入缓冲自适应哈希索引InnoDB存储的锁信息lock info数据字典信息data dictionary 缓冲池以Page为单位底层采用链表结构管理Page。根据状态可以将页分为三类
free page空闲page未被使用clean page被使用未被修改dirty page被使用且数据被修改过数据与磁盘数据不一致
LRU List、Free List和Flush List
缓冲池是通过LRU算法进行进行管理的页的大小默认为16KB。LRU列表用来管理已经读取的页数据库刚启动是LRU列表是空的这时的页都在Free列表里。
InnoDB 1.0.x之后支持压缩页的功能将原本16KB的页压缩为1KB、2KB、4KB和8KB非16KB的页通过unzip_LRU列表进行管理。
在LRU列表中的页被修改后该页被称为脏页dirty page这个时候数据库会通过checkpoint机制刷脏而Flush列表即为脏页列表。脏页同时存在于LRU列表和Flush列表LRU用来管理缓冲池的可用性Flush用来管理刷脏二者互不影响。
更改缓冲区在5.x版本之前叫做插入缓冲区
针对于非唯一二级索引在5.x版本之前叫做插入缓冲区8版本之后叫做更改缓冲区。在执行DML语句时如果这些数据Page没有在Buffer Pool中不会直接修改磁盘而是将数据变更保存在更改缓冲区里面。等待以后数据被读取时再将数据合并到Buffer Pool中然后再刷新到磁盘。
Change Buffer的意义 和聚簇索引不同二级索引通常是不唯一的并且插入和删除的顺序是随机的可能会影响索引树中不相邻的二级索引页要是每次都操作磁盘就会造成大量的磁盘IO。所以我们把操作合并在Change Bufer里面减少磁盘IO。
自适应hash
自适应hash索引用于单条数据的查询优化InnoDB会监控对表上索引页的查询如果观察到可以用hash索引提升速度那么就会自己建立hash索引不需要人工干预默认是开启的。 日志缓冲区
用来缓存日志redo log、undo log默认大小16M日志缓冲区会定期刷新到磁盘达到节省磁盘IO的目的。如果需要更新、插入、删除许多行的事务可以增大该缓冲区节省磁盘IO。
innodb_log_buffer_size缓冲区大小
innodb_flush_log_at_trx_commit日志刷盘的时机0表示每秒写入并刷盘1表示每次事务提交时写入并刷盘2表示每次事务提交后写入并每秒刷盘。 InnoDB首先将重做日志放入这个缓冲区然后按照一定的频率刷新到重做日志文件该缓冲区不用设置很大一般每一秒钟都会刷新日志文件用户只需要保证每秒钟产生的事务量在这个大小之内即可。
下列三种情况会刷新重做日志
Master Thread每秒钟刷新重做日志每个事务提交时重做日志剩余空间小于一半时
磁盘架构
System Tablespace
系统表空间是用来保存修改缓冲区的。如果表不是在每个独立表空间或者通用表空间中创建它也会包含表和索引数据。在MySQL5.x版本中还包含InnoDB数据字典、undolog等。
参数
innodb_data_file_path系统表空间的存储路径 File Per Table Tabspace
每个表的独立表空间包含单个表的数据和索引存储在文件系统上的单个数据文件中默认是开启的。开启后每个数据库都会有一个独立的文件夹如下图是三个不同数据库的文件夹 每个表都会有一个独立的ibd文件下图是learn_ssm数据库的表文件 参数innodb_file_per_table General Tablespce
通用表空间需要自己手动创建后续建表可以指定使用该表空间一般很少用。
创建表空间语法
CREATE TABLESPACE 表空间名称 ADD DATAFILE 表文件名 ENGINE innodb;指定表空间语法
CREATE TABLE (xxx) ENGINEinnodb TABLESPACE 表空间名称创建测试表空间 创建成功之后在mysql目录下可以找到test.ibd文件 Undo Tablespace
撤销表空间MySQL实例在初始化时会自动创建两个默认的undo表空间初始大小16M用于存储undo log日志。
在MySQL目录下可以找到这两个文件 Temp Tablespace
主要用来存储用户创建的一些临时表。
Doublewrite Buffer Files
双写缓冲区InnoDB引擎在刷脏前会先将页写入到双写缓冲区文件里面便于系统异常时恢复数据。
可以在MySQL目录下找到两个双写缓冲区文件 Redo Log
重做日志用来实现事务的持久性由重做日志缓冲在内存和重做日志文件在磁盘两部分组成。当事务提交之后会把所有的修改信息都存到该日志中用于在刷脏发生错误时进行数据恢复。RedoLog是循环写入的不会永久保存。
后台线程
Master Thread
这是一个非常核心的线程主要负责调度其他线程将缓冲池的数据异步刷新到磁盘保证数据一致性包括刷脏、合并插入缓冲、UNDO页的回收等。
IO Thread
该线程主要负责AIO请求的回调处理。
线程类型默认个数职责Read thread4负责读操作Write thread4负责写操作Log thread1将日志刷新到磁盘Insert buffer thread1将写缓冲区内容刷新到磁盘
Purge Thread
用来回收已经使用并分配的undo页从InnoDB1.1开始purge操作可以独立到单独的线程来减轻Master Thread的工作。用户可以在配置文件添加如下命令来启动独立的purge线程
[mysqld]
innodb_purge_thread1Page Cleaner Thread
该线程是1.2.x版本引入的单独用来做脏页刷新减轻 Master Thread 的工作减少阻塞。
事务原理
事务时一组操作的集合不可分割的工作单位事务的四大特性ACID
特性
原子性A不可分割要么全部成功要么全部失败一致性C事务完成所有数据都保持一致隔离性I根据隔离机制保证事务不受外部并发操作下独立运行持久性D一旦提交或者回滚它对数据库的改变就是永久的
ACD是由redo log和undo log来保证的I是由锁机制和MVCC来保证的。
持久性redo log来保证
持久性是有redo log来保证的。当缓冲区数据更改时会把修改的数据保存到redo log buffer中在事务提交的时候会把redo log buffer刷到redo log文件里。
如果后面在刷脏的时候出错了就可以通过redo log来恢复因为redo log记录了当次数据的变化。
如果刷脏成功那么redo log里的记录就没有意义了所以每隔一段时间就会去清理redo log日志。
为什么每次事务提交都把redo log刷新到磁盘而不是直接刷新数据
可以直接刷新数据但是存在严重的性能问题。因为一个事务通常会操作很多条记录而这些记录所在的数据页都是随机的会造成大量的随机磁盘IO。但是我们刷日志文件的话日志文件都是顺序追加的所以速度很快。
如果日志刷盘的时候失败了怎么办
原子性undo log来保证
回滚日志用来记录数据被修改前的信息作用包含两个提供回滚的MVCC在多版本并发控制的时候可以依据undo log来找到记录的历史版本。
redo log记录的是物理记录即记录真实的数据而undo log是逻辑记录记录的是每一步的反向操作可以认为执行delete的时候undo log会有一条相反的insert操作执行update操作的时候会有一条相反的update操作。当事务回滚时就会执行对应的反向操作恢复成之前的数据这样就会保证事务的原子性。
undo log销毁一旦事务提交或者回滚那么这份undo log也就不需要了但是它不会立即去删除还会去检查MVCC会不会用到该日志。
undo log存储采用段的方式进行管理和存储存放在rollback segment回滚段中里面包含1024个undo log segment。
隔离性MVCC和锁
前置概念
当前读
读取的是记录的最新版本读取的时候保证其他并发事务不能修改当前记录所以会对记录进行枷锁。如
SELECT ... LOCK IN SHARE MODE # 共享锁
SELECT ... FOR UPDATE、 INSERT、 DELETE # 排他锁这些锁都是一种当前读。
下面演示一下当前读
首先我们打开两个MySQL连接选择了learn_ssm数据库展示了tb_user表的数据 然后我们使用begin分别开启两个事务 在第二个连接里面修改一条记录这个时候事务还没有提交我们在第一个连接里面查看发现读取不到修改 当我们提交事务之后发现第一个连接还是读取不到修改 这是因为InnoDB默认的隔离级别是可重复读所以不会感知到其他事务的修改这个时候我们在第一个连接里面加上当前读的锁就可以得到最新的数据 这个就是当前读的作用用来获取记录的最新版本。
快照读
简单的不加锁的select语句就是快照读读取的是记录数据的可见版本有可能是历史数据不加锁所以它是非阻塞的。
Read Committed每一次select都会产生一个快照读Repeatable Read开启事务后第一个select语句才是快照读后面读的都是前面产生的快照Serializable快照读会退化成当前读每一次读都会加锁
MVCC
全称 Multi-Version-Concurrency-Control多版本并发控制。维护一个数据的多个版本使得读写操作没有冲突快照读给MVCC提供了非阻塞读功能。当我们在快照读的时候就要通过MVCC来获取记录的历史版本。MVCC的实现还依赖于数据记录里的三个隐藏字段、undo日志和readView。
隐藏字段
隐藏字段作用DB_TRX_ID最近一次修改或插入该记录的事务的IDDB_ROLL_PTR回滚指针指向这条记录的上一个版本配合undo日志一起使用DB_ROW_ID隐藏主键如果这张表没有人为设置主键那么就会生成这个字段作为记录的主键
我们可以使用ibd2sdi命令查看ibd文件信息在这里我们可以看到这些隐藏字段
首先进入数据库目录然后输入 ibd2sdi tb_user.ibd 查看文件信息 在columns下面我们可以找到最近事务ID和回滚指针 undo日志
当insert的时候产生的undo日志只在回滚时需要所以在事务提交后可以被立即删除。
而update、delete的时候产生的undo日志在回滚和快照读的时候都需要不会被立即删除。
undo日志版本链 在记录未被修改之前回滚指针指向null。当我们在事务2里面对记录进行修改InnnoDB会在undo日志里面保存修改之前的版本然后用在记录的新版本里面用回滚指针指向老版本记录的地址事务id为修改记录的事务的id。
后面的事务3和4的修改也是同样的操作这样一来我们就得到了一条链表链表头节点为记录的最新版本链表尾节点为记录的最老版本我们可以通过这样一条链表进行记录的回滚操作。
readview
读视图是快照读的时候MVCC提取数据的依据记录和维护当前未提交的事务id包含如下字段
字段含义m_ids未提交事务id集合min_trx_id最小未提交事务idmax_trx_id预分配事务id最大未提交事务id1因为事务id是自增的creator_trx_idreadview创建者的事务id也就是当前查询事务的id
快照读是使用记录的事务id字段去读取的具体读取规则如下 当前记录的事务id等于creator_trx_id也就是说这条记录是我们自己修改的那么就可以读取。 否则我们就找不超过max_rtx_id且已经提交了的事务也就是小于min_trx_id的事务和在min和max之间但是不在m_ids内的事务就是我们要找的那条记录。 如果上述条件都不符合那么我们就根据undo版本链表回滚记录直到找到一个符合条件的记录。
因为是在undo日志版本链的记录是从新到旧的所以我们找到的一定是提交的事务里最新的那条记录。
不同隔离级别生成readview的时机
READ COMMITTED每次查询都会生成所以该隔离级别的每次查询都是快照读。
REPEATABLE READ只在第一次查询的时候生成后面的查询都是复用第一次也是因为这个原因保证了重复读。
下图是在 READ COMMITTED 隔离级别下的情况 Checkpoint技术
如果在刷脏的时候宕机那么数据就不能恢复了为了避免这个问题当前事务数据库都采用了Write Ahead Log 策略即当事务提交时先写重做日志再修改页宕机之后就可以通过重做日志来恢复。
Checkpoint目的是解决以下几个问题
缩短数据库恢复时间缓存池不够用时开始刷脏重做日志不可用时开始刷脏
当数据库宕机时不需要重做所有日志因为Checkpoint之前的页已经刷回了磁盘只需要对Checkpoint之后的重做日志进行恢复大大缩短了恢复时间。
当LRU算法淘汰的页是脏页时需要强制执行Checkpoint刷脏。
重做日志的设计是循环使用的被重用都是不需要的部分因此可以覆盖使用若此时重做日志还需要使用就必须强行产生Checkpoint刷脏。
InnoDB有两种Checkpoint
Sharp Checkpoint将所有脏页刷回磁盘发生在数据库关闭时。Fuzzy Checkpoint只刷新部分脏页而不是所有发生在数据库运行时。
Fuzzy Checkpoint发生的几种情况
Master ThreadFLUSH_LRU_LIST Checkpoint保证LRU列表有100个空闲页没有就从尾部移除要是有脏页就进行Chekpoint。Async/Sync Flush Checkpoint重做日志不可用的情况为了保证重做日志循环使用的可用性。Dirty Page too much Checkpoint脏页太多当脏页数量占据75%时强制进行Checkpoint刷新一部分脏页到磁盘。
思考
在可重复读的隔离级别下分别开启两个事务A和B。在B事务里面插入一条记录的时候A事务开启共享锁再去查询的时候发现卡死了直到B事务提交A事务才继续执行在B事务里面修改记录也一样会卡死。为什么A事务会卡死
因为在事务修改的时候会给对应的记录加上行锁只有在事务提交之后才会释放锁。所以A事务去读取时因为有锁所以就一直卡在那了直到事务B提交释放锁事务A才能够上锁进而读取数据。
在串行化隔离级别下事务B插入一条主id13的数据然后事务A去查询id13的数据发现卡住了。然后如果这种情况发生在可重复度的隔离级别下事务A不会卡住会返回空记录但是如果事务A开启共享锁去查的话事务A也会卡住。为什么会发生这种情况
