目录

  • 一. BufferPool
    • BufferPool基础与内部几个链表的解释
      • 1. free链表
        • 磁盘页加载到BufferPool的缓存流程
      • 2. hash表
      • 3. flush链表
        • flush 写入流程
      • 4. LRU表
        • 什么是预读失效
        • 如何解决预读失效(BufferPool污染)提高命中率
        • LRU链表的写入过程
        • LRU链表的淘汰过程
    • BufferPool数据修改操作与脏页的刷新机制checkpoint
    • 总结BufferPool
  • 二. ChangeBuffer
    • 1. 为什么唯一索引不如普通索引适用changeBuffer
      • 唯一索引和普通索引在更新时候的差异
    • 2. 是否会出现一致性问题
    • 3. ChangeBuffer被merge的时机
    • 4. ChangeBuffer大小配置
    • 5. ChangeBuffer 类型
    • 6. ChangeBuffer和redo log的交互
    • 7. 什么场景下推荐使用ChangeBuffer
  • 三. 其它几个问题总结
    • 1. 什么是BufferPool 污染, 如何解决
      • 解决BufferPool污染针对老年代的优化
      • 解决BufferPool污染针对新生代的优化
    • 2. 什么是多实例BufferPool

一. BufferPool

  1. 参考博客
  2. 在使用InnoDB存储引擎时为提高性能,在存储引擎层提供了缓存的功能也就是BufferPool,是一种降低磁盘访问的机制, 又叫做预读机制,有两种策略:
  1. 线性预读linear read-ahead(默认): 如果前面的请求顺序访问当前区的页,那么接下来的若干请求也会顺序访问下一个区的页的几率会更大,所以将下一个区预读到BufferPool, 5.4版本以后默认开启,默认值为56,最大不能超过64,表示顺序访问N个页后触发预读(一个页16K，一个区1M,一个区最多64个页,所以最大值64)
  2. 随机预读random read-ahead 基本弃用
  1. innodb 在执行读写操作时都需要用到BufferPool
  1. 读操作: 先从buffer_pool中查看数据的数据页是否存在，如果不存在，则将page从磁盘读取到buffer pool中
  2. 写操作: 先把数据和日志写入 buffer pool 和 log buffer，再由后台线程以一定频率将 buffer 中的内容刷到磁盘,这个刷盘机制叫做Checkpoint, 写操作的事务持久性由redo log 落库保证，buffer pool只是为了提高读写效率
  1. 实际一下部分都是被BufferPool所管理的: 缓存了: 索引页,数据页,另外还会缓存一下undo页,插入缓存,自适应哈希索引,锁等相关信息
  2. Buffer Pool里有三个链表，LRU链表，free链表，flush链表，InnoDB正是通过这三个链表的使用来控制数据页的更新与淘汰的,另外还维护了一个hash表,通过这个hash表来确认被访问的数据页是否在缓存中

BufferPool基础与内部几个链表的解释

  1. 在查询数据时MySQL实际是按照页去加载的,比如说想要查询一条数据,那么会加载这条数据所在的页到缓存中, 这个缓存就是BufferPool
  2. 查询当前MySQL BufferPool大小: 5.7默认134217728字节,也就是128M,最小允许设置为5m,
SHOW VARIABLES like 'innodb_buffer_pool_size';
  1. BufferPool中缓存的就是索引页,与控制块,每个缓存页都有一个对应的控制块,通过控制块控制缓存页,一个索引页16k,一个控制块是16k*5%, 可以通过"innodb_buffer_pool_size"命令设置大小,但是设置的这个大小是不包括控制块的,所以查询BufferPool时会发现实际的会比设置的要大一点
  2. BufferPool中存在几个链表
  1. free链表: 用来管理当前BufferPool中的空闲缓存页
  2. flush链表: 用来管理当前BufferPool中需要刷出到磁盘的脏页
  3. hash表: 用来保存数据缓存页的关系
  4. LRU表: 用来管理淘汰策略

1. free链表

  1. MySQL在启动时就会申请开辟BufferPool占用的空间默认128M,在没有执行操作时,BufferPool中的缓存页是空的,free链表通过控制块管理了或者存储了所有空的缓存页,当其中一个缓存页被使用后,会在free中移除
  2. 是一个双向链表，由一个基础节点和若干个子节点组成，记录空闲的数据页对应的控制块信息
  3. free链表本身其实就是由Buffer Pool里的控制块组成的, 每个控制块里都有free_pre/free_next两个指针,分别指向自己的上一个free链表的节点，以及下一个free链表的节点

磁盘页加载到BufferPool的缓存流程

  1. 步骤一: 从free链表中取出一个空闲的控制块以及对应缓冲页
  2. 步骤二: 把磁盘上的数据页读取到对应的缓存页，同时把相关的一些描述数据写入缓存页的控制块,如: 页所在的表空间,页号等信息
  3. 把该控制块对应的free链表节点从链表中移除，表示该缓冲页已经被使用了

2. hash表

  1. 怎么判断一个索引页是否在BufferPool中,可以认为以"表空间号+数据页号"为kev,缓存页控制块的地址作为value,提出了hash表,
  2. 在加载索引页时如果hash表中不存在,则说明BufferPool中没有缓存这个页数据,通过free链表中取出一个空闲缓存页,用来缓存需要加载的数据
  1. 步骤一: 通过sql语句中的数据库名和表名可以知道要加载的数据页处于哪个表空间
  2. 步骤二: 通过表空间号，表名称进行一致性算法得到索引根节点数据页号(实际根节点页号就是通过一致性hash确认的)
  3. 步骤三: 通过根节点数据页号,一层一层查找,在找下一层之前会通过这个hash表判断bufferpool里面是否存在这个数据页,不存在则去磁盘加载
  4. 步骤四: 如果存在通过缓存页地址就可以在BufferPool池中定位到缓存页

3. flush链表

  1. InnoDB提供了BufferPool, 对数据的读写操作都是先基于这个BufferPool缓存进行,然后通过后台线程将脏页写入磁盘,也就是刷脏
  2. 那么什么是脏页: 以更新为例,会先更新BufferPool中的缓存页,此时这个缓存跟磁盘数据就不一致了,称为脏页,而flush链表就是用来管理这些脏页的
  3. Flush链表与Free链表的结构类似,是一个双向链表,链接首尾结点,管理了修改过的缓存页所对应的控制块(也就是管理了所有更新过的缓存页,脏页）
  4. 提供

flush 写入流程

  1. 以更新为例: 当修改数据时先对需要更新的行数据进行加锁,将原始数据写入到redoLog供后续回滚使用,执行update操作,先更新BufferPool中对应的缓存页,此时这个缓存页被称为脏页,等待刷脏,注意此处说的是更新的数据在BufferPool中,如果不在,InnoDB使用会使用changeBuffer进行优化处理,后面有讲
  2. 当控制块被加入到Flush 链表后，后台线程就可以遍历 Flush 链表，将脏页写入到磁盘
  3. flush链表: 脏页是怎么刷新到磁盘进行落地的,BufferPool中提供了flush链表,专门用来管理待刷出的脏页,并且flush链表中的节点同时也在lru链表中,脏页刷新是innodb后台执行的确定性工作

4. LRU表

  1. 通过几个问题引出LRU表:(下面两个问题都是通过LRU链表解决的)
  1. 从磁盘中加载数据页到BufferPool的时,会将对应的控制块从Free链表中移除,那这个控制块移除之后被放到哪里去了
  2. BufferPool的大小是128MB，当Buffer Pool中空闲数据页全部别加载数据之后，新的数据要怎么处理
  1. 缓存空间是有限的,数据是如何淘汰的,提供了lru链表,移除最近最少使用,并且通过这个lru链表解决“预读失效”与“缓冲池污染”的问题
  2. 实际已使用的缓存页在BufferPool中被一个lru链表管理,将频繁访问的数据放在链表头部,不怎么访问的数据链表末尾,空间不够的时候就从尾部开始淘汰, LRU链表本质上也是有控制块组成的

什么是预读失效

InnoDB提供了LRU链表,提供了淘汰策略,预读的数据会被放到 LRU 链表头部,当 BufferPool空间不足时,需要把末尾的页淘汰掉,如果这些预读的数据一直没有被使用,而把被使用的数据挤到了链表的尾部,进而被淘汰,那缓存的命中率就会大大降低,这就是预读失效

如何解决预读失效(BufferPool污染)提高命中率

  1. MySQL对LRU算法进行了优化,将LRU划分为了old和young两个区域,其中:
  1. old 区域: 在LRU 链表的后半部分, 默认占比37%，可以通过 innodb_old_blocks_pct 进行配置
  2. young 区域: 在 LRU 链表的前半部分, 首尾相连,即 新生代的尾(tail)连接着老生代的头(head)
  1. 一条缓存会先进老生代(老生代满了会把使用频率最低的缓存移除)待够一定时间之后再挪到新生代,淘汰时先淘汰老年代数据
  1. 新页(例如被预读的页)加入缓冲池时,先加入到老生代头部：如果数据真正被读取(预读成功),才会加入到新生代的头部；如果数据没有被读取,则会比新生代里的“热数据页”更早被淘汰出缓冲池；
  2. 数据页加载到缓存页后，在1s之后(默认),访问该缓存页,该缓存页会被移动到热数据区头部。数据页刚加载到缓存页后，在1s之内，访问该缓存页,该缓存页是不会被移动到热数据区头部的。
  3. 热数据区的前1/4的缓存页如果被访问，是不会移动到热数据区头部的；后3/4的缓存页被访问了，才会移动到热数据区头部

LRU链表的写入过程

  1. 步骤一：根据表空间号+表名称，拿到数据页号,通过表空间号+数据页号在hash表中判断数据是否被加载过
  2. 步骤二: 如果hash表中不存在,说明未被加载,从Free链表中获取一个控制块
  3. 步骤三: 读取磁盘数据, 将数据写到空闲的缓存页中
  4. 步骤四: 将缓存页的信息写回控制块,将控制块从Free链表中移除
  5. 步骤五: 从Free中移除的控制块节点加入到LRU链表中

LRU链表的淘汰过程

  1. 设计思路就是：链表头部的节点是最近使用的，链表末尾的节点是最久没被使用的，当空间不足时就淘汰末尾最久没被使用的节点,目的是让被访问的缓存页能够尽量排到靠前的位置, 设计实现
  1. 当访问的页在 BufferPool 里，就将该页对应的控制块移动到 LRU 链表的头部节点。
  2. 当访问的页不在 BufferPool 里，除了要把控制块放入到 LRU 链表的头部，还要淘汰 LRU 链表末尾的节点
  1. 在淘汰时还需要注意,因为flush链表中管理的待刷出脏页节点也在lru链表中，此时在缓存页清理的时候需要做一项简单的判断。
  1. 若缓存页在lru表尾的节点同时也在flush链表中,第一步需要先进行刷脏，随后释放掉缓存页的内存,保证事务的相关修改可以正确同步至磁盘中
  2. 若缓存页不在flush链表中,则直接执行简单的释放缓存页内存即可,然后将这些释放完内存缓存页的描述信息,重新添加到free链表中

BufferPool数据修改操作与脏页的刷新机制checkpoint

  1. 当修改数据时先对需要更新的行数据进行加锁,将原始数据写入到redoLog供后续回滚使用,执行update操作,先更新BufferPool中对应的缓存页,此时这个缓存页被称为脏页
  2. flush链表: 脏页是怎么刷新到磁盘进行落地的,BufferPool中提供了flush链表,专门用来管理待刷出的脏页,并且flush链表中的节点同时也在lru链表中
  3. 脏页刷新是innodb后台执行的确定性工作,分为两种
  1. 刷新所有脏页: 在数据库关闭时，刷新所有的脏页到磁盘
  2. 部分刷新: 有多种情况
  1. 触发部分刷新的几种情况
  1. 定时触发
  2. LRU列表中空闲页不足,强制LRU删除末尾页时,如果存在脏页,触发checkpoint刷新
  3. 重做日志不够用时，从flush 列表中选择一些页，强制checkpoint刷新
  4. 通过innodb_dirty_page_pct指定系统中脏页比例,当到达这个比例触发刷新,默认75%
  5. 在数据库关闭时，刷新所有的脏页到磁盘
  6. BufferPool 空间不足时,会淘汰一部分数据页,如果淘汰的是脏页,需要先将其同步到磁盘
  1. 勤快刷新模式(agressively flush）,当innodb中的脏页比例超过innodb_max_dirty_pages_pct时,触发刷新脏页到磁盘。
    同时脏页比例超过innodb_max_dirty_pages_pct_lwm时进入勤快刷新模式(agressively flush）
  2. IO风暴: 有一种情况叫做sharp checkpoint ,当innodb要重用之前的redo文件时，就会把innodb_buffer_pool中所有与这个文件有关的页面都要刷新到磁盘；这样做就有可能引起磁盘的IO风暴了，轻者影响性能，重者影响可用性
  3. Buffer Pool内存不足脏页刷盘分为两种情况
  1. 若缓存页同时在flush链表和lru链表中，说明数据被修改过，则需要刷脏，释放掉缓存页的内存，将控制块重新添加到free链表中
  2. 若缓存页只是存在于LRU链表中，说明数据没有被修改过，则不需要刷脏，直接释放掉缓存页的内存，将控制块重新添加到free链表中

总结BufferPool

  1. BufferPool是 MySQL 为了提高操作性能,在启动时预先分配的一块连续的内存空间,用来缓存数据页,默认128M
  2. 在BufferPool中提供了free链表,用来管理空的缓存页,并通过hash表管理以及存在数据的缓存页,查询数据时通过"表空间号+页号"在hash表冲查询,如果没有则执行io操作通过磁盘查询,查到数据后将该数据保存在对应的缓存页上,并将这个缓存页信息在free链表中删除
  3. 提供了flush链表,在修改数据时会先对需要更新的行数据进行加锁,将原始数据写入到redoLog供后续回滚使用,执行update操作,先更新BufferPool中对应的缓存页,此时这个缓存页被称为脏页,然后通过刷盘禁止将脏页刷新给数据库
  4. 高并发下为了提高性能,可以有多个BufferPool实例
  5. 提供了 LRU链表管理BufferPool缓存的淘汰策略,并且内部区分热数据区与冷数据区

二. ChangeBuffer

  1. 参考博客
  2. Insert/ChangeBuffer 实际是BufferPool中的一块区域,上面时在读操作的角度对BufferPool进行了介绍,下面在增删改层面介绍一下BufferPool,也就是BufferPool中的ChangeBuffer
  3. ChangeBuffer在MySQL5.5之前的版本中，由于只支持缓存insert操作，所以最初叫做insertbuffer插入缓冲，后来的版本中支持了更多的操作类型缓存，才改叫change buffer写入缓冲,主要是为了在写入时减少磁盘IO,将随机写改为顺序写等,注意ChangeBuffer只针对 非唯一索引的更新操作有效
  4. 先提出问题,通过这个问题引出ChangeBuffer, 以更新为例,在执行更新操作时,对需要更新的行数据进行加锁,将原始数据写入到redoLog供后续回滚使用,执行update操作,先更新BufferPool中对应的缓存页,此时这个缓存页被称为脏页,然后通过刷盘禁止将脏页刷新给数据库,如果数据不在BufferPool中该如何操作?
  5. 在没有ChangeBuffer时执行更新操作,数据不在BufferPool的原逻辑思路: 没有命中缓冲池的时候，至少产生一次磁盘IO
  1. 先执行io操作将数据由磁盘加载到BufferPool中,
  2. 然后基于内存修改缓存中的数据页,
  3. 磁盘顺序写入redoLog,
  4. 等待刷脏落库
  1. 使用了ChangeBuffer后,流程优化为
  1. 当通过BufferPool没有查询到数据时,直接将这个写操作记录到ChangeBuffer中,一次内存操作
  2. 写入redo log，一次磁盘顺序写操作
  3. 等待merge,将修改落库

1. 为什么唯一索引不如普通索引适用changeBuffer

  1. 对于唯一索引来说,更新操作需要 首先判断这个操作是否是违反了唯一性的约束(也就是要将数据读取到内存,判断一下)既然都读取到了内存了就没必要用changebuffer了,直接在内存修改就行了
  2. 而对于普通索引来说,更新的时候如果目标内存页不在内存中,将更新记录保存到change buffer即可,后续通过merge将此次更新落库
  3. 对于唯一二级索引(unique key)，由于索引记录具有唯一性，因此无法缓存插入操作，但可以缓存删除操作

唯一索引和普通索引在更新时候的差异

  1. 更新时唯一索引不能使用changeBuffer,普通索引能够使用changeBuffer,根据"update table where k=4"进行一个详细举例,根据数据是否在BufferPool中存在两种情况
  2. 当要更新的记录在内存中时
  1. 普通索引k会找到索引记录等于3和5的位置，然后在中间插入k=4的记录；
  2. 唯一索引k会找到索引记录等于3和5的位置，然后判断没有冲突，插入k=4的记录；
  3. 可以看出,当记录在内存中的时候,两者差不不大,唯一索引多了一步唯一索引是否重复的判断,仅仅会消耗很小一部分cpu的资源
  1. 当要更新的记录不在内存中的时候。
  1. 唯一索引需要将数据页加载到内存中,判断这个值没有冲突,然后插入这个新值
  2. 普通索引则是将更新记录在change buffer,语句执行就结束了,后续通过merge进行合并
  3. 可以看到,普通索引利用了changeBuffer,减少了磁盘上的随机访问,对性能的提升比较明显。

2. 是否会出现一致性问题

  1. 数据库异常奔溃通过redo保证数据的一致性
  2. 写缓冲不只是一个内存结构，它也会被定期刷盘到写缓冲系统表空间
  3. 数据读取时，有另外的流程，将数据合并到缓冲池

3. ChangeBuffer被merge的时机

  1. Changebuffer是单独内存中,写入之后会被合并到BufferPool中,那么是时候时候会被merge
  1. 读取Changebuffer中记录的数据页时，会将Changebuffer合并到bufferPool 中，然后被刷新到磁盘(或者说访问变更操作对应的数据页)
  2. 当系统空闲或者slow shutdown时，后台master线程发起merge
  3. InnoDB后台有定期merge线程,定时合并
  4. change buffer的内存空间用完了，后台master线程会发起merge。
  5. redo log写满了，但是一般不会发生

4. ChangeBuffer大小配置

  1. innodb_change_buffer_max_size表示允许change_buffer占Buffer Pool总大小的百分比，默认值为25%，最大可设置为50%
  1. 当有大量增删改操作时,可以增大innodb_change_buffer_max_size以提高系统的写入性能
  2. 当有大量查询操作时,可以减小innodb_change_buffer_max_size以减少Buffer Pool中数据页的淘汰的概率,提高系统的读取性能

5. ChangeBuffer 类型

  1. 前面说到ChangeBuffer在MySQL5.5之后可以支持新增、删除、修改的写入,通过innodb_change_buffering可以自定义设置分别为插入，删除，清除启用或禁用缓冲等默认为all
  1. all ：默认值，缓冲区插入，删除和清除。
  2. none：不缓存任何操作
  3. inserts：缓冲区插入操作。
  4. deletes：缓冲区删除标记操作。
  5. changes：缓冲区插入和删除标记操作。
  6. purges：缓冲区在后台发生的物理删除操作

6. ChangeBuffer和redo log的交互

  1. 当我们要更新一条普通索引记录的时候：
  1. 如果这条记录在内存中,那么直接更新内存,后续通过刷脏处理
  2. 如果该记录没有在内存中,那么就需要更新change buffer
  3. 更新完change buffer之后，MySQL会在redo log中记录下change buffer的修改，
  4. 事务完成时,进行binlog落盘与redolog commit(redo两阶段提交)
  5. 当需要读取不在内存中的记录时,会将该数据页从磁盘加载到内存,然后应用changebuffer中的修改,也就是merge操作

7. 什么场景下推荐使用ChangeBuffer

  1. 不适合使用: 数据库都是唯一索引,或者写入一个数据后会立刻读取它
  2. 适合使用: 数据库大部分是非唯一索引,业务是写多读少,或者不是写后立刻读取

三. 其它几个问题总结

  1. buffer pool的工作流程,大致可以分为三步：
  1. 第一步：先查询bufferPool是否存在对应的数据页,有的话则直接返回
  2. 第二步：bufferPool不存在对应的数据页,则去磁盘中查找,并把结果copy一份到bufferPool中,然后返回给客户端
  3. 第三步：下次有同样的查询，就可以直接查找buffer pool返回数据, 例如：当id=1与id=2都在这个数据页中，那么下次查询Id=2的时候，就可以直接通过buffer pool返回
  1. 在更新数据时由于提出了BufferPool,会不会有脏读现象?或者怎么解决脏读问题
  1. 首先时会通过"表空间+页号"读取缓冲池的页返回数据,如果缓存中没有通过磁盘获取数据
  2. 在更新数据时虽然先更新缓存区的数据,BufferPool基于LRU链表与刷脏机制,会将“脏页”刷回磁盘,防止脏读现象
  3. 据库异常奔溃，能够从redo log中恢复数据
  1. 什么时候缓冲池中的页，会刷到磁盘上
  2. BufferPool中存在Insert/ChangeBuffer是否会出现一致性问题,或者怎么解决一致性问题
  1. 数据库异常奔溃,通过redo log中恢复数据
  2. 提供了刷盘机制将数据持久化到磁盘,
  3. 并且innodb数据行中提供了trx_id,提供了MVCC,与undo版本链,可以根据事物状态判断读取指定版本数据
  1. 为什么写缓冲优化，仅适用于非唯一普通索引页
  2. 还有哪些场景会触发刷写缓冲中的数据
  3. 什么时候不适合InnoDB的写缓冲机制
  4. 什么时候适合使用写缓冲

1. 什么是BufferPool 污染, 如何解决

  1. 使用BufferPool后,在执行sql时,会将数据页加载到BufferPool中,而BufferPool的大小是有限的,如果执行一次加载大量数据的操作,可能就会造成把原本BufferPool中的热数据给淘汰掉了,导致下次访问以前的热数据时又要重新去磁盘读取,最终造成性能下降,这就是BufferPool 污染
  2. 什么时候会读取大量数据,例如索引失效造成全表扫描,导致大量数据加载到BufferPool中
  3. 如何解决: 实际这块要放到LRU链表中一块去解释,BufferPool污染跟预读失效都是一样的会导致LRU的热点数据被替换和淘汰,前面说为了解决预读失效问题,MySQL对LRU链表进行了优化,整个LRU链表内部分为老年代与新生代,老年代在LRU链表尾部,数据加载到BufferPool时先进入老年代,当数据真实被访问时才会将数据右老年代移动到新生代,此时淘汰时也是先淘汰老年代数据,不会影响新生代的热数据

解决BufferPool污染针对老年代的优化

  1. 提出了innodb_old_blocks_time可以看为必须在老年代停留的时间,提高数据由老年代转入新生代的门槛
  2. 在上面LRU提出了老年代,新生代的划分只是解决了预读失效问题,如果一个数据被加载到老年代后确实真正读取了,导致数据移动到新生代,将原新生代中的热数据给淘汰的问题,解决这个问题Innodb提供了"innodb_old_blocks_time"默认1秒, 当数据加载到老年代后,即使真正读取,在这个时间内也不会移动到新生代,提高数据由老年代进入新生代的门槛,

解决BufferPool污染针对新生代的优化

  1. 热数据区的前1/4的缓存页如果被访问，是不会移动到热数据区头部的；后3/4的缓存页被访问了，才会移动到热数据区头部

2. 什么是多实例BufferPool

  1. 当多线程并发访问时,单一的BufferPool可能会影响请求的处理速度,因此InnoDB提供了"innodb_buffer_pool_instances"用来设置BufferPool的实例个数,可以通过多个实例对外提供服务,各自去申请内存空间以及管理各种链表,默认为1，最大可以设置为64
  2. 注意在多实例BufferPool时,单个缓冲池实际占用内存空间 = 缓冲池大小 ÷ 缓冲池实例的个数

十一. MySQL InnoDB 三大特性之 BufferPool相关推荐

  1. [MySQL] InnoDB三大特性之 - 插入缓冲

    InnoDB存储引擎有三大特性非常令人激动,它们分别是插入缓冲.两次写和自适应哈希,本篇文章先介绍第一个特性 - 插入缓冲(insert buffer) 在上一篇<MySQL - 浅谈InnoD ...

  2. mysql的三大特性_【mysql】Innodb三大特性之double write

    1.doublewrite buffer(mysql官方的介绍) InnoDB uses a novel file flush technique called doublewrite. Before ...

  3. 【mysql】Innodb三大特性之double write

    1.doublewrite buffer(mysql官方的介绍) InnoDB uses a novel file flush technique called doublewrite. Before ...

  4. MySQL如何生成idf文件_【IDF2010】释放三大特性 至强7500为MySQL量身定做

    我们曾经总结一般的数据库服务器在选型时的主要需求(详见:数据库服务器选型原则及实例解说),并探讨了如何选择Oralce数据库服务器(详见:x86渐热 Oracle数据库服务器选型指南).本期我们将从M ...

  5. mysql innodb 存储引擎

    --MySQL 结构有两部分组成 1.MySQL server 层 2.存储引擎层 --注:到 存储引擎层之前都属于 MySQL server 层 MySQL 5.1到 5.7 ,大版本 没有变化 , ...

  6. mysql innodb体系结构--初级

    MySQL innodb体系结构 <!--more--&gt 2015年9月20日星期日 20:00-20:40,我观看了博森瑞的关于mysql体系结构网络公开课,这次课程简单介绍了in ...

  7. MySQL 的三大引擎：InnoDB、MyISAM和Memory

    http://www.cnblogs.com/kakaliush/archive/2010/02/23/1671757.html MySQL的三大引擎:InnoDB.MyISAM和Memory Inn ...

  8. mysql特点_Mysql 三大特性详解

    Mysql Innodb后台线程 工作方式 首先Mysql进程模型是单进程多线程的.所以我们通过ps查找mysqld进程是只有一个. 体系架构 InnoDB存储引擎的架构如下图所以,是由多个内存块组成 ...

  9. MySQL - InnoDB特性 - Buffer Pool漫谈

    转载自  MySQL - InnoDB特性 - Buffer Pool漫谈 缓存管理是DBMS的核心系统,用于管理数据页的访问.刷脏和驱逐:虽然操作系统本身有page cache,但那不是专门为数据库 ...

最新文章

  1. class function或class procedure是什么意思
  2. 扫盲 docker 常用命令
  3. 第一篇：数据仓库概述
  4. BSP UI Workbench double click component and see view list
  5. 不当败家子的原因......
  6. Codeforces- Educational Codeforces Round 69
  7. springboot redis 断线重连_Redis(9)——史上最强【集群】入门实践教程
  8. java bio例子_传统的BIO
  9. eclipse jar打包详解
  10. FLEX 与JAVA的LCDS BLAZEDS配置.
  11. java中字符串计算字节长度
  12. 树莓派升级安装python3.7
  13. AR游戏觉醒，或将成为手游未来独角兽
  14. 成为互联网企业家的10个理由
  15. 谷歌提出Flan-T5，一个模型解决所有NLP任务
  16. tipask二次开发总结_测试经验总结（“二次开发”）
  17. 云计算对电子商务的应用优势
  18. ThinkPad E545连WiFi教程（系统：ubuntu-20.04.3-live-server，无线网卡：BCM34142）
  19. 公钥加密技术ECC椭圆曲线加密算法原理
  20. 小学教师计算机模块报哪些,小学计算机教师个人工作总结

热门文章

  1. 大航海时代: 流行5掠夺篇
  2. 路由器上DHCP配置 及单臂路由
  3. FPGA学习-Verilog例化说明
  4. 蓄水池采样算法的python实现_蓄水池抽样及实现
  5. 游戏模型师是做什么的？薪资高不高？
  6. 珞珈-B生所学 跟学笔记 PPT（一）
  7. VLAN间路由的配置
  8. openwrt支持wpa3加密
  9. WIFI认证WPA3
  10. 第16套题目 doc.计算机,计算机二级ms实操题excel难点汇总.doc