前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >InnoDB学习笔记之一

InnoDB学习笔记之一

作者头像
AsiaYe
发布2019-11-06 15:26:48
3610
发布2019-11-06 15:26:48
举报
文章被收录于专栏:DBA随笔DBA随笔

InnoDB学习笔记

简要介绍

innodb存储引擎是第一个完整支持ACID事务的MySQL存储引擎,其特点是行锁设计、支持MVCC、支持外键、提供一致性非锁定读。从MySQL5.1版本开始,MySQL数据库允许存储引擎开发商以动态的方式加载引擎,这样存储引擎的更新可以不受MySQL数据库版本的限制。从MySQL5.5版本开始,它是默认的表存储引擎。

体系架构

InnoDB存储引擎的体系架构如下图所示:

图中可以看到,InnoDB存储引擎有多个内存块,可以认为这些内存块组成了一个大的内存池,内存池的主要工作有如下几种:

  • 维护所有进程/线程需要访问的多个内存数据结构
  • 缓存磁盘上的数据,方便快速的读取,同时在对磁盘文件的数据修改之前在这里缓存
  • 重做日志redo log缓冲。

1.后台线程

innodb存储引擎是多线程模型,它的后台有多个不同的线程,负责不同的任务,这里简单介绍一下:

1.1 Master Thread

这是一个核心的后台线程,主要负责将缓冲池中的数据一步刷新到磁盘,保证数据的一致性,包括脏页的刷新、合并插入缓冲、UNDO页的回收等。

1.2 IO Thread

在InnoDB存储引擎中使用了大量的Async IO来处理IO请求,这样可以极大的提高数据库的性能,而IO线程的主要工作是负责这些IO请求的回调处理。

1.3 Purge Thread

事务被提交之后,其所使用的undolog可能不再需要,因此需要PurgeThread来回收已经使用并分配的undo页,以前Purge Thread是集成在Master Thread中的,从InnoDB1.1版本开始,purge操作可以独立到单独的线程中执行,从而提高CPU的使用率以及提升存储引擎的性能。InnoDB1.2版本开始,InnoDB支持多个Purge Thread,其目的是为了进一步加快undo页的回收。

1.4 Page Cleaner Thread

该线程的作用是将之前版本中的脏页的刷新操作都放入到单独的线程中来完成。而目的是为了减轻原Master Thread的工作以及对于用户查询线程的阻塞,从而提高Innodb存储引擎的性能。

2.内存

2.1 缓冲池

缓冲池简单来说就是一块内存区域,通过内存的速度来弥补磁盘速度较慢对数据库性能的影响,在数据库中进行读取页的操作,首先将从磁盘督导的页放到缓冲池中,下一次再督导相同的页时,首先判断该页是否在缓冲池中,若在,则该页在缓冲池中被命中,否则读取磁盘上的页。

对于InnoDB而言,缓冲池通过innodb_buffer_pool_size来设置,

代码语言:javascript
复制
mysql ::>>show variables like 'innodb_buffer_pool_size';
+-------------------------+-----------+
| Variable_name           | Value     |
+-------------------------+-----------+
| innodb_buffer_pool_size |  |
+-------------------------+-----------+
 row in set (0.00 sec)

缓冲池中缓存的数据类型还有:索引页、数据也、undo页、插入缓冲、自适应哈希索引、Innodb存储引擎的所信息、数据字典信息等。如下图所示:

如果我们想增加缓冲池的实例,可以通过innodb_buffer_pool_instances来进行配置,在配置文件中将innodb_buffer_pool_instances设置为大于1的值就可以得到多个缓冲池实例。使用show engine innodb status可以查看每个缓冲池的状态。

代码语言:javascript
复制
mysql> show engine innodb status\G
*************************** 1. row ***************************
  Type: InnoDB
  Name: 
Status: 
=====================================
-11-20 :: 0x7fbbc84b0700 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last  seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops:  srv_active,  srv_shutdown,  srv_idle
srv_master_thread log flush and writes: 
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 
OS WAIT ARRAY INFO: signal count 
RW-shared spins , rounds , OS waits 
RW-excl spins , rounds , OS waits 
RW-sx spins , rounds , OS waits 
Spin rounds per wait: 626.00 RW-shared, 184.00 RW-excl, 0.00 RW-sx
------------
TRANSACTIONS
------------
Trx id counter 
Purge done for trx's n:o < 184678 undo n:o < 0 state: running but idle
History list length 
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION , not started
 lock struct(s), heap size ,  row lock(s)
---TRANSACTION , not started
 lock struct(s), heap size ,  row lock(s)
---TRANSACTION , not started
 lock struct(s), heap size ,  row lock(s)
--------
FILE I/O
--------
I/O thread  state: waiting for completed aio requests (insert buffer thread)
I/O thread  state: waiting for completed aio requests (log thread)
I/O thread  state: waiting for completed aio requests (read thread)
I/O thread  state: waiting for completed aio requests (read thread)
I/O thread  state: waiting for completed aio requests (read thread)
I/O thread  state: waiting for completed aio requests (read thread)
I/O thread  state: waiting for completed aio requests (write thread)
I/O thread  state: waiting for completed aio requests (write thread)
I/O thread  state: waiting for completed aio requests (write thread)
I/O thread  state: waiting for completed aio requests (write thread)
Pending normal aio reads: [, , , ] , aio writes: [, , , ] ,
 ibuf aio reads:, log i/o's:, sync i/o's:
Pending flushes (fsync) log: ; buffer pool: 
 OS file reads,  OS file writes,  OS fsyncs
0.00 reads/s,  avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size , free list len , seg size ,  merges
merged operations:
 insert , delete mark , delete 
discarded operations:
 insert , delete mark , delete 
Hash table size , node heap has  buffer(s)
Hash table size , node heap has  buffer(s)
Hash table size , node heap has  buffer(s)
Hash table size , node heap has  buffer(s)
Hash table size , node heap has  buffer(s)
Hash table size , node heap has  buffer(s)
Hash table size , node heap has  buffer(s)
Hash table size , node heap has  buffer(s)
0.00 hash searches/s, 0.00 non-hash searches/s
---
LOG
---
Log sequence number 
Log flushed up to   
Pages flushed up to 
Last checkpoint at  
 pending log flushes,  pending chkp writes
 log i/o's done, 0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total large memory allocated 
Dictionary memory allocated 
Buffer pool size   
Free buffers       
Database pages     
Old database pages 
Modified db pages  
Pending reads      
Pending writes: LRU , flush list , single page 
Pages made young , not young 
0.00 youngs/s, 0.00 non-youngs/s
Pages read , created , written 
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
No buffer pool page gets since the last printout
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: , unzip_LRU len: 
I/O sum[]:cur[], unzip sum[]:cur[]
--------------
ROW OPERATIONS
--------------
 queries inside InnoDB,  queries in queue
 read views open inside InnoDB
Process ID=, Main thread ID=, state: sleeping
Number of rows inserted , updated , deleted , read 
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================

 row in set (0.00 sec)

第82行下面就是buffer pool的详细内容,这里需要说明的是,关于缓冲池,还有很多细节的内容,明天将使用一篇文章详细展开。

2.2 重做日志缓冲

InnoDB存储引擎除了有缓冲池外,还有重做日志缓冲,InnoDB存储引擎首先将重做日志信息放入到这个缓冲区,然后按照一定频率将其刷新到重做日志文件中,重做日志缓冲一般不需要设置的很大,因为一般情况下每一秒钟会将重做日志刷新到日志文件中,因此用户只需要保证每秒产生的事务在这个缓冲大小之内即可。该值可以由innodb_log_buffer_size来控制,默认为8MB。

重做日志在下列三种情况下会将重做日志缓冲中的内容刷新到外部磁盘的重做日志文件中。

  • Master Thread每一秒将重做日志缓冲刷新到重做日志文件
  • 每个事务提交时会将重做日志缓冲刷新到重做日志文件
  • 当重做日志缓冲池剩余空间小于1/2时,重做日志缓冲将刷新到重做日志文件

2.3额外的内存池

在InnoDB中,内存的管理是通过一种称为内存对的方式进行的,在对一些数据结构本身的内存进行分配时,需要从额外的内存池中进行申请,当该区域的内存不够时,会从缓冲池中进行申请。例如,分配了缓冲池,但是缓冲池中的帧缓冲还有相应的缓冲控制对象,这些对象记录了一些诸如LRU、锁等信息,而这个对象的内存需要从屋外的内存池中申请。因此,申请了大的InnoDB缓冲池时,也应该考虑增大额外内存池的值。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2018-11-20,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 DBA随笔 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
对象存储
对象存储(Cloud Object Storage,COS)是由腾讯云推出的无目录层次结构、无数据格式限制,可容纳海量数据且支持 HTTP/HTTPS 协议访问的分布式存储服务。腾讯云 COS 的存储桶空间无容量上限,无需分区管理,适用于 CDN 数据分发、数据万象处理或大数据计算与分析的数据湖等多种场景。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档