2. InnoDB存储引擎

2.1 InnoDB存储引擎概述

InnoDB 存储引擎最早由 Innobase Oy 公司开发,被包括在 MySQL 数据库所有的二进制发行版本中,从 MySQL 5.5 版本开始是默认的表存储引擎(之前的版本 InnoDB存储引擎仅在 Windows 下为默认的存储引擎)。该存储引擎是第一个完整支持 ACID 事务的 MySQL 存储引擎(BDB 是第一个支持事务的 MySQL 存储引擎,现在已经停止开发),其特点是行锁设计、支持 MVCC、支持外键、提供一致性非锁定读,同时被设计用来最有效地利用以及使用内存和 CPU。
Heikki Tuuri(1964 年,芬兰赫尔辛基)是InnoDB 存储引整的创始人,和著名的Linux 创始人 Linus 是芬兰赫尔辛基大学校友。在 1990 年获得赫尔辛基大学的数学逻辑
博士学位后,他于1995 年成立 Innobase Oy 公司并担任 CEO。同时,在 InnoDB存储引擎的开发团队中,有来自中国科技大学的 Calvin Sun。而最近又有一个中国人 Jimmy Yang 也加入了InnoDB 存储引擎的核心开发团队,负责全文索引的开发,其之前任职于 Sybase 数据库公司,负责数据库的相关开发工作。
InnoDB存储引擎已经被许多大型网站使用,如用户熟知的 Google、Yahoo!、 Facebook、YouTube、Flickr,在网络游戏领域有《魔兽世界》、《Second Life》、《神兵玄奇》等。我不是 MySQL 数据库的布道者,也不是 InnoDB 的鼓吹者,但是我认为当前实施一个新的 OLTP 项目不使用 MySOL InnoDB 存储引擎将是多么的愚蠢。
从 MySQL 数据库的官方手册可得知,著名的 Internet 新闻站点 Slashdot.org运行在 InnoDB 上。Mytrix、Inc.在 InnoDB上存储超过1TB 的数据,还有一些其他站点在 InnoDB上处理插入/更新操作的速度平均为 800 次/秒。这些都证明了InnoDB 是一个高性能、高可用、高可扩展的存储引擎。
InnoDB存储引擎同 MySQL 数据库一样,在 GNU GPL 2下发行。更多有关 MySQL证书的信息,可参考 http∶//www.mysql.com/about/legal/,这里不再详细介绍。

2.2 InnoDB 存储引擎的版本

  • 从 MySQL 5.1 版本时,MySQL 数据库允许存储引擎开发商以动态方式加载引擎,这样存储引擎的更新可以不受 MySQL 数据库版本的限制。
  • 所以在 MySQL 5.1中,可以支持两个版本的 InnoDB,一个是静态编译的 InnoDB 版本,可将其视为老版本的 InnoDB;另一个是动态加载的 InnoDB 版本,官方称为 InnoDB Plugin,可将其视为 InnoDB 1.0.x版本。MySQL5.5版本中又将 InnoDB 的版本升级到了
    1.1.x。
    而在最近的 MySQL 5.6 版本中InnoDB的版本也随着升级为1.2.x 版本。表2-1 显示了各个版本中 InnoDB存储引擎的功能。
    在这里插入图片描述

2.3 InnoDB体系结构

InnoDB 存储引擎有多个内存块,可以认为这些内存块组成了—个大的内存池,负责如下工作∶

  • 维护所有进程 / 线程需要访问的多个内部数据结构。
  • 缓存磁盘上的数据,方便快速地读取,同时在对磁盘文件的数据修改之前在这里缓存。
  • 重做日志(redo log)缓冲。
    在这里插入图片描述
    后台线程的主要作用是负责刷新内存池中的数据,保证缓冲池中的内存缓存的是最近的数据。此外将已修改的数据文件刷新到磁盘文件,同时保证在数据库发生异常的情况下 InnoDB 能恢复到正常运行状态。

2.3.1 后台线程

InnoDB 存储引擎是多线程的模型,因此其后台有多个不同的后台线程,负责处理不同的任务。

  1. Master Thread
    Master Thread 是一个非常核心的后台线程,主要负责将缓冲池中的数据异步刷新到磁盘,保证数据的一致性,包括脏页的刷新、合并插入缓冲(INSERT BUFFER)、 UNDO 页的回收等。2.5 节会详细地介绍各个版本中 Master Thread 的工作方式。
  2. IO Thread
    在 InnoDB存储引擎中大量使用了 AIO(Async IO)来处理写 IO 请求,这样可以极大提高数据库的性能。而 IO Thread 的工作主要是负责这些 **IO 请求的回调(call back)**处理。InnoDB 1.0 版本之前共有 4个 IO Thread,分别是 write、read、insert buffer 和 log IO thread。在 Linux 平台下,IO Thread的数量不能进行调整,但是在 Windows 平台下可以通过参数 innodb_file_io_threads 来增大 IO Thread。从 InnoDB 1.0.x 版本开始,read thread和 write thread分别增大到了4个,并且不再使用 innodb_file io_threads 参数,而是分别使用 innodb_read io threads 和 innodb write io threads 参数进行设置。
    在这里插入图片描述
    可以看到IO Thread 0为 insert buffer thread。IO Thread 1为 log thread。之后就是根据参数 innodb read io threads 及 innodb write io threads来设置的读写线程,并且读线程的ID总是小于写线程。
  3. Purge Thread
    事务被提交后,其所使用的 undolog 可能不再需要,因此需要 PurgeThread来回收已经使用并分配的 undo 页。在 InnoDB 1.1版本之前,purge 操作仅在 InnoDB存储引擎的 Master Thread 中完成。而从 InnoDB 1.1 版本开始,purge操作可以独立到单独的线程中进行,以此来减轻 Master Thread 的工作,从而提高 CPU 的使用率以及提升存储引擎的性能。用户可以在 MySQL 数据库的配置文件中添加如下命令来启用独立的 Purge Thread:
[mysq1d]
innodb_purge_threads=1

在 InnoDB 1.1 版本中,即使将 innodb_purge_threads 设为大于1,InnoDB存储引擎启动时也会将其设为 1,并在错误文件中出现如下类似的提示∶

120529 22:54:16[Warning] option'innodb-purge-threads': unsigned value 4 adjusted to 1	

从 InnoDB 1.2 版本开始,InnoDB支持多个 Purge Thread,这样做的目的是为了进一步加快 undo 页的回收。同时由于Purge Thread 需要离散地读取 undo 页,这样也能更进一步利用磁盘的随机读取性能。如用户可以设置 4个 Purge Thread∶
在这里插入图片描述

  1. Page Cleaner Thread
    Page Cleaner Thread 是在 InnoDB 1.2.x 版本中引入的。其作用是将之前版本中脏页的刷新操作都放入到单独的线程中来完成。而其目的是为了减轻原 Master Thread 的工作及对于用户查询线程的阻塞,进一步提高 InnoDB存储引擎的性能。

2.3.2 内存

  1. 缓冲池
  • InnoDB 存储引擎是基于磁盘存储的,并将其中的记录按照页的方式进行管理。因此可将其视为基于磁盘的数据库系统(Disk-base Database)。在数据库系统中,由于 CPU速度与磁盘速度之间的鸿沟,基于磁盘的数据库系统通常使用缓冲池技术来提高数据库的整体性能。
  • 缓冲池简单来说就是一块内存区域,通过内存的速度来弥补磁盘速度较慢对数据库性能的影响。在数据库中进行读取页的操作,首先将从磁盘读到的页存放在缓冲池中,这个过程称为将页"FIX"在缓冲池中。下一次再读相同的页时,首先判断该页是否在缓冲池中。若在缓冲池中,称该页在缓冲池中被命中,直接读取该页。否则,读取磁盘上的页。
  • 对于数据库中页的修改操作,则首先修改在缓冲池中的页,然后再以一定的频率刷新到磁盘上。这里需要注意的是,页从缓冲池刷新回磁盘的操作并不是在每次页发生更新时触发,而是通过一种称为 Checkpoint 的机制刷新回磁盘。同样,这也是为了提高数据库的整体性能。
  • **综上所述,缓冲池的大小直接影响着数据库的整体性能。**由于 32 位操作系统的限
    制,在该系统下最多将该值设置为 3G。此外用户可以打开操作系统的 PAE选项来获得 32 位操作系统下最大 64GB 内存的支持。随着内存技术的不断成熟,其成本也在不断下降。单条 8GB 的内存变得非常普遍,而 PC 服务器已经能支持 512GB 的内存。因此为了让数据库使用更多的内存,强烈建议数据库服务器都采用 64 位的操作系统。
  • 对于 InnoDB 存储引擎而言,其缓冲池的配置通过参数 innodb_buffer_poolsize来设置。下面显示一台 MySQL 数据库服务器,其将 InnoDB存储引擎的缓冲池设置为 15GB。
  • 具体来看,缓冲池中缓存的数据页类型有∶索引页、数据页、undo 页、插入缓冲(insert buffer)、自适应哈希索引(adaptive hash index)、InnoDB存储的锁信息(lock info)、数据字典信息(data dictionary)等。不能简单地认为,缓冲池只是缓存索引页和数据页,它们只是占缓冲池很大的一部分而已。图 2-2 很好地显示了InnoDB 存储引擎中内存的结构情况。
    在这里插入图片描述
  • 从 InnoDB 1.0.x 版本开始,允许有多个缓冲池实例。每个页根据哈希值平均分配到不同缓冲池实例中。这样做的好处是减少数据库内部的资源竞争,增加数据库的并发处理能力。可以通过参数 innodb buffer pool instances 来进行配置,该值默认为1。

在这里插入图片描述

  • 在配置文件中将 innodb buffer pool instances 设置为大于1的值就可以得到多个缓冲池实例。
  • 从 MySQL5.6 版本开始,还可以通过information_schema架构下的表INNODB BUFFER_POOL_STATS来观察缓冲的状态,如运行下列命令可以看到各个缓冲池的使用状态∶
  1. LRU List、Free List和 Flush List
  • 通常来说,数据库中的缓冲池是通过LRU(Latest Recent Used,最近最少使
    用)算法来进行管理的。即最频繁使用的页在 LRU 列表的前端,而最少使用的页在
    LRU列表的尾端。当缓冲池不能存放新读取到的页时,将首先释放 LRU 列表中尾端的页。
  • 在 InnoDB 存储引擎中,缓冲池中页的大小默认为 16KB,同样使用LRU 算法对缓冲池进行管理。 InnoDB 存储引擎对传统的 LRU 算法做了一些优化。
  • 在InnoDB 的存储引擎中,LRU列表中还加入了midpoint 位置。新读取到的页,虽然是最新访问的页,但并不是直接放入到LRU 列表的首部,而是放入到 LRU列表的 midpoint位置。这个算法在 InnoDB 存储引擎下称为 midpoint insertion strategy
  • 在默认配置下,该位置在 LRU 列表长度的 5/8 处。midpoint 位置可由参数innodb old blocks_pct 控制,如∶
    在这里插入图片描述
  • 在 InnoDB 存储引擎中,把 midpoint 之后的列表称为 old 列表,之前的列表称为 new 列表。可以简单地理解为 new列表中的页都是最为活跃的热点数据。
  • 那为什么不采用朴素的 LRU 算法? 这是因为若直接将读取到的页放入到LRU 的首部,那么某些 SOL 操作可能会使缓冲池中的页被刷新出,从而影响缓冲池的效率。常见的这类操作为索引或数据的扫描操作。这类操作需要访问表中的许多页,甚至是全部的页,而这些页通常来说又仅在这次查询操作中需要,并不是活跃的热点数据。如果页被放入 LRU 列表的首部,那么非常可能将所需要的热点数据页从 LRU列表中移除,而在下一次需要读取该页时,InnoDB 存储引擎需要再次访问磁盘。
  • 为了解决这个问题,InnoDB存储引擎引入了另一个参数来进一步管理 LRU 列表,这个参数是 innodb old blocks time,用于表示页读取到 mid 位置后需要等待多久才会被加入到LRU 列表的热端。因此当需要执行上述所说的 SQL 操作时,可以通过下面的方法尽可能使LRU 列表中热点数据不被刷出。
    在这里插入图片描述
    如果用户预估自己活跃的热点数据不止 63%,那么在执行 SQL 语句前,还可以通过下面的语句来减少热点页可能被刷出的概率。
    在这里插入图片描述
  • LRU 列表用来管理已经读取的页,但当数据库刚启动时,LRU 列表是空的,即没有任何的页。这时页都存放在 Free 列表中。当需要从缓冲池中分页时,首先从 Free 列表中查找是否有可用的空闲页,若有则将该页从 Free 列表中删除,放入到LRU列表中。否则,根据LRU 算法,淘汰 LRU 列表末尾的页,将该内存空间分配给新的页。当页从 LRU列表的 old 部分加入到 new 部分时,称此时发生的操作为 page made young,而因为innodb_old_blocks time的设置而导致页没有从 old 部分移动到 new 部分的操作称为 page not made young。可以通过命令 SHOW ENGINE INNODB STATUS 来观察LRU 列表及 Free 列表的使用情况和运行状态。
    在这里插入图片描述
  • 通过命令 SHOW ENGINE INNODB STATUS 可以看到∶当前 Buffer pol size共有 327 679个页,即327679*16K,总共 5GB的缓冲池。
  • Free buffers 表示当前 Free 列表中页的数量。
  • Database pages 表示LRU 列表中页的数量。可能的情况是 Free buffers 与 Database pages 的数量之和不等于 Buffer pool size。正如图 所示的那样,因为缓冲池中的页还可能会被分配给自适应哈希索引、Lock 信息、Insert Buffer 等页,而这部分页不需要 LRU 算法进行维护,因此不存在于LRU 列表中。
  • pages made young 显示了LRU 列表中页移动到前端的次数,因为该服务器在运行阶段没有改变 innodb old blocks time 的值,因此 not young为 0。
  • youngs/s、non-youngs/s表示每秒这两类操作的次数。
  • 这里还有一个重要的观察变量——Buffer pool hit rate,表示缓冲池的命中率,这个例子中为 100%,说明缓冲池运行状态非常良好。通常该值不应该小于 95%。若发生 Buffer pool hit rate 的值小于 95% 这种情况,用户需要观察是否是由于全表扫描引起的 LRU 列表被污染的问题。

执行 SHOW ENGINE INNODB STATUS 显示的不是当前的状态,而是过去某个时间范围内 InnoDB 存储引擎的状态。从上面的例子可以发现,Per second averages calculated from the last 24 seconds 代表的信息为过去 24 秒内的数据库状态。

从 InnoDB 1.2 版本开始,还可以通过表 INNODB_BUFFER_POOL_STATS 来观察缓冲池的运行状态,如∶
在这里插入图片描述
此外,还可以通过表INNODB_BUFFER_PAGE LRU 来观察每个LRU 列表中每个页的具体信息,例如通过下面的语句可以看到缓冲池 LRU列表中 SPACE 为1 的表的页类型∶
在这里插入图片描述
在这里插入图片描述

  • InnoDB存储引擎从1.0.x 版本开始支持压缩页的功能,即将原本 16KB 的页压缩为 1KB、2KB、4KB和8KB。而由于页的大小发生了变化,LRU列表也有了些许的改变。对于非 16KB的页,是通过 unzip LRU列表进行管理的。通过命令 SHOW ENGINE INNODB STATUS 可以观察到如下内容∶
    在这里插入图片描述
  • 可以看到LRU 列表中一共有1539 个页,而 unzip_LRU 列表中有 156 个页。这里需要注意的是,LRU中的页包含了 unzip LRU 列表中的页。
  • 对于压缩页的表,每个表的压缩比率可能各不相同。可能存在有的表页大小为 8KB,有的表页大小为 2KB 的情况。unzip_LRU 是怎样从缓冲池中分配内存的呢?
  • 首先,在 unzip LRU 列表中对不同压缩页大小的页进行分别管理。其次,通过伙伴算法进行内存的分配。例如对需要从缓冲池中申请页为 4KB 的大小,其过程如下∶
    1)检查 4KB 的 unzip LRU 列表,检查是否有可用的空闲页;
    2)若有,则直接使用;
    3)否则,检查 8KB的 unzip LRU 列表;
    4)若能够得到空闲页,将页分成2 个 4KB 页,存放到 4KB 的 unzip_LRU列表;
    5)若不能得到空闲页,从 LRU列表中申请一个16KB 的页,将页分为1个 8KB的页、2个 4KB的页,分别存放到对应的 unzip LRU 列表中。
    同样可以通过 information_schema 架构下的表 INNODB_BUFFER_PAGE_LRU 来观察 unzip_LRU 列表中的页,如∶
    在这里插入图片描述
  • 在LRU 列表中的页被修改后,称该页为脏页(dirty page)即缓冲池中的页和磁盘上的页的数据产生了不一致这时数据库会通过 CHECKPOINT 机制将脏页刷新回磁盘,而 Flush 列表中的页即为脏页列表。需要注意的是,脏页既存在于LRU列表中,也存在于 Flush 列表中。LRU 列表用来管理缓冲池中页的可用性,Flush 列表用来管理将页刷新回磁盘,二者互不影响。
  • 同 LRU列表一样,Flush列表也可以通过命令 SHOW ENGINE INNODB STATUS来查看,前面例子中 Modified db pages 24673 就显示了脏页的数量。information_ schema架构下并没有类似INNODB BUFFER PAGE LRU 的表来显示脏页的数量及脏页的类型,但正如前面所述的那样,脏页同样存在于LRU列表中,故用户可以通过元数据表 INNODB BUFFER_PAGE LRU 来查看,唯一不同的是需要加入 OLDEST MODIFICATION 大于0的 SQL 查询条件,如∶
    在这里插入图片描述
    可以看到当前共有5 个脏页及它们对应的表和页的类型。TABLE NAME 为 NULL表示该页属于系统表空间。
  1. 重做日志缓冲
  • InnoDB 存储引擎的内存区域除了有缓冲池外,还有重做日志缓冲(redo log buffer)。InnoDB存储引擎**首先将重做日志信息先放入到这个缓冲区,然后按一定频率将其刷新到重做日志文件。**重做日志缓冲一般不需要设置得很大,因为一般情况下每一秒钟会将重做日志缓冲刷新到日志文件,因此用户只需要保证每秒产生的事务量在这个缓冲大小之内即可。该值可由配置参数innodb log buffer size 控制,默认为 8MB。
  • 在通常情况下,8MB 的重做日志缓冲池足以满足绝大部分的应用,因为重做日志在下列三种情况下会将重做日志缓冲中的内容刷新到外部磁盘的重做日志文件中。
  1. Master Thread 每一秒将重做日志缓冲刷新到重做日志文件;
  2. 每个事务提交时会将重做日志缓冲刷新到重做日志文件;
  3. 当重做日志缓冲池剩余空间小于 1/2 时,重做日志缓冲刷新到重做日志文件。

4.额外的内存池
额外的内存池通常被 DBA忽略,他们认为该值并不十分重要,事实恰恰相反,该
值同样十分重要。在 InnoDB 存储引擎中,对内存的管理是通过一种称为内存堆(heap)的方式进行的。在对一些数据结构本身的内存进行分配时,需要从额外的内存池中进行申请,当该区域的内存不够时,会从缓冲池中进行申请。例如,分配了缓冲池(innodb_ buffer pool),但是每个缓冲池中的帧缓冲(frame buffer)还有对应的缓冲控制对象(buffer control block),这些对象记录了一些诸如 LRU、锁、等待等信息,而这个对象的内存需要从额外内存池中申请。因此,在申请了很大的 InnoDB 缓冲池时,也应考虑相应地增加这个值。

2.4 Checkpoint 技术

  • 前面已经讲到了,缓冲池的设计目的为了协调 CPU速度与磁盘速度的鸿沟。因此页的操作首先都是在缓冲池中完成的。如果一条 DML 语句,如 Update 或 Delete 改变了页中的记录,那么此时页是脏的, 即缓冲池中的页的版本要比磁盘的新。数据库需要将新版本的页从缓冲池刷新到磁盘。
  • 倘若每次一个页发生变化,就将新页的版本刷新到磁盘,那么这个开销是非常大的。若热点数据集中在某几个页中,那么数据库的性能将变得非常差。同时,如果在从缓冲池将页的新版本刷新到磁盘时发生了宕机,那么数据就不能恢复了。为了避免发生数据丢失的问题,当前事务数据库系统普遍都采用了 Write Ahead Log 策略,即当事务提交时,先写重做日志,再修改页。当由于发生宕机而导致数据丢失时,通过重做日志来完成数据的恢复。这也是事务 ACID中D(Durability 持久性)的要求。
  • 思考下面的场景,如果重做日志可以无限地增大,同时缓冲池也足够大,能够缓冲所有数据库的数据,那么是不需要将缓冲池中页的新版本刷新回磁盘。因为当发生宕机时,完全可以通过重做日志来恢复整个数据库系统中的数据到宕机发生的时刻。但是这需要两个前提条件∶
    1.缓冲池可以缓存数据库中所有的数据;
    2.重做日志可以无限增大。
    对于第一个假设对于生产环境应用中的数据库是很难得到保证的。
    再来看第二个前提条件∶重做日志可以无限增大。也许是可以的,但是这对成本的要求太高,同时不便于运维。
    即使上述两个条件都满足,那么还有一个情况需要考虑∶ 宕机后数据库的恢
    复时间。
  • 因此 Checkpoint (检查点)技术的目的是解决以下几个问题∶
    1.缩短数据库的恢复时间;
    2.缓冲池不够用时,将脏页刷新到磁盘;
    3.重做日志不可用时,刷新脏页。
  • 当数据库发生宕机时,数据库不需要重做所有的日志,因为 Checkpoint 之前的页都已经刷新回磁盘。故数据库只需对 Checkpoint 后的重做日志进行恢复。这样就大大缩短了恢复的时间。
  • 此外,当缓冲池不够用时,根据LRU 算法会溢出最近最少使用的页,若此页为脏页,那么需要强制执行 Checkpoint,将脏页也就是页的新版本刷回磁盘。
  • 重做日志出现不可用的情况是因为重做日志的设计是循环使用的,并不是让其无限增大的。重做日志可以被重用的部分是指这些重做日志已经不再需要。若此时重做日志还需要使用,那么必须强制产生 Checkpoint,将缓冲池中的页至少刷新到当前重做日志的位置。
  • 对于InnoDB 存储引擎而言,其是通过 LSN(Log Sequence Number)来标记版本的。而 LSN 是8字节的数字,其单位是字节。每个页有LSN,重做日志中也有 LSN, Checkpoint 也有LSN。可以通过命令 SHOW ENGINE INNODB STATUS 来观察;
    在这里插入图片描述
    在 InnoDB存储引擎中,Checkpoint 发生的时间、条件及脏页的选择等都非常复杂。
  • 而 Checkpoint 所做的事情无外乎是将缓冲池中的脏页刷回到磁盘。在 InnoDB存储引擎内部,有两种 Checkpoint,分别为∶
  1. Sharp Checkpoint
  2. Fuzzy Checkpoint
  • Sharp Checkpoint 发生在数据库关闭时将所有的脏页都刷新回磁盘,这是默认的工作方式,即参数 innodb fast_shutdown=1。但是若数据库在运行时也使用 Sharp Checkpoint,那么数据库的可用性就会受到很大的影响。故在 InnoDB 存储引擎内部使用 Fuzzy Checkpoint 进行页的刷新,即只刷新一部分脏页,而不是刷新所有的脏页回磁盘。

这里笔者进行了概括,在 InnoDB存储引擎中可能发生如下几种情况的 Fuzzy Checkpoint:
3. Master Thread Checkpoint
4. FLUSH_LRU_LIST Checkpoint
5. Async/Sync Flush Checkpoint
6. Dirty Page too much Checkpoint

  • 对于Master Thread中发生的 Checkpoint,差不多以每秒或每十秒的速度从缓冲池的脏页列表中刷新一定比例的页回磁盘。这个过程是异步的,即此时 InnoDB 存储引擎可以进行其他的操作,用户查询线程不会阻塞。
  • FLUSH_LRU_LIST Checkpoint 是因为 InnoDB存储引擎需要保证 LRU 列表中需要有差不多100个空闲页可供使用。在 InnoDB1.1.x 版本之前,需要检查LRUJ 列表中是否
    有足够的可用空间操作发生在用户查询线程中,显然这会阻塞用户的查询操作。倘若没有 100 个可用空闲页,那么 InnoDB 存储引擎会将 LRU列表尾端的页移除。如果这些页中有脏页,那么需要进行 Checkpoint,而这些页是来自LRU 列表的,因此称为 FLUSH LRU_LIST Checkpoint。
    而从 MySQL 5.6 版本,也就是 InnoDB1.2.x 版本开始,这个检查被放在了一个单独的 Page Cleaner 线程中进行,并且用户可以通过参数 innodb lru scan depth 控制LRU列表中可用页的数量,该值默认为 1024,如∶
    在这里插入图片描述
  • Async/Sync Flush Checkpoint指的是重做日志文件不可用的情况,这时需要强制将一些页刷新回磁盘,而此时脏页是从脏页列表中选取的。若将已经写入到重做日志的 LSN记为 redo lsn,将已经刷新回磁盘最新页的 LSN 记为 checkpoint lsn,则可定义;
    checkpoint_age = redo_lsn - checkpoint_lsn
    再定义以下的变量∶
    async_water_mark = 75$* total_redo_log_file_size
    sync_water_mark = 90%* total_redo_log_file_size
  • 若每个重做日志文件的大小为 1GB,并且定义了两个重做日志文件,则重做日志文件的总大小为 2GB。async_water_mark=1.5GB,sync_water_mark=1.8GB。
  1. checkpoint_age<async_water_mark 时,不需要刷新任何脏页到磁盘;
  2. 当async_water_mark<checkpoint age<sync_water_mark 时触发 Async Flush,从 Flush列表中刷新足够的脏页回磁盘,使得刷新后满足 checkpoint age<async_water_ mark;
  3. checkpoint_age>sync_water_mark 这种情况一般很少发生,除非设置的重做日志文件太小,并且在进行类似LOAD DATA的 BULK INSERT操作。此时触发 Sync Flush 操作,从 Flush 列表中刷新足够的脏页回磁盘,使得刷新后满足 checkpoint_age<async_water_mark。
  • 可见,Async/Sync Flush Checkpoint 是为了保证重做日志的循环使用的可用性。在 InnoDB 1.2.x 版本之前,Async Flush Checkpoint 会阻塞发现问题的用户查询线程,而 Sync Flush Checkpoint 会阻塞所有的用户查询线程,并且等待脏页刷新完成。从 InnoDB 1.2,x版本开始———也就是MySOL 5.6 版本,这部分的刷新操作同样放入到了单独的Page Cleaner Thread 中,故不会阻塞用户查询线程。
  • MySQL 官方版本并不能查看刷新页是从 Flush列表中还是从LRU列表中进行 Checkpoint 的,也不知道因为重做日志而产生的 Async/Sync Flush 的次数。但是 InnoSQL版本提供了方法,可以通过命令 SHOW ENGINE INNODB STATUS 来观察,如∶
    在这里插入图片描述
  • 最后一种 Checkpoint 的情况是 Dirty Page too much,即脏页的数量太多,导致 InnoDB 存储引擎强制进行 Checkpoint。其目的总的来说还是为了保证缓冲池中有足够可用的页。其可由参数 innodb_max_dirty_pages_pct 控制∶
    在这里插入图片描述
  • innodb_max_dirty_pages_pct 值为75 表示,当缓冲池中脏页的数量占据 75%时,强制进行 Checkpoint,刷新一部分的脏页到磁盘。在 InnoDB 1.0.x版本之前,该参数默认值为 90,之后的版本都为 75。

2.5 Master Thread工作方式

2.5.1 InnoDB 1.0.x 版本之前的 Master Thread

  • Master Thread具有最高的线程优先级别。其内部由多个循环(loop)组成∶主循环(loop)、后台循环(backgroup loop)、刷新循环(flushloop)、暂停循环(suspend loop)。 Master Thread 会根据数据库运行的状态在 loop、background loop、flush loop 和 suspend loop 中进行切换。
  • Loop 被称为主循环,因为大多数的操作是在这个循环中,其中有两大部分的操作——每秒钟的操作和每 10 秒的操作。伪代码如下∶
    在这里插入图片描述
  • 可以看到,loop循环通过 thread sleep 来实现,这意味着所谓的每秒一次或每 10 秒一次的操作是不精确的。在负载很大的情况下可能会有延迟(delay),只能说大概在这个频率下。当然,InnoDB 源代码中还通过了其他的方法来尽量保证这个频率。
  • 每秒一次的操作包括∶
  1. 日志缓冲刷新到磁盘,即使这个事务还没有提交(总是);
  2. 合并插入缓冲(可能);
  3. 至多刷新 100 个 InnoDB 的缓冲池中的脏页到磁盘(可能);
  4. 如果当前没有用户活动,则切换到 background loop(可能)。
  • 即使某个事务还没有提交,InnoDB 存储引擎仍然每秒会将重做日志缓冲中的内容刷新到重做日志文件。这一点是必须要知道的,因为这可以很好地解释为什么再大的事务提交(commit)的时间也是很短的。
  • 合并插入缓冲(Insert Buffer)并不是每秒都会发生的。InnoDB 存储引擎会判断当
    前一秒内发生的 IO次数是否小于5次,如果小于5次,InnoDB 认为当前的 IO 压力很小,可以执行合并插入缓冲的操作。
  • 同样,刷新 100 个脏页也不是每秒都会发生的。InnoDB存储引擎通过判断当前缓冲池中脏页的比例(buf get modified ratio pct)是否超过了配置文件中 innodb max dirty_pages_pct 这个参数(默认为 90,代表 90%),如果超过了这个阈值,InnoDB 存储引擎认为需要做磁盘同步的操作,将 100 个脏页写入磁盘中。
  • 总结上述操作,伪代码可以进一步具体化,如下所示∶

在这里插入图片描述

接着来看每 10 秒的操作,包括如下内容∶

  1. 刷新 100 个脏页到磁盘(可能的情况下);
  2. 合并至多5个插入缓冲(总是);
  3. 将日志缓冲刷新到磁盘(总是);
  4. 删除无用的 Undo 页(总是);
  5. 刷新 100 个或者 10个脏页到磁盘(总是)。
  • 在以上的过程中,InnoDB 存储引擎会先判断过去 10 秒之内磁盘的 IO 操作是否小于 200 次,如果是,InnoDB 存储引擎认为当前有足够的磁盘 IO操作能力,因此将 100个脏页刷新到磁盘。接着,InnoDB 存储引擎会合并插入缓冲。不同于每秒一次操作时可能发生的合并插入缓冲操作,这次的合并插入缓冲操作总会在这个阶段进行。之后, InnoDB 存储引擎会再进行一次将日志缓冲刷新到磁盘的操作。这和每秒一次时发生的操作是一样的。

  • 接着 InnoDB存储引擎会进行一步执行 full purge 操作,即删除无用 的 Undo页。对表进行 update、delete 这类操作时,原先的行被标记为删除,但是因为一致性读(consistent read)的关系,需要保留这些行版本的信息。但是在 full purge 过程中, InnoDB 存储引擎会判断当前事务系统中已被删除的行是否可以删除,比如有时候可能还有查询操作需要读取之前版本的 undo 信息,如果可以删除,InnoDB 会立即将其删除。

  • 从源代码中可以发现,InnoDB 存储引擎在执行 full purge 操作时,每次最多个尝试回收20个undo 页。

  • 然后,InnoDB存储引擎会判断缓冲池中脏页的比例(buf_get_modified_ratio_pct),如果有超过70%的脏页,则刷新 100 个脏页到磁盘,如果脏页的比例小于 70%,则只需刷新 10% 的脏页到磁盘。

  • 现在我们可以完整地把主循环(main loop)的伪代码写出来了,内容如下∶
    在这里插入图片描述

  • 接着来看 background loop,若当前没有用户活动(数据库空闲时)或者数据库关闭
    (shutdown),就会切换到这个循环。background loop 会执行以下操作∶

  1. 删除无用的 Undo 页(总是);
  2. 合并 20个插入缓冲(总是);
  3. 跳回到主循环(总是);
  4. 不断刷新 100 个页直到符合条件(可能,跳转到 flush loop 中完成)。
  • 若 flush loop 中也没有什么事情可以做了,InnoDB存储引擎会切换到 suspend loop,将 Master Thread挂起,等待事件的发生。若用户启用(enable)了InnoDB 存储引擎,却没有使用任何 InnoDB 存储引擎的表,那么 Master Thread 总是处于挂起的状态。
  • 最后,Master Thread完整的伪代码如下;
    在这里插入图片描述

在这里插入图片描述

2.5.2 InnoDB1.2.x 版本之前的 Master Thread

  • 在了解了1.0.x版本之前的 Master Thread的具体实现过程后,细心的读者会发现 InnoDB 存储引擎对于 IO 其实是有限制的,在缓冲池向磁盘刷新时其实都做了一定的硬编码(hard coding)。在磁盘技术飞速发展的今天,当固态磁盘(SSD)出现时,这种规定在很大程度上限制了InnoDB 存储引擎对磁盘 IO 的性能,尤其是写入性能。
  • 从前面的伪代码来看,无论何时,InnoDB 存储引擎最大只会刷新 100个脏页到磁盘,合并 20个插入缓冲。如果是在写入密集的应用程序中,每秒可能会产生大于100个的脏页,如果是产生大于20 个插入缓冲的情况,Master Thread 似乎会"忙不过来",或者说它总是做得很慢。即使磁盘能在 1 秒内处理多于100 个页的写入和 20个插入缓冲的合并,但是由于hard coding,Master Thread 也只会选择刷新 100 个脏页和合并 20个插入缓冲。同时,当发生宕机需要恢复时,由于很多数据还没有刷新回磁盘,会导致恢复的时间可能需要很久,尤其是对于 insert buffer 来说。
  • 这个问题最初由 Google 的工程师 Mark Callaghan 提出,之后 InnoDB 官方对其进行了修正并发布了补丁(patch)。InnoDB存储引擎的开发团队参考了Google 的 patch,提供了类似的方法来修正该问题。因此 InnoDB Plugin(从 InnoDB1.0.x 版本开始)提供了参数 innodb_io_capacity,用来表示磁盘 IO 的吞吐量,默认值为 200。对于刷新到磁盘页的数量,会按照 innodb_io_capacity 的百分比来进行控制。规则如下∶
  1. 在合并插入缓冲时,合并插入缓冲的数量为 innodb_io_capacity 值的 5%;
  2. 在从缓冲区刷新脏页时,刷新脏页的数量为 innodb_io_capacity。
  • 若用户使用了 SSD 类的磁盘,或者将几块磁盘做了RAID,当存储设备拥有更高的 IO速度时,完全可以将 innodb_io_capacity 的值调得再高点,直到符合磁盘IO的吞吐量为止。
  • 另一个问题是,参数 innodb max_dirty_pages_pct 默认值的问题,在 InnoDB 1.0.x版本之前,该值的默认为 90,意味着脏页占缓冲池的 90%。但是该值"太大"了,因为 InnoDB 存储引擎在每秒刷新缓冲池和 flush loop 时会判断这个值,如果该值太争 innodb_max_dirty_pages_pct,才刷新 100 个脏页,如果有很大的内存,或者数据库服务器的压力很大,这时刷新脏页的速度反而会降低。同样,在数据库的恢复阶段可能需要更多的时间。
  • 在很多论坛上都有对这个问题的讨论,有人甚至将这个值调到了20 或 10,然后测试发现性能会有所提高,但是将 innodb max dirty pages pct 调到 20 或 10 会增加磁盘的压力,系统的负担还是会有所增加的。Google 在这个问题上进行了测试,证明 20 并不是一个最优值。而从 InnoDB 1.0.x 版本开始,innodb_max_dirty_pages_pct 默认值变为了75,和 Google 测试的 80 比较接近。这样既可以加快刷新脏页的频率,又能保证了磁盘 IO 的负载。
  • InnoDB 1.0.x 版本带来的另一个参数是 innodb adaptive flushing(自适应地刷新),该值影响每秒刷新脏页的数量。原来的刷新规则是∶ 脏页在缓冲池所占的比例小于 innodb max_dirty_pages pct 时,不刷新脏页;大于innodb max dirty pages pct 时,刷新 100个脏页。随着 innodb adaptive flushing 参数的引入,InnoDB 存储引擎会通过—个名为 buf_flush_get_desired_flush_rate 的函数来判断需要刷新脏页最合适的数量。粗略地翻阅源代码后发现 buf flush_get_desired_flush_rate 通过判断产生重做日志(redo log)的速度来决定最合适的刷新脏页数量。因此,当脏页的比例小于innodb_max_dirty_pages_ pct 时,也会刷新一定量的脏页。
  • 还有一个改变是∶ 之前每次进行 full purge 操作时,最多回收 20个 Undo 页,从 InnoDB 1.0.x 版本开始引人了参数 innodb_purge_batch size,该参数可以控制每次 full purge 回收的 Undo 页的数量。该参数的默认值为 20,并可以动态地对其进行修改,具体如下∶
    在这里插入图片描述
    通过上述的讨论和解释我们知道,从InnoDB 1.0.x 版本开始,Master Thread的伪码必将有所改变,最终变成∶
    在这里插入图片描述
  • 很多测试都显示,InnoDB 1.0.x 版本在性能方面取得了极大的提高,其实这和前面提到的 Master Thread 的改动是密不可分的,因为 InnoDB 存储引擎的核心操作大部分都集中在 Master Thread 后台线程中。
  • 从 InnoDB 1.0.x 开始,命令 SHOW ENGINE INNODB STATUS 可以查看当前 Master Thread 的状态信息,如下所示∶
    在这里插入图片描述
  • 这里可以看到主循环进行了 45 次,每秒挂起(sleep)的操作进行了 45 次(说明负载不是很大),10秒一次的活动进行了4次,符合 1∶10。background loop 进行了6次, flush loop 也进行了6次。因为当前这台服务器的压力很小,所以能在理论值上运行。如果是在一台压力很大的 MySQL 数据库服务器上,看到的可能会是下面的情景∶
    在这里插入图片描述
  • 可以看到当前主循环运行了2188次,但是循环中的每秒挂起(sleep)的操作只运行了1537次。这是因为 InnoDB 对其内部进行了一些优化,当压力大时并不总是等待 1秒。因此,并不能认为1_second和 sleeps 的值总是相等的。在某些情况下,可以通过两者之间差值的比较来反映当前数据库的负载压力。

2.5.3 InnoDB 1.2.x版本的 Master Thread

  • 在 InnoDB 1.2.x 版本中再次对 Master Thread 进行了优化,由此也可以看出 Master Thread 对性能所起到的关键作用。在 InnoDB 1.2.x版本中,Master Thread 的伪代码如下∶
if InnoDB is idle
srv_master_do_idle_tasks () ; 
else
srv_master_do_active_tasks ();
  • 其中 srv_master do_idle_tasks(O)就是之前版本中每 10秒的操作,srv_master_do_ active_tasksO)处理的是之前每秒中的操作。同时对于刷新脏页的操作,从 Master Thread线程分离到一个单独的 Page Cleaner Thread,从而减轻了Master Thread 的工作,同时进一步提高了系统的并发性。

2.6 InnoDB 关键特性

  • InnoDB存储引擎的关键特性包括∶
  1. 插入缓冲(Insert Buffer)
  2. 两次写(Double Write)
  3. 自适应哈希索引(Adaptive Hash Index)
  4. 异步 IO(Async IO)
  5. 刷新邻接页(Flush Neighbor Page)
    上述这些特性为 InnoDB 存储引擎带来更好的性能以及更高的可靠性。

2.6.1 插入缓冲

  1. Insert Buffer
  • Insert Buffer 可能是 InnoDB 存储引擎关键特性中最令人激动与兴奋的一个功能。不过这个名字可能会让人认为插人缓冲是缓冲池中的一个组成部分。其实不然,InnoDB 缓冲池中有 Insert Buffer 信息固然不错,但是 Insert Buffer 和数据页—样,也是物理页的一个组成部分。
  • 在 InnoDB 存储引擎中,主键是行唯一的标识符。通常应用程序中行记录的插入顺序是按照主键递增的顺序进行插入的。因此,插入聚集索引(Primary Key)一般是顺序的,不需要磁盘的随机读取。比如按下列 SOL 定义表∶
CREATE TABLE t (
a INT AUTO_INCREMENT, b VARCHAR (30), PRIMARY KEY (a));
  • 其中a 列是自增长的,若对 a 列插入 NULL 值,则由于其具有 AUTO_INCREMENT属性,其值会自动增长。同时页中的行记录按 a 的值进行顺序存放。在一般情况下,不需要随机读取另一个页中的记录。因此,对于这类情况下的插入操作,速度是非常快的。

并不是所有的主键插入都是顺序的。若主键类是 UUID 这样的类,那么插入和辅助索引一样,同样是随机的。即使主键是自增类型,但是插入的是指定的值,而不是 NULL 值,那么同样可能导致插入并非连续的情况。

  • 但是不可能每张表上只有一个聚集索引,更多情况下,一张表上有多个非聚集的辅助索引(secondary index)。比如,用户需要按照b 这个字段进行查找,并且b这个字段不是唯一的,即表是按如下的 SQL 语句定义的∶
CREATE TABLE t (
a INT AUTO_INCREMENT, b VARCHAR (30), PRIMARY KEY (a), key (b));
  • 在这样的情况下产生了一个非聚集的且不是唯一的索引。在进行插入操作时,数据页的存放还是按主键 a 进行顺序存放的,但是对于非聚集索引叶子节点的插入不T序的了,这时就需要离散地访问非聚集索引页, 由于随机读取的存在而导致了插入操作性能下降。当然这并不是这个 b 字段上索引的错误,而是因为 B+ 树的特性决定了非聚集索引插入的离散性。
  • 需要注意的是,在某些情况下,辅助索引的插入依然是顺序的,或者说是比较顺序的,比如用户购买表中的时间字段。在通常情况下,用户购买时间是一个辅助索引,用来根据时间条件进行查询。但是在插入时却是根据时间的递增而插入的,因此插入也是"较为"顺序的。
  • InnoDB存储引擎开创性地设计了Insert Buffer,对于非聚集索引的插入或更新操作,不是每一次直接插入到索引页中,而是先判断插入的非聚集索引页是否在缓冲池中,若在,则直接插入;若不在,则先放入到一个 Insert Buffer 对象中,好似欺骗。数据库这个非聚集的索引已经插到叶子节点,而实际并没有,只是存放在另一个位置。然后再以一定的频率和情况进行 Insert Buffer 和辅助索引页子节点的 merge (合并)操作,这时通常能将多个插入合并到—个操作中(因为在—个索引页中),这就大大提高了对干非聚集索引插入的性能
  • 然而 Insert Buffer 的使用需要同时满足以下两个条件;
  1. 索引是辅助索引(secondary index);
  2. 索引不是唯一(unique)的。
  • 当满足以上两个条件时,InnoDB 存储引擎会使用Insert Buffer,这样就能提高插入操作的性能了。不过考虑这样一种情况 ∶应用程序进行大量的插入操作,这些都涉及了不唯一的非聚集索引,也就是使用了Insert Buffer。若此时 MySOL 数据库发生了宕机,这时势必有大量的 Insert Buffer 并没有合并到实际的非聚集索引中去。因此这时恢复可能需要很长的时间,在极端情况下甚至需要几个小时。
  • 辅助索引不能是唯一的,因为在插入缓冲时,数据库并不去查找索引页来判断插入的记录的唯一性。如果去查找肯定又会有离散读取的情况发生,从而导致 Insert Buffer失去了意义。
  • 用户可以通过命令 SHOW ENGINE INNODB STATUS 来查看插入缓冲的信息∶
mysql>SHOW ENGINE INNODB STATUS\G;

在这里插入图片描述

  • seg size 显示了当前 Insert Buffer 的大小为11336×16KB,大约为 177MB;
  • free list len 代表了空闲列表的长度;
  • size 代表了已经合并记录页的数量。
  • 黑体部分的第 2行它显示了插入性能的提高。
  • Inserts 代表了插入的记录数;
  • merged recs 代表了合并的插入记录数量;
  • merges 代表合并的次数,也就是实际读取页的次数。
  • merges∶merged recs 大约为1∶3,代表了插入缓冲将对于非聚集索引页的离散 IO逻辑请求大约降低了2/3。

  • 正如前面所说的,目前 Insert Buffer 存在一个问题是∶在写密集的情况下,插入缓冲会占用过多的缓冲池内存(innodb_buffer_pool),默认最大可以占用到 1/2 的缓冲池内存。以下是 InnoDB 存储引擎源代码中对于 insert buffer 的初始化操作∶
/** Buffer pool size per the maximum insert buffer size */
#define IBUF POOL SIZE PER MAX SIZE   2
ibuf->max_size = buf_pool_get_curr_size()/ UNIV_PAGE SIZE
/ IBUF_POOL_SIZE_PER_MAX_SIZE;
  • 这对于其他的操作可能会带来一定的影响。Percona 上发布一些 patch来修正插入缓冲占用太多缓冲池内存的情况,具体可以到 Percona 官网进行查找。修改IBUF_POOL_SIZE_PER_MAX_SIZE 就可以对插入缓冲的大小进行控制。比如将 IBUF_POOL_SIZE_PER_MAX_SIZE 改为 3,则最大只能使用 1/3 的缓冲池内存。

2.Change Buffer

  • InnoDB 从 1.0.x版本开始引入了 Change Buffer,可将其视为 Insert Buffer 的升级。从这个版本开始,InnoDB存储引擎可以对 DML 操作——INSERT、DELETE、UPDATE都进行缓冲,他们分别是∶ Insert Buffer、Delete Buffer、Purge buffer。
  • 当然和之前 Insert Buffer 一样,Change Buffer 适用的对象依然是非唯一的辅助索引。+
  • 对一条记录进行 UPDATE 操作可能分为两个过程∶
  1. 将记录标记为已删除;
  2. 真正将记录删除。
  • 因此 Delete Buffer 对应 UPDATE操作的第一个过程,即将记录标记为删除。Purge Buffer 对UPDATE 操作的第二个过程,即将记录真正的删除。nnoDB 存储引擎提供了参数innodb_change_buffering,用来开启各种 Buffer 的选项。该参数可选的值为∶ inserts、deletes、purges、changes、all、none。inserts、deletes、purges 就是前面讨论过的三种情况。changes 表示启用 inserts 和 deletes,all 表示启用所有,none 表示都不启用。该参数默认值为 all。
  • 从 InnoDB 1.2.x 版本开始,可以通过参数 innodb_change buffer max size 来控制 Change Buffer 最大使用内存的数量∶
mysql> SHOW VARIABLES LIKE 'innodb_change_buffer_max_size'\G;
*************************** 1.rOW***************************
 Variable_name: innodb_change_buffer_max_size
		Value: 25
1 row in set (0.00 sec)
  • innodb_change_buffer_max_size 值默认为 25,表示最多使用 1/4 的缓冲池内存空间。而需要注意的是,该参数的最大有效值为 50。
  • 在 MySQL5.5版本中通过命令 SHOWENGINE INNODB STATUS,可以观察到类似如下的内容∶
mysql> SHOW ENGINE INNODB STATUS\G;
*************************** 1.rOW***************************
	Type: InnoDB .
	......
	---------------------------------------------------------------------
	INSERT BUFFER AND ADAPTIVE HASH INDEX
	---------------------------------------------------------------------
	Ibuf: size 1,free list len 34397,seg size 34399,10875 merges
	 merged operations:
		insert 20462,delete mark 20158,delete 4215 
	discarded operations:
		insert 0, delete mark 0, delete 0 ....
  • 可以看到这里显示了merged operations 和 discarded operation,并且下 面具体显示 Change Buffer 中每个操作的次数。insert 表示 Insert Buffer; delete mark 表示 Delete Buffer; delete 表示 Purge Buffer; discarded operations 表示当 Change Buffer发生 merge时,表已经被删除,此时就无需再将记录合并(merge)到辅助索引中了。
  1. Insert Buffer 的内部实现
  • 通过前一个小节读者应该已经知道了Insert Buffer 的使用场景,即非唯一辅助索引
    的插入操作。但是对于 Insert Buffer 具体是什么,以及内部怎么实现可能依然模糊,这正是本节所要阐述的内容。
  • 可能令绝大部分用户感到吃惊的是,Insert Buffer 的数据结构是一棵 B+ 树。在 MySQL 4.1之前的版本中每张表有一棵 Insert Buffer B+ 树。而在现在的版本中,全局只有一棵 Insert Buffer B+ 树,负责对所有的表的辅助索引进行 Insert Buffer。而这棵 B+ 树存放在共享表空间中,默认也就是ibdata1中。因此,试图通过独立表空间 ibd 文件恢复表中数据时,往往会导致 CHECK TABLE 失败。这是因为表的辅助索引中的数据可能还在 Insert Buffer 中,也就是共享表空间中,所以通过 ibd 文件进行恢复后,还需要进行 REPAIR TABLE 操作来重建表上所有的辅助索引。
  • Insert Buffer 是一棵 B+ 树,因此其也由叶节点和非叶节点组成。非叶节点存放的是查询的 search key(键值)

图 2-3 Insert Buffer 非叶节点中的 search key

  • search key 一共占用9个字节,其中 space 表示待插入记录所在表的表空间 id,在 InnoDB 存储引擎中,每个表有一个唯一的 space id,可以通过 space id 查询得知是哪张表。space 占用4字节。marker 占用1字节,它是用来兼容老版本的 Insert Buffer。offset表示页所在的偏移量,占用 4 字节。
  • 当一个辅助索引要插入到页(space,offset)时,如果这个页不在缓冲池中,那么InnoDB存储引擎首先根据上述规则构造一个search key,接下来查询 Insert Buffer 这棵 B+ 树,然后再将这条记录插入到 Insert Buffer B+ 树的叶子节点中。
  • 对于插入到Insert Buffer B+树叶子节点的记录(如图 2-4 所示),并不是直接将待插入的记录插入,而是需要根据如下的规则进行构造∶
    在这里插入图片描述
  • space、marker、page_no 字段和之前非叶节点中的含义相同,一共占用9字节。第 4个字段 metadata 占用4 字节,其存储的内容如表 2-2 所示。
    表 2-2 metadata 字段存储的内容
  • IBUF_REC_OFFSET_COUNT是保存两个字节的整数,用来排序每个记录进入 Insert Buffer 的顺序。因为从 InnoDB1.0.x开始支持 Change Buffer,所以这个值同样记录进入 Insert Buffer 的顺序。通过这个顺序回放(replay)才能得到记录的正确值。
  • 从Insert Buffer 叶子节点的第 5 列开始,就是实际插入记录的各个字段了。因此较之原插入记录,Insert Buffer B+ 树的叶子节点记录需要额外 13 字节的开销。
  • 因为启用 Insert Buffer索引后,辅助索引页(space,page_no)中的记录可能被插入到Insert Buffer B+树中,所以为了保证每次 Merge Insert Buffer 页必须成功,还需要有一个特殊的页用来标记每个辅助索引页(space,page_no)的可用空间。这个页的类型为 Insert Buffer Bitmap。
  • 每个Insert Buffer Bitmap 页 用来追 踪 16384个辅 助索引页,也就是 256个区(Extent)。每个Insert Buffer Bitmap 页都在16384个页的第二个页中。关于Insert Buffer Bitmap 页的作用会在下一小节中详细介绍。
  • 每个辅助索引页在 Insert Buffer Bitmap 页中占用4 位(bit),由表2-3 中的三个部分组成。
    在这里插入图片描述
  1. Merge Insert Buffer
  • 通过前面的小节读者应该已经知道了Insert/Change Buffer 是一棵 B+ 树。若需要实现插入记录的辅助索引页不在缓冲池中,那么需要将辅助索引记录首先插入到这棵 B+树中。但是 Insert Buffer 中的记录何时合并(merge)到真正的辅助索引中呢?这是本小节需要关注的重点。
  • 概括地说,Merge Insert Buffer 的操作可能发生在以下几种情况下∶
  1. 辅助索引页被读取到缓冲池时;
  2. Insert Buffer Bitmap 页追踪到该辅助索引页已无可用空间时;
  3. Master Thread。
  • 第一种情况为当辅助索引页被读取到缓冲池中时,例如这在执行正常的 SELECT 查询操作,这时需要检查 Insert Buffer Bitmap 页,然后确认该辅助索引页是否有记录存放于 Insert Buffer B+ 树中。若有,则将 Insert Buffer B+ 树中该页的记录插入到该辅助索引页中。可以看到对该页多次的记录操作通过—次操作合并到了原有的辅助索引页中,因此性能会有大幅提高。
  • Insert Buffer Bitmap 页用来追踪每个辅助索引页的可用空间,并至少有 1/32 页的空间。若插入辅助索引记录时检测到插入记录后可用空间会小于 1/32 页,则会强制进行一个合并操作,即强制读取辅助索引页,将 Insert Buffer B+ 树中该页的记录及待插入的记录插入到辅助索引页中。这就是上述所说的第二种情况。
  • 还有一种情况,之前在分析 Master Thread 时曾讲到,在 Master Thread 线程中每秒或每 10 秒会进行一次 Merge Insert Buffer 的操作,不同之处在于每次进行 merge 操作的页的数量不同。
  • 在 Master Thread 中,执行 merge操作的不止是一个页,而是根据 srv_innodb_io capactiy 的百分比来决定真正要合并多少个辅助索引页。但 InnoDB 存储引擎又是根据怎样的算法来得知需要合并的辅助索引页呢?
  • 在Insert Buffer B+树中,辅助索引页根据(space,offset)都已排序好,故可以根据(space,offset)的排序顺序进行页的选择。然而,对于Insert Buffer 页的选择, InnoDB存储引擎并非采用这个方式,它随机地选择 Insert Buffer B+ 树的一个页,读取该页中的 space 及之后所需要数量的页。该算法在复杂情况下应有更好的公平性。同时,若进行 merge 时,要进行 merge 的表已经被删除,此时可以直接丢弃已经被 Insert/ Change Buffer 的数据记录。

2.6.2 两次写

  • 如果说 Insert Buffer 带给 InnoDB 存储引擎的是性能上的提升,那么 doublewrite(两次写)带给InnoDB 存储引擎的是数据页的可靠性。
  • 当发生数据库宕机时,可能 InnoDB存储引擎正在写入某个页到表中,而这个页只写了一部分,比如 16KB 的页,只写了前 4KB,之后就发生了宕机,这种情况被称为部分写失效(partial page write)。在 InnoDB存储引擎未使用 doublewrite技术前,曾经出现过因为部分写失效而导致数据丢失的情况。
  • 有经验的 DBA 也许会想,如果发生写失效,可以通过重做日志进行恢复。这是一个办法。但是必须清楚地认识到,重做日志中记录的是对页的物理操作,如偏移量 800,写’aaaa’记录。如果这个页本身已经发生了损坏,再对其进行重做是没有意义的。这就是说,在应用(apply)重做日志前,用户需要一个页的副本,当写入失效发生时,先通过页的副本来还原该页,再进行重做,这就是 doublewrite。在 InnoDB 存储引擎中 doublewrite 的体系架构如图 2-5 所示。
  • doublewrite 由两部分组成,一部分是内存中的 doublewrite buffer,大小为 2MB,另一部分是物理磁盘上共享表空间中连续的 128个页,即 2 个区(extent),大小同样为 2MB。在对缓冲池的脏页进行刷新时,并不直接写磁盘,而是会通过memcpy 函数将脏页先复制到内存中的 doublewrite buffer,之后通过 doublewrite buffer 再分两次,每次 1MB 顺序地写入共享表空间的物理磁盘上,然后马上调用 fsync 函数,同步磁盘,避免缓冲写带来的问题。在这个过程中,因为 doublewrite 页是连续的,因此这个过程是顺序

在这里插入图片描述
写的,开销并不是很大。在完成 doublewrite 页的写入后,再将 doublewrite buffer 中的页写入各个表空间文件中,此时的写入则是离散的。可以通过以下命令观察到 doublewrite运行的情况∶
在这里插入图片描述

  • 可以看到,doublewrite 一共写了6325 194个页,但实际的写入次数为 100 399,基本上符合 64∶1。如果发现系统在高峰时的 Innodb_dblwr_pages_written∶Innodb_dblwr_ writes 远小于64∶1,那么可以说明系统写入压力并不是很高。
  • 如果操作系统在将页写入磁盘的过程中发生了崩溃,在恢复过程中,InnoDB 存储引擎可以从共享表空间中的 doublewrite 中找到该页的一个副本,将其复制到表空间文件,再应用重做日志。下面显示了一个由 doublewrite 进行恢复的情况∶
    在这里插入图片描述
  • 若查 看 MySQL 官方手册,会发 现在命令 SHOW GLOBAL STATUS中Innodb_ buffer_pool_pages_flushed变量表示当前从缓冲池中刷新到磁盘页的数量。根据之前的介绍,用户应该了解到,在默认情况下所有页的刷新首先都需要放入到 doublewrite 中,
    因此该变量应该和 Innodb dblwr pages written 一致。然而在 MySQL 5.5.24 版本之前, Innodb_buffer_pool_pages_flushed 总是为 Innodb_dblwr_pages_written 的2倍,而此 Bug直到 MySQL5.5.24 才被修复。因此用户若需要统计数据库在生产环境中写入的量,最安全的方法还是根据 Innodb_dblwr_pages_written 来进行统计,这在所有版本的 MySQL 数据库中都是正确的。
  • 参数 skip_innodb_doublewrite 可以禁止使用doublewrite 功能,这时可能会发生前面提及的写失效问题。不过如果用户有多个从服务器(slave server),需要提供较快的性能(如在 slaves erver 上做的是 RAID0),也许启用这个参数是一个办法。不过对于需要提供数据高可靠性的主服务器(master server),任何时候用户都应确保开启
    doublewrite 功能。

有些文件系统本身就提供了部分写失效的防范机制,如ZFS 文件系统。在这种情况下,用户就不要启用 doublewrite 了。

2.6.3 自适应哈希索引

  • 哈希(hash)是一种非常快的查找方法,在一般情况下这种查找的时间复杂度为 O(1),即一般仅需要一次查找就能定位数据。而 B+ 树的查找次数,取决于 B+ 树的高度,在生产环境中,B+ 树的高度一般为 3 ~ 4 层,故需要 3~ 4 次的查询。
  • InnoDB 存储引擎会监控对表上各索引页的查询。如果观察到建立哈希索引可以带来速度提升,则建立哈希索引,称之为自适应哈希索引(Adaptive Hash Index,AHI)。 AHI 是通过缓冲池的 B+ 树页构造而来,因此建立的速度很快,而且不需要对整张表构建哈希索引。InnoDB 存储引擎会自动根据访问的频率和模式来自动地为某些热点页建立哈希索引。
  • AHI 有一个要求,即对这个页的连续访问模式必须是一样的。例如对于(a,b)这样的联合索引页,其访问模式可以是以下情况∶
  1. WHERE a=xxX
  2. WHERE a=xxx and b=xxx
  • 访问模式一样指的是查询的条件一样,若交替进行上述两种查询,那么 InonDB 存储引擎不会对该页构造 AHI。此外 AHI 还有如下的要求∶
  1. 以该模式访问了100 次
    2.页通过该模式访问了N次,其中 N= 页中记录*1/16
  • 根据 InnoDB 存储引擎官方的文档显示,启用 AHI后,读取和写入速度可以提高 2倍,辅助索引的连接操作性能可以提高 5倍。毫无疑问,AHI是非常好的优化模式,其设计思想是数据库自优化的(self-tuning),即无需 DBA 对数据库进行人为调整。
  • 通过命令 SHOW ENGINE INNODB STATUS 可以看到当前 AHI 的使用状况;
    在这里插入图片描述
  • 现在可以看到 AHI 的使用信息了,包括 AHI 的大小、使用情况、每秒使用 AH 搜
    索的情况。值得注意的是,哈希索引只能用来搜索等值的查询,如 SELECT*FROM table WHERE index_col=‘xxx’。而对于其他查找类型,如范围查找,是不能使用哈希索引的,因此这里出现了 non-hash searches/s 的情况。通过 hash searches∶non-hash searches 可以大概了解使用哈希索引后的效率。
  • 由于 AHI 是由 InnoDB存储引擎控制的,因此这里的信息只供用户参考。不过用户
    可以通过观察 SHOW ENGINE INNODB STATUS的结果及参数 `innodb_adaptive_hash_index 来考虑是禁用或启动此特性,默认 AHI为开启状态。

2.6.4 异步 IO

  • 为了提高磁盘操作性能,当前的数据库系统都采用异步 IO(Asynchronous IO, AIO)的方式来处理磁盘操作。InnoDB 存储引擎亦是如此。
  • 与 AIO 对应的是 Sync IO,即每进行一次 IO操作,需要等待此次操作结束才能继续接下来的操作。但是如果用户发出的是一条索引扫描的查询,那么这条 SQL 查询语句可能需要扫描多个索引页,也就是需要进行多次的 IO 操作。在每扫描一个页并等待其完成后再进行下一次的扫描,这是没有必要的。用户可以在发出一个 IO 请求后立即再发出另一个IO 请求,当全部 IO 请求发送完毕后,等待所有 IO操作的完成,这就是 AIO。
  • AIO 的另一个优势是可以进行 IO Merge 操作,也就是将多个 IO 合并为1个 IO,这样可以提高 IOPS 的性能。例如用户需要访问页的(space,page_no)为∶
    (8,6)、(8,7),(8,8)
  • 每个页的大小为 16KB,那么同步 IO需要进行 3 次 IO操作。而 AIO 会判断到这三个页是连续的(显然可以通过(space,page_no)得知)。因此 AIO 底层会发送一个IO请求,从(8,6)开始,读取 48KB 的页。
  • 若通过Linux操作系统下的 iostat命令,可以通过观察 rram/s 和 wram/s。例如∶
    在这里插入图片描述
  • 在 InnoDB1.1.x 之前,AIO 的实现通过 InnoDB存储引擎中的代码来模拟实现。而从 InnoDB 1.1.x开始(InnoDB Plugin 不支持),提供了内核级别 AIO的支持,称为Native AIO。因此在编译或者运行该版本 MySOL 时,需要 libaio 库的支持。若没有则会出现如下的提示∶
    在这里插入图片描述
  • 提供Native AIO 支持,而 Mac OSX系统则未提供。因此在这些系统下,依旧只能使用原模拟的方式。在选择 MySQL 数据库服务器的操作系统时,需要考虑这方面的因素。
  • 参数innodb_use_native_aio 用来控制是否启用Native AIO,在 Linux操作系统下,默认值为 ON∶
    在这里插入图片描述
  • 用户可以通过开启和关闭Native AIO 功能来比较 InnoDB 性能的提升。官方的测试显示,启用 Native AIO,恢复速度可以提高 75%。
  • 在 InnoDB存储引擎中,read ahead方式的读取都是通过 AIO完成,脏页的刷新,即磁盘的写入操作则全部由 AIO完成。

2.6.5 刷新邻接页

  • InnoDB 存储引擎还提供了Flush Neighbor Page(刷新邻接页)的特性。其工作原理为;当刷新一个脏页时,InnoDB 存储引擎会检测该页所在区(extent)的所有页,如果是脏页,那么一起进行刷新。这样做的好处显而易见,通过 AIO 可以将多个IO写入操作合并为一个IO 操作,故该工作机制在传统机械磁盘下有着显著的优势。但是需要考虑到下面两个问题∶
  1. 是不是可能将不怎么脏的页进行了写入,而该页之后又会很快变成脏页?
  2. 固态硬盘有着较高的 IOPS,是否还需要这个特性?
  • 为此,InnoDB存储引擎从 1.2.x 版本开始提供了参数 innodb flush neighbors,用来控制是否启用该特性。对于传统机械硬盘建议启用该特性,而对于固态硬盘有着超高 IOPS 性能的磁盘,则建议将该参数设置为 0,即关闭此特性。

2.7 启动、关闭与恢复

  • InnoDB 是 MySQL 数据库的存储引擎之一,因此 InnoDB 存储引擎的启动和关闭,更准确的是指在 MySQL 实例的启动过程中对 InnoDB 存储引擎的处理过程。
  • 在关闭时,参数 innodb fast shutdown 影响着表的存储引擎为 InnoDB 的行为。,数可取值为 0、1、2,默认值为 1。
  1. 0表示在 MySQL 数据库关闭时,InnoDB 需要完成所有的 full purge 和 merge
    insert buffer,并且将所有的脏页刷新回磁盘。这需要一些时间,有时甚至需要几个小时来完成。如果在进行 InnoDB 升级时,必须将这个参数调为 0,然后再关闭数据库。
  2. 1是参数 innodb_fast_shutdown 的默认值,表示不需要完成上述的 full purge 和
    merge insert buffer 操作,但是在缓冲池中的一些数据脏页还是会刷新回磁盘。
  3. 2表示不完成 full purge 和 merge insert buffer操作,也不将缓冲池中的数据脏页
    写回磁盘,而是将日志都写入日志文件。这样不会有任何事务的丢失,但是下次 MySQL 数据库启动时,会进行恢复操作(recovery)。
  • 当正常关闭 MySQL 数据库时,下次的启动应该会非常"正常"。但是如果没有正常地关闭数据库,如用 kill 命令关闭数据库,在 MySQL 数据库运行中重启了服务器,或者在关闭数据库时,将参数 innodb fast shutdown 设为了2 时,下次 MySOL 数据库启动时都会对 InnoDB存储引擎的表进行恢复操作。
  • 参数 innodb_force_recovery 影响了整个 InnoDB存储引擎恢复的状况。该参数值默认为0,代表当发生需要恢复时,进行所有的恢复操作,当不能进行有效恢复时,如数据页发生了corruption,MySQL 数据库可能发生宕机(crash),并把错误写入错误日志中去。
  • 但是,在某些情况下,可能并不需要进行完整的恢复操作,因为用户自己知道怎么进行恢复。比如在对一个表进行 alter table 操作时发生意外了,数据库重启时会对 InnoDB 表进行回滚操作,对于一个大表来说这需要很长时间,可能是几个小时。这时用户可以自行进行恢复,如可以把表删除,从备份中重新导入数据到表,可能这些操作的速度要远远快于回滚操作。
  • 参数 innodb_force_recovery 还可以设置为6个非零值∶1~ 6。大的数字表示包含了前面所有小数字表示的影响。具体情况如下∶
  1. 1(SRV_FORCE_IGNORE_CORRUPT)∶ 忽略检查到的 corrupt 页。
  2. 2(SRV_FORCE_NO_BACKGROUND)∶阻止 Master Thread 线程的运行,如 Master Thread 线程需要进行 full purge 操作,而这会导致 crash。
  3. 3(SRV_FORCE_NO_TRX UNDO)∶不进行事务的回滚操作。
  4. 4(SRV_FORCE_NO_IBUF_MERGE)∶ 不进行插入缓冲的合并操作。
  5. 5(SRV_FORCE_NO_UNDO_LOG_SCAN)∶ 不查看撤销日志(Undo Log),InnoDB
    存储引擎会将未提交的事务视为已提交。
  6. 6(SRV_FORCE_NO_LOG_REDO)∶ 不进行前滚的操作。
  • 需要注意的是,在设置了参数 innodb_force_recovery 大于0后,用户可以对表进行 select、create 和 drop操作,但 insert、update 和 delete 这类 DML操作是不允许的。
  • 现在来做一个实验,模拟故障的发生。在第一个会话中(session),对一张接近 1 000 万行的 InnoDB存储引擎表进行更新操作,但是完成后不要马上提交;
    在这里插入图片描述+ START TRANSACTION 语句开启了事务,同时防止了自动提交(auto commit)的发生,UPDATE 操作则会产生大量的 UNDO 日志(undo log)。这时,人为通过 kill 命令杀掉 MySQL 数据库服务器∶
    在这里插入图片描述

通过 kill 命令可以模拟数据库的宕机操作。下次 MySQL 数据库启动时会对之前的 UPDATE 事务进行回滚操作,而这些信息都会记录在错误日志文件(默认后缀名为 err)中。如果查看错误日志文件,可得如下结果∶
在这里插入图片描述
在这里插入图片描述

  • 可以看到,采用默认的策略,即将 innodb_force recovery 设为0,InnoDB 会在每次启动后对发生问题的表进行恢复操作。通过错误日志文件,可知这次回滚操作需要回滚 8867280行记录,差不多总共进行了 9分钟。
  • 再做一次同样的测试,只不过这次在启动 MySQL数据库前,将参数 innodb force recovery 设为3,然后观察 InnoDB存储引擎是否还会进行回滚操作。查看错误日志文件,可得∶

在这里插入图片描述

  • 这里出现了"!!!",InnoDB 警告已经将 innodb_force_recovery 设置为3,不会进行回滚操作了,因此数据库很快启动完成了。但是用户应该小心当前数据库的状态,并仔细确认是否不需要回滚事务的操作。

热门文章

暂无图片
编程学习 ·

C语言二分查找详解

二分查找是一种知名度很高的查找算法&#xff0c;在对有序数列进行查找时效率远高于传统的顺序查找。 下面这张动图对比了二者的效率差距。 二分查找的基本思想就是通过把目标数和当前数列的中间数进行比较&#xff0c;从而确定目标数是在中间数的左边还是右边&#xff0c;将查…
暂无图片
编程学习 ·

GMX 命令分类列表

建模和计算操作命令&#xff1a; 1.1 . 创建拓扑与坐标文件 gmx editconf - 编辑模拟盒子以及写入子组(subgroups) gmx protonate - 结构质子化 gmx x2top - 根据坐标生成原始拓扑文件 gmx solvate - 体系溶剂化 gmx insert-molecules - 将分子插入已有空位 gmx genconf - 增加…
暂无图片
编程学习 ·

一文高效回顾研究生课程《数值分析》重点

数值分析这门课的本质就是用离散的已知点去估计整体&#xff0c;就是由黑盒子产生的结果去估计这个黑盒子。在数学里这个黑盒子就是一个函数嘛&#xff0c;这门课会介绍许多方法去利用离散点最大化地逼近这个函数&#xff0c;甚至它的导数、积分&#xff0c;甚至微分方程的解。…
暂无图片
编程学习 ·

在职阿里5年,一个28岁女软测工程师的心声

简单的先说一下&#xff0c;坐标杭州&#xff0c;14届本科毕业&#xff0c;算上年前在阿里巴巴的面试&#xff0c;一共有面试了有6家公司&#xff08;因为不想请假&#xff0c;因此只是每个晚上去其他公司面试&#xff0c;所以面试的公司比较少&#xff09; ​ 编辑切换为居中…
暂无图片
编程学习 ·

字符串左旋c语言

目录 题目&#xff1a; 解题思路&#xff1a; 第一步&#xff1a; 第二步&#xff1a; 第三步&#xff1a; 总代码&#xff1a; 题目&#xff1a; 实现一个函数&#xff0c;可以左旋字符串中的k个字符。 例如&#xff1a; ABCD左旋一个字符得到BCDA ABCD左旋两个字符…
暂无图片
编程学习 ·

设计模式--观察者模式笔记

模式的定义与特点 观察者&#xff08;Observer&#xff09;模式的定义&#xff1a;指多个对象间存在一对多的依赖关系&#xff0c;当一个对象的状态发生改变时&#xff0c;所有依赖于它的对象都得到通知并被自动更新。这种模式有时又称作发布-订阅模式、模型-视图模式&#xf…
暂无图片
编程学习 ·

睡觉突然身体动不了,什么是睡眠痽痪症

很多朋友可能有这样的体验&#xff0c;睡觉过程中突然意识清醒&#xff0c;身体却动弹不了。这时候感觉非常恐怖&#xff0c;希望旁边有一个人推自己一下。阳光以前也经常会碰到这样的情况&#xff0c;一年有一百多次&#xff0c;那时候很害怕晚上到来&#xff0c;睡觉了就会出…
暂无图片
编程学习 ·

深入理解C++智能指针——浅析MSVC源码

文章目录unique_ptrshared_ptr 与 weak_ptrstd::bad_weak_ptr 异常std::enable_shared_from_thisunique_ptr unique_ptr 是一个只移型别&#xff08;move-only type&#xff0c;只移型别还有std::mutex等&#xff09;。 结合一下工厂模式&#xff0c;看看其基本用法&#xff…
暂无图片
编程学习 ·

@TableField(exist = false)

TableField(exist false) //申明此字段不在数据库存在&#xff0c;但代码中需要用到它&#xff0c;通知Mybatis-plus在做写库操作是忽略它。,.
暂无图片
编程学习 ·

Java Web day15

第十二章文件上传和下载 一、如何实现文件上传 要实现Web开发中的文件上传功能&#xff0c;通常需要完成两步操作&#xff1a;一.是在Web页面中添加上传输入项&#xff1b;二是在Servlet中读取上传文件的数据&#xff0c;并保存到本地硬盘中。 需要使用一个Apache组织提供一个…
暂无图片
编程学习 ·

【51nod 2478】【单调栈】【前缀和】小b接水

小b接水题目解题思路Code51nod 2478 小b接水 题目 输入样例 12 0 1 0 2 1 0 1 3 2 1 2 1输出样例 6解题思路 可以发现最后能拦住水的都是向两边递减高度&#xff08;&#xff1f;&#xff09; 不管两个高积木之间的的积木是怎样乱七八糟的高度&#xff0c;最后能用来装水的…
暂无图片
编程学习 ·

花了大半天写了一个UVC扩展单元调试工具

基于DIRECTSHOW 实现的&#xff0c;用的是MFC VS2019. 详见&#xff1a;http://www.usbzh.com/article/detail-761.html 获取方法 加QQ群:952873936&#xff0c;然后在群文件\USB调试工具&测试软件\UVCXU-V1.0(UVC扩展单元调试工具-USB中文网官方版).exe USB中文网 USB中文…
暂无图片
编程学习 ·

贪心(一):区间问题、Huffman树

区间问题 例题一&#xff1a;区间选点 给定 N 个闭区间 [ai,bi]请你在数轴上选择尽量少的点&#xff0c;使得每个区间内至少包含一个选出的点。 输出选择的点的最小数量。 位于区间端点上的点也算作区间内。 输入格式 第一行包含整数 N&#xff0c;表示区间数。 接下来 …
暂无图片
编程学习 ·

C语言练习实例——费氏数列

目录 题目 解法 输出结果 题目 Fibonacci为1200年代的欧洲数学家&#xff0c;在他的着作中曾经提到&#xff1a;「若有一只免子每个月生一只小免子&#xff0c;一个月后小免子也开始生产。起初只有一只免子&#xff0c;一个月后就有两只免子&#xff0c;二个月后有三只免子…
暂无图片
编程学习 ·

Android开发(2): Android 资源

个人笔记整理 Android 资源 Android中的资源&#xff0c;一般分为两类&#xff1a; 系统内置资源&#xff1a;Android SDK中所提供的已经定义好的资源&#xff0c;用户可以直接拿来使用。 用户自定义资源&#xff1a;用户自己定义或引入的&#xff0c;只适用于当前应用的资源…
暂无图片
编程学习 ·

零基础如何在短时间内拿到算法offer

​算法工程师是利用算法处理事物的职业 算法&#xff08;Algorithm&#xff09;是一系列解决问题的清晰指令&#xff0c;也就是说&#xff0c;能够对一定规范的输入&#xff0c;在有限时间内获得所要求的输出。 如果一个算法有缺陷&#xff0c;或不适合于某个问题&#xff0c;执…
暂无图片
编程学习 ·

人工智能:知识图谱实战总结

人工智能python&#xff0c;NLP&#xff0c;知识图谱&#xff0c;机器学习&#xff0c;深度学习人工智能&#xff1a;知识图谱实战前言一、实体建模工具Protegepython&#xff0c;NLP&#xff0c;知识图谱&#xff0c;机器学习&#xff0c;深度学习 人工智能&#xff1a;知识图…
暂无图片
编程学习 ·

【无标题】

这里写自定义目录标题欢迎使用Markdown编辑器新的改变功能快捷键合理的创建标题&#xff0c;有助于目录的生成如何改变文本的样式插入链接与图片如何插入一段漂亮的代码片生成一个适合你的列表创建一个表格设定内容居中、居左、居右SmartyPants创建一个自定义列表如何创建一个注…