【走进RDS】之MySQL内存分配与管理（中篇）

MySQL内存分配与管理总体上分为上中下三篇介绍，上篇中主要介绍了 InnoDB 层和 SQL 层内存分配管理器，其中InnoDB的内存分配主要依靠ut_allocator和mem_heap_allocator完成。本篇为中篇，主要介绍InnoDB的内存构成和使用，代码版本主要基于8.0.25。

InnoDB 是 MySQL 默认的存储引擎，而提到InnoDB的内存，就绕不开Buffer Pool，该结构对性能的影响重大。但事实上InnoDB的内存消耗并不只有BP而已，其内部还有许多重要的结构（如AHI、Change Buffer、Log buffer等）也占据着不可忽视的内存空间。了解InnoDB的内存结构和使用特点对于MySQL运行期间的内存选型和使用有很大帮助。

图源：https://dev.mysql.com/doc/refman/8.0/en/innodb-architecture.html

1.Buffer Pool

Buffer Pool（后面简称 BP）是 InnoDB 主内存中的一块区域，主要用于缓存数据页、索引页、undo 页、自适应哈希索引、锁信息等。读取数据时，若数据存在于 BP 中则可以直接读取，避免磁盘 IO 而提升性能；写入数据时，先修改 BP 中的数据页，再使用一定的策略进行刷脏，更新磁盘数据。

一般来说，BP size 会配置成机器可用物理内存的 50% 到 75%，数据库在启动时会提前分配好这部分的虚拟内存，而真正的物理内存映射会在实际使用中进行。BP 的内存占用会一直存在，直到数据库实例关闭时统一释放。实际BP size和设定值可能会不同，BP size 始 终会圆整为chunk_size * instances的整数倍。

1.1 数据结构

BP 主要的数据结构包括buf_pool_t、buf_chunk_t、buf_block_t 等，各结构之间的主要关系如下图所示。通过参数 innodb_buffer_pool_instances 可以设置 buf_pool_t 实例的数量，多个 instance 的设计可以减少缓冲池内部的资源竞争以提高引擎整体的性能；每个 BP instance 至少包含 1 个 chunk，每个 chunk 在初始化时会划分出数据页控制体 buf_block_t 和实际的数据页帧 frame。页由 LRU、free、flush 等链表进行管理。

▶︎ 1.1.1 buf_pool_t

buf_pool_t 表示一个 BP instance，该结构中包含了诸多的信息，如实例号、size、chunk 列表、各个链表（free、LRU、flush）及其互斥锁、哈希表及其互斥锁等，还包括了 zip_free 链表数组；此外，buf_pool_t 中还包含了内存分配器 ut_allocator，用于分配 chunks 的内存；xxx_old 用来记录 BP resize 前的旧数据；风险指针 Hp 用于标记链表节点位置。

struct buf_pool_t {
    ...
    ulint                           instance_no;       // 缓冲池实例编号
    ulint                           curr_pool_size;    // 缓冲池实例大小
    buf_chunk_t                     *chunks;           // 缓冲池实例的物理块列表
    hash_table_t                    *page_hash;        // 页哈希表
    hash_table_t                     *zip_hash;         // 伙伴系统分配frame对应的block哈希表
    UT_LIST_BASE_NODE_T(buf_page_t) free;              // 空闲链表
    UT_LIST_BASE_NODE_T(buf_page_t) LRU;               // LRU 链表
    UT_LIST_BASE_NODE_T(buf_page_t) flush_list;        // flush 链表
    UT_LIST_BASE_NODE_T(buf_buddy_free_t) zip_free[BUF_BUDDY_SIZES_MAX]; //伙伴分配系统空闲链表
    BufListMutex                    free_list_mutex;   // 空闲链表的互斥锁
    BufListMutex                    LRU_list_mutex;    // LRU 链表的互斥锁
    BufListMutex                    flush_state_mutex; // flush 链表的互斥锁
    BufListMutex           zip_free_mutex;               // 伙伴分配互斥锁
    BufListMutex           zip_hash_mutex;
    BufListMutex           chunks_mutex;                  // chunk mutex链表
    ...
}

▶︎ 1.1.2 buf_chunk_t

chunk 是物理内存分配的基本单位，instance 由一块一块的 chunk 组成。每个 chunk 被切分成 block 串和 frame 串，block 串在前，frame 串在后，两者之间可能存在不圆整的内存碎片。其中 block 为控制块，包含了页面的控制信息；frame 存储了实际的数据，由 bytes 组成。

struct buf_chunk_t {
  ulint               size;           /*!< frames[]/blocks[]的数量 */
  unsigned char       *mem;           /*!< frame内存区域指针 */
  ut_new_pfx_t         mem_pfx;         /*!< 监控信息 */
  buf_block_t         *blocks;         /*!< 控制块数组 */
  uint32_t             chunk_no;        /*! chunk号 */
  UT_LIST_BASE_NODE_T(buf_page_t)   chunk_page_list; /*!< chunk list根结点 */
  ...
};

▶︎ 1.1.3 buf_block_t页控制块，主要的数据包括 buf_page_t 格式的 page，该对象必须为第一个成员以便进行指针的强制转换；还包括指向实际的数据帧 frame 的指针，frame 指向的内存块大小为 UNIV_PAGE_SIZE（一般为16K）；block 中还包含了 frame 和 block 的 mutex，该mutex也负责保护buf_page_t 中的部分数据。

struct buf_block_t {
  buf_page_t     page;  // 放在第一个位置，以便于block和page进行强制转换
  BPageLock     lock;  // frame的读写锁
  byte         *frame;  // 实际数据
  ...
  BPageMutex     mutex; // block锁：state、io_fix、buf_fix_count、accessed
};

▶︎ 1.1.4 buf_page_tpage 包含了 id、size、lsn 等信息，io_fix 和 buf_fix_count 用于控制并发状态，判断该 page 是否处于被访问的状态。page 中还包含了很多 bool 变量，用于判断该 page 是否处于对应链表或哈希表中。

struct buf_page_t {
    ...
    page_id_t      id;                  // page id
    page_size_t    size;                // page 大小
    ib_uint32_t    buf_fix_count;       // 用于并发控制
    buf_io_fix     io_fix;              // 用于并发控制
    buf_page_state state;               // 页状态
    lsn_t          newest_modification; // 最新 lsn，即最近修改的 lsn
    lsn_t          oldest_modification; // 最老 lsn，即第一条修改 lsn
    ...
}

1.2 初始化过程

BP初始化的过程和上述的各个层级的数据结构紧密相关。初始化的主线过程大致步骤可分为：BP初始化---BP isntance初始化---chunk 初始化---block初始化；此外AHI、page_hash等结构的初始化也会在此过程中完成。

▶︎ 1.2.1 buf_pool_init()：

这个过程主要做三件事：一是 BP instance 指针数组的初始化（没有分配实际的内存）；二是多线程并发使用 buf_pool_create() 去构建实际的内存空间；三是在 BP 初始化完成后开启AHI的初始化。

// 1. 构建BP instance指针数组
buf_pool_ptr =
    (buf_pool_t *)ut_zalloc_nokey(n_instances * sizeof *buf_pool_ptr);

// 2. 多线程并发初始化BP instance
for (ulint id = i; id < n; ++id) {
    threads.emplace_back(std::thread(buf_pool_create, &buf_pool_ptr[id], size,
                                     id, &m, std::ref(errs[id]))); }
// 3. AHI的初始化
btr_search_sys_create(buf_pool_get_curr_size() / sizeof(void *) / 64);

buf_pool_create() 函数负责构建每个BP instance，主要做了几件事：

1.初始化各个锁：包括 chunks mutex、LRU 链表锁、free 链表锁、zip_free 链表锁、哈希表锁等；

2.计算 chunks 数量，申请 chunk 指针数组；

3.初始化上述的链表；

4.循环调用 buf_chunk_init() 初始化 chunk；

5.设置 instance 相关的参数（size、instance_no 等）；

6.构建哈希表和相关的锁；

7.初始化 flush 相关数据，如 Hp 指针、链表包含关系等。

static void buf_pool_create(buf_pool_t *buf_pool, ulint buf_pool_size,
                            ulint instance_no, std::mutex *mutex,
                            dberr_t &err) {
  ...
  // 1. 构建锁信息
  mutex_create(LATCH_ID_BUF_POOL_CHUNKS, &buf_pool->chunks_mutex);
  mutex_create(LATCH_ID_BUF_POOL_LRU_LIST, &buf_pool->LRU_list_mutex);
  ...
  // 2. 计算chunks数量
  buf_pool->n_chunks = buf_pool_size / srv_buf_pool_chunk_unit;
  chunk_size = srv_buf_pool_chunk_unit;
  buf_pool->chunks = reinterpret_cast<buf_chunk_t *>(
        ut_zalloc_nokey(buf_pool->n_chunks * sizeof(*chunk)));
  ...
  // 3. 初始化各链表
  UT_LIST_INIT(buf_pool->LRU, &buf_page_t::LRU);
  UT_LIST_INIT(buf_pool->free, &buf_page_t::list)
  UT_LIST_INIT(buf_pool->flush_list, &buf_page_t::list);
  ...
  // 4. 初始化chunk
  do {
    if (!buf_chunk_init(buf_pool, chunk, chunk_size, mutex)) {
      ...
  } while (++chunk < buf_pool->chunks + buf_pool->n_chunks);
  ...
  // 5. 设置instance参数
  buf_pool->instance_no = instance_no;
  buf_pool->curr_pool_size = buf_pool->curr_size * UNIV_PAGE_SIZE;
  ...
  // 6. 构建page_hash和locks
  srv_n_page_hash_locks =
      static_cast<ulong>(ut_2_power_up(srv_n_page_hash_locks));
  buf_pool->page_hash =
      ib_create(2 * buf_pool->curr_size, LATCH_ID_HASH_TABLE_RW_LOCK,
                srv_n_page_hash_locks, MEM_HEAP_FOR_PAGE_HASH);
  buf_pool->zip_hash = hash_create(2 * buf_pool->curr_size);
  ...
  // 7. 初始化flush相关信息，如Hp指针等
  for (i = BUF_FLUSH_LRU; i < BUF_FLUSH_N_TYPES; i++) {
    buf_pool->no_flush[i] = os_event_create();
  }
  ...
  new (&buf_pool->flush_hp) FlushHp(buf_pool, &buf_pool->flush_list_mutex);
  ...
}

▶︎ 1.2.2 buf_chunk_init():

该函数主要做了以下几件事：

1.通过 ut_allocator + large 的方式分配 chunk 需要的内存；

2.分割 chunk，将其分为 blocks 和 frames；

3.调用 buf_block_init() 初始化 block（初始化 block/page 中的变量，如 state、chunk_no 还有是否处于链表的各个标志位等，构建mutex 和 rwlock）并将其加入free链表；

4.注册 chunk。

static buf_chunk_t *buf_chunk_init(...) 
{
  // 1. ut_allocator + large方式申请内存
  ...
  if (!buf_pool->allocate_chunk(mem_size, chunk)) {
    return (nullptr);
  }
  ...
  // 2. 切分block和frame
  chunk->blocks = (buf_block_t *)chunk->mem;
  frame = (byte *)ut_align(chunk->mem, UNIV_PAGE_SIZE);
  chunk->size = chunk->mem_pfx.m_size / UNIV_PAGE_SIZE - (frame != chunk->mem);
  {
    ulint size = chunk->size;
    while (frame < (byte *)(chunk->blocks + size)) {
      frame += UNIV_PAGE_SIZE;
      size--;
    }
    chunk->size = size;
  }
  ...
  // 3. 初始化页控制体block
  for () {
    buf_block_init(buf_pool, block, frame, chunk, sync_init_nolock);
    UT_LIST_ADD_LAST(buf_pool->free, &block->page);
  }
  // 4. 注册chunk
  buf_pool_register_chunk(chunk);
  ...
}

▶︎ 1.2.3 page_hash初始化

buf_pool->page_hash =
     ib_create(2 * buf_pool->curr_size, LATCH_ID_HASH_TABLE_RW_LOCK,
               srv_n_page_hash_locks, MEM_HEAP_FOR_PAGE_HASH);

buf_pool->page_hash_old = nullptr;

buf_pool->zip_hash = hash_create(2 * buf_pool->curr_size);

这里可以看到 page_hash 和 zip_hash 的构建方式有所差异，前者调用 ib_create()，后者则是直接调用 hash_create()。ib_create() 在hash_create() 的基础上多做了 mem_heap_t 类型结构 heaps 和锁初始化的工作。有关 ib_create() 函数的内容会在第三部分的 AHI 结构中做进一步介绍。

1.3 页面管理链表

BP 中的每个链表都是双向链表，节点类型都是 buf_block_t ，基节点中保存了首尾节点信息和链表长度等，大致结构如下图所示。

Buffer Pool 中的页面使用情况如下图所示。其中每个小方格可视为一个页，free 表示空闲页，即该页面对应的数据为空，随时可以填入新的数据；clean 表示干净页，即该页面存在数据，且该数据未被更新；dirty 表示脏页，即该页面存在数据已被更新。各个类型的页同时存在于 BP 中，它们被各个链表串起来，协同管理。

▶︎ 1.3.1 free list

block 初始化后会直接加入到 free 链表。缓冲池中如果需要使用数据页，直接从空闲链表中获取。当空闲节点不足时，将采用一定的策略从 LRU List 和 flush List 中淘汰节点以补充 free 状态的页面。

▶︎ 1.3.2 LRU list

LRU list 是缓冲池中最重要的数据结构，基本所有读入的数据页都缓冲于其上。LRU 链表根据 Least Recently Used 算法对节点进行淘汰。InnoDB 对 LRU 算法进行了以下优化，解决“预读失效”与“缓冲池污染”的问题。

• LRU优化

LRU 分为了 Old Sublist 和 New Sublist 两段，加载数据首先会加载到 Old 位置，只有当满足一定的条件时，数据才会从 Old 段转移到 New 段。当发生类似全表扫描的操作时，LRU 的淘汰就不会影响到真正的热点数据，从而保证缓存的热度。

图源：https://dev.mysql.com/doc/refman/8.0/en/innodb-buffer-pool.html

• 响应时间优化

先设定一个间隔时间 innodb_old_blocks_time，然后将 Old 区域数据页的第一次访问时间在其对应的控制块中记录下来：

• 如果后续的访问时间与第一次访问的时间小于 innodb_old_blocks_time，则不将该缓存页从 Old 区域移动到 New 区域。

• 如果后续的访问时间与第一次访问的时间大于 innodb_old_blocks_time，则将该缓存页从 Old 区域移动到 New 区域的头部。

▶︎ 1.3.3 flush list

缓冲池中所有脏页都会挂载在 flush list 中，以等待数据落盘。在数据更改被刷入磁盘前，数据很有可能会被修改多次。数据页控制体中记录了最新修改的 lsn（newset_modification） 和最早修改的 lsn（oldest_modification）。最新加入的数据页放在链表头部，刷数据时从链表尾开始，即优先刷新最早加入的页节点。

▶︎ 1.3.4 zip_free

该结构是由 5 个链表构成的二维数组，分别是 1K、2K、4K、8K 和 16K 的碎片链表，存储从磁盘读入的压缩页，引擎使用伙伴系统来管理该结构。

2. Change Buffer

Change Buffer 是一颗通用 B+ 树，当二级索引页面不在 Buffer Pool 中时会将 DML（insert、update、delete） 操作产生的的变更缓存在其中，并在合适的时机将缓存合并（merge），减少磁盘的 IO 操作。Change Buffer 内存来源是 Buffer Pool，可以通过参数 innodb_change_buffer_max_size 来设置最大的大小占比，默认 25%，最多 50%。

图源：https://dev.mysql.com/doc/refman/8.0/en/innodb-change-buffer.html

早先的版本中，Change Buffer 只支持 insert 操作，也被称为 Insert Buffer，基于这个历史原因，Change Buffer 在代码中的结构为 ibuf_t ，内包含的是基本的 size、max_size、free_list_len、merge 操作次数等信息。全局只有一个 ibuf_t 结构体，在数据库启动的时候构建。Change Buffer 创建和初始化过程在 ibuf_init_at_db_start() 函数中完成，主要包括：

1.相关互斥量的构建；

2.ibuf参数的初始化，包括max_size、index等相关的数据；

3.root的获取。

void ibuf_init_at_db_start(void) {
  ...
  // 1.互斥量操作
  mutex_create(LATCH_ID_IBUF, &ibuf_mutex);
  ...

  // 2.构建root
  {
    buf_block_t *block;
    // IBUF_SPACE_ID = 0, FSP_IBUF_TREE_ROOT_PAGE_NO = 4
    block = buf_page_get(page_id_t(IBUF_SPACE_ID, FSP_IBUF_TREE_ROOT_PAGE_NO),
                          univ_page_size, RW_X_LATCH, &mtr);
    buf_block_dbg_add_level(block, SYNC_IBUF_TREE_NODE);
    // 对应的frame作为Change Buffer B+树的root
    root = buf_block_get_frame(block);
  }
  ...
  // 3. 参数设置
  // CHANGE_BUFFER_DEFAULT_SIZE默认是25
  ibuf->max_size = ((buf_pool_get_curr_size() / UNIV_PAGE_SIZE) *
                    CHANGE_BUFFER_DEFAULT_SIZE) /
                    100;
  ibuf->index =
      dict_mem_index_create("innodb_change_buffer", "CLUST_IND", IBUF_SPACE_ID,
                            DICT_CLUSTERED | DICT_IBUF, 1);
  ibuf->index->id = DICT_IBUF_ID_MIN + IBUF_SPACE_ID;
  ibuf->index->table = dict_mem_table_create("innodb_change_buffer",
                                              IBUF_SPACE_ID, 1, 0, 0, 0, 0);
  ...
}

ibuf_insert()操作底层调用了ibuf_insert_low()，主要做了以下几件事：

1.根据数据构建，在数据记录的基础上增加 page.no 等信息；

2.选择合适的 block 插入（数据插入在 rec 中，而 block 则包含有 rec 的数据）；

3.视情况进行 merge。

static MY_ATTRIBUTE((warn_unused_result)) dberr_t
    ibuf_insert_low(ulint mode, ibuf_op_t op, ibool no_counter,
                    const dtuple_t *entry, ulint entry_size,
                    dict_index_t *index, const page_id_t &page_id,
                    const page_size_t &page_size, que_thr_t *thr) {
  ...
  // 1. 构建entry
  ibuf_entry = ibuf_entry_build(op, index, entry, page_id.space(), page_id.page_no(),
                                no_counter ? ULINT_UNDEFINED : 0xFFFF, heap);
  ...
  // 初始化游标
  btr_pcur_open(ibuf->index, ibuf_entry, PAGE_CUR_LE, mode, &pcur, &mtr);
  ...

  // 2. 插入操作
  err = btr_cur_optimistic_insert(...);// 也可能是btr_cur_pessimistic_insert
  block = btr_cur_get_block(cursor);
  ...
  // pcur收尾工作，包括rec、block的清空等
  btr_pcur_close(&pcur);

  // 3. 视情况进行merge
}

Change Buffer 本身没有很多额外的内存申请，依赖 Buffer Pool 中的 block 进行操作。大部分都是申请一些临时的 mem_heap_t，使用完毕后立即释放，不会在内存中长时间驻留。

3. AHI

InnoDB 的索引组织结构为 btree，当查询的时候会根据条件一直索引到叶子节点。为了减少开销，InnoDB 中引入了自适应哈希索引（Adaptive Hash Index，后文简称AHI）对索引的前缀建立了一个哈希表，用来加速查询。AHI 是为那些频繁被访问的索引页而建立的，可以理解为 btree 上的索引，其中包含了多个 hash_table。初始创建的数组大小为 buf_pool_get_curr_size() / sizeof(void *) / 64，使用 malloc 分配。数组大小最终对应了 hash_table 中 cell(bucket)的总数，这个数量实际上还要进行一个质数化的处理。

3.1 数据结构

struct hash_cell_t {
  void *node; /*!< 哈希链 */
};

/* The hash table structure */
struct hash_table_t {
  enum hash_table_sync_t type; /*!< MUTEX/RW_LOCK/NONE. */
  ibool adaptive;     
  ulint n_cells;      /* 哈希桶数量 */
  hash_cell_t *cells; /*!< bucket数组 */
  ulint n_sync_obj; /* 互斥量、锁的数量 */
  union {
    ib_mutex_t *mutexes; 
    rw_lock_t *rw_locks; 
  } sync_obj;

  mem_heap_t **heaps; // 多个part时，用于分配哈希链的内存数组，个数和n_sync_obj相关，如在page_hash中用到
  mem_heap_t *heap; // 分配哈希链的内存堆
};

3.2 内存初始化

在AHI构建的时候，分成了 8 个 part，每个 part 负责不同的 bucket ，拥有各自部分的锁。构建和初始化主要分为以下几个步骤：

1.锁的初始化，锁的数量和 part 数量挂钩；

2.hash_table 的初始化，底层调用 ib_create()，注意这里传入的 type 是 MEM_HEAP_FOR_BTR_SEARCH，这直接决定了 hash_table 中 heap 的类型，即内存的来源。

void btr_search_sys_create(ulint hash_size) {
  /* Step-1: Allocate latches (1 per part). */
  btr_search_latches = reinterpret_cast<rw_lock_t **>(
      ut_malloc(sizeof(rw_lock_t *) * btr_ahi_parts, mem_key_ahi));

  for (ulint i = 0; i < btr_ahi_parts; ++i) {
    btr_search_latches[i] = reinterpret_cast<rw_lock_t *>(
        ut_malloc(sizeof(rw_lock_t), mem_key_ahi));
    rw_lock_create(btr_search_latch_key, btr_search_latches[i],
                    SYNC_SEARCH_SYS);
  }

  /* Step-2: Allocate hash tablees. */
  btr_search_sys = reinterpret_cast<btr_search_sys_t *>(
      ut_malloc(sizeof(btr_search_sys_t), mem_key_ahi));

  btr_search_sys->hash_tables = reinterpret_cast<hash_table_t **>(
      ut_malloc(sizeof(hash_table_t *) * btr_ahi_parts, mem_key_ahi));

  for (ulint i = 0; i < btr_ahi_parts; ++i) { // 循环调用ib_create()
    btr_search_sys->hash_tables[i] =
        ib_create((hash_size / btr_ahi_parts), LATCH_ID_HASH_TABLE_MUTEX, 0,
                  MEM_HEAP_FOR_BTR_SEARCH);
  ...
}

进一步地，ib_create中主要做两件事：

• 调用 hash_create() 创建 hash_table

hash_table() 函数将大部分 hash table 结构中的参数初始化为 0/nullptr，最重要的是构建 hash_table->cells，即哈希桶。哈希桶通过malloc & memset 方式进行构建，这也是AHI构建过程中耗时最久的步骤。

• 初始化table->heap

这里初始化 type 选择 MEM_HEAP_FOR_BTR_SEARCH 类型，heap 的构建为后续的哈希桶指向的哈希链的内存分配做准备。关于 MEM_HEAP_FOR_BTR_SEARCH 类型的说明和使用可以参考上篇。

4. 其他

4.1 Log Buffer

Log Buffer 是日志的缓存，大小由参数 innodb_log_buffer_size 指定，一般来说这块内存都比较小，默认是 16M，有 max 和 min 的限制。

Log Buffer的内存申请/释放底层调用的是ut_allocate()/ut_free()，参数 srv_log_buffer_size就是所需的大小。

// 内存申请
static void log_allocate_buffer(log_t &log) {
  ...
  log.buf.create(srv_log_buffer_size);
}
// 内存释放
static void log_deallocate_buffer(log_t &log) { log.buf.destroy(); }

4.2 table cache

MySQL 中对内存中打开表的数量和表结构数量做了限制。open_table 的过程涉及到 Sever 层和引擎层，这里只针对 InnoDB 层涉及的动作展开介绍。

InnoDB 层的开表动作从函数 ha_innobase::open() 开始，主要包括了 dict_table_t 的构建和 row_prebuilt_t 这个结构的建立。ib_table 的获取顺序依次是会话级缓存 session_cache、全局缓存 dict_sys->hash_table、开表 dd_open_table()。在当前缓存中获取 ib_table 失败就会去下一层的缓存中去获取，所有缓存都不命中就执行开表操作。

int ha_innobase::open(const char *name, int, uint open_flags,
                      const dd::Table *table_def) {
  ...
  // session级缓存
  ib_table = thd_to_innodb_session(thd)->lookup_table_handler(norm_name);

  ...
  // 全局dict_sys级缓存
  ib_table = dict_table_check_if_in_cache_low(norm_name);

  ...
  // 缓存中不存在，直接开表
  ib_table = dd_open_table(client, table, norm_name, table_def, thd);

  ...
  // m_prebuilt结构构建
  m_prebuilt = row_create_prebuilt(ib_table, table->s->reclength);

  ...
}

下面分别就 ib_table 的来源内存进行说明：

1. session_table_cache

每个连接都会对应一个 THD 结构，THD 内部保存了 thread_local 的数据，通过该数据可以获取 session 下的 m_open_tables 映射表。该表的插入、删除、查找都是基于 std::map 进行。

class innodb_session_t {
  table_cache_t m_open_tables;
  ...
};

2. dict_sys->table_hash

dict_sys 可视为全局的缓存。dicy_sys 中 table_hash 的构造是在执行数据字典初始化 dict_init() 的时候完成的，主要包括：lock 的构建、table_LRU 链表的构建、table_hash 的构建，其中 table_hash 也是通过 hash_create() 这个接口进行构建。

void dict_init(void) {
  ...
  dict_sys->table_hash = hash_create(
      buf_pool_get_curr_size() / (DICT_POOL_PER_TABLE_HASH * UNIV_WORD_SIZE));
  dict_sys->table_id_hash = hash_create(
      buf_pool_get_curr_size() / (DICT_POOL_PER_TABLE_HASH * UNIV_WORD_SIZE));
  ...
}

3. dd_open_table()

在试图获取缓存表失败后，最终会通过 dd_open_table() 接口构造 dict_table_t ，底层的调用是 dict_mem_table_create() ，通过 mem_heap_t 对 dict_table_t 的所有结构进行构造；构造完成后，会把最新的 table 缓存在 dict 的 hash_table 中。

dd_open_table
    |->dd_open_table_one
    |    |->dd_fill_dict_table //create dict_table_t
    |        |->dict_mem_table_create // create
    |           {
    |               // dict_table_t和内部的col、locks等内存都从这个heap上面分配，DICT_HEAP_SIZE=100
    |               heap = mem_heap_create(DICT_HEAP_SIZE);
    |             ...
    |               table = static_cast<dict_table_t *>(mem_heap_zalloc(heap, sizeof(*table)));
    |               ...
    |               table->heap = heap;
    |               table->cols = static_cast<dict_col_t *>(
    |               mem_heap_alloc(heap, table->n_cols * sizeof(dict_col_t)));
    |               table->v_cols = static_cast<dict_v_col_t *>(
    |                  mem_heap_alloc(heap, n_v_cols * sizeof(*table->v_cols)));
    |               table->autoinc_lock =
    |                      static_cast<ib_lock_t *>(mem_heap_alloc(heap, lock_get_size()));
    |               ...
    |           }
    |->dict_table_add_to_cache(m_table, TRUE, heap); // 添加到缓存

Server 层中的总的 table cache 和打开表数量、字段长度都有关系，每个 table cache 占据的内存从几十k ～ 几百k不等。

4.3 lock_sys_t

锁系统也是在 InnoDB start/create 的时候构建的，主要的数据内容包括行锁哈希表、Predicate Locks 哈希表、predicate page locks 哈希表等，主要的构建和销毁操作如下。

void lock_sys_create(ulint n_cells)
{
  ...
  lock_sys->rec_hash = hash_create(n_cells);
  lock_sys->prdt_hash = hash_create(n_cells);
  lock_sys->prdt_page_hash = hash_create(n_cells);
  ...
}

void lock_sys_close(void) {
  ...
  hash_table_free(lock_sys->rec_hash);
  hash_table_free(lock_sys->prdt_hash);
  hash_table_free(lock_sys->prdt_page_hash);
  ...
}

主要的内存消耗都是在 3 个 hash_table 的构造上，并且是直接调用 hash_create() 进行“裸”构造，没有涉及 heap/heaps 的初始化，所有的内存都是通过 malloc 的方式去构造。各个 hash_table 的需要的内存大小和 srv_lock_table_size 相关，其值在 InnoDB 启动时被指定：srv_lock_table_size = 5 * (srv_buf_pool_size / UNIV_PAGE_SIZE)。

4.4 os_event_t

大多数锁、互斥量的构建和初始化最终都会落到 os_event_t 的构造，但是零散的、临时的 mutex 并不会造成很大的内存压力。前文提到的在 buf_block_t 的初始化中就有大量 mutex 和 rw_lock 的初始化，其生命周期和 BP 相当，数量和 buf_block_t 相等，因此会占据很大一部分内存空间。

• buf_block_init：

/** Initializes a buffer control block when the buf_pool is created. */
static void buf_block_init(
    buf_pool_t *buf_pool, /*!< in: buffer pool instance */
    buf_block_t *block,   /*!< in: pointer to control block */
    byte *frame,          /*!< in: pointer to buffer frame */
    buf_chunk_t *chunk,   /*!< in: pointer to chunk */
    bool sync_init_nolock)
{
  ...
  mutex_create(LATCH_ID_BUF_BLOCK_MUTEX, &block->mutex); // mutex构建
  ...
  rw_lock_create(PFS_NOT_INSTRUMENTED, &block->lock, SYNC_LEVEL_VARYING); // rw_lock构建
  ...
}

• mutex_create

mutex_create()
    |->mutex_init()
        |->TTASEventMutex::init()
          |->os_event_create() // 构建os_event_t

• rw_lock_create

rw_lock_create()
    |->pfs_rw_lock_create_func()
    |->rw_lock_create_func()
        |->os_event_create() // 构建os_event_t

os_event_create()的底层实现是调用了 malloc 的方式，最终由系统分配这部分的内存。

os_event_t os_event_create() {
  os_event_t ret = (UT_NEW_NOKEY(os_event()));
  return ret;
}

5. 总结

最后，对 InnoDB 涉及到的内存使用做了简要概括，汇总如下表所示。可以看到当指定 innodb_buffer_pool_size 时，除了 BP 本身外，还有很多其他部分的内存也被间接确定了，这部分内存如果没有关注到，其具体内存占用不易知晓。

BP指代innodb_buffer_pool_size，round代表分配的大小需要做圆整对齐处理、prime代表需要做质数化处理。

● BP 指定的 size 最终体现在 chunk 的内存中，实际内存和指定的 size 可能存在差异。

● AHI 结构中采用 malloc 的方式申请了 cells ，但在某些情况下数据都会保存在 mem_heap_t 中。由于 MEM_HEAP_FOR_BTR_SEARCH 标志位的设置，AHI 中 mem_heap_t 部分内存将从 BP 中获取。AHI 中存在多个 hash_table ，目前是采用 loop 方式构建，可以考虑并行方式进行初始化，提高初始化效率；理论上减少哈希冲突能够减少 mem_heap_t 的内存使用。

● 很多内存结构都和 hash_table 相关，hash_table 实际的内存占用需要做质数化处理。

● 绝大多数的 os_event_t 在 buf_block_t 的初始化中产生，该部分的内存占用较大、生命周期较长。

● 在实际的内存分配中，除了指定的 BP 大小之外，系统还会产生额外的内存，本节只是列举部分。Oracle 的分配内存的方式对用户更加友好，指定固定的内存，具体的分配在内部完成，可以很好控制内存总量。

参考

[1] https://dev.mysql.com/doc/refman/8.0/en/innodb-architecture.html

[2] https://dev.mysql.com/doc/refman/8.0/en/innodb-buffer-pool.html

[3] http://mysql.taobao.org/monthly/2021/01/06/

[4] https://www.leviathan.vip/2018/12/18/InnoDB%E7%9A%84BufferPool%E5%88%86%E6%9E%90/

[5] https://juejin.cn/post/7109811386091307039

[6] https://juejin.cn/post/6882298660965580814

[7] https://juejin.cn/post/6974389300884570149

[8] https://dev.mysql.com/doc/refman/8.0/en/innodb-change-buffer.html

[9] 《MySQL内核：InnoDB存储引擎 》Chapter 11

[10] https://juejin.cn/post/6892659139794157575

[11] https://dev.mysql.com/doc/refman/8.0/en/innodb-adaptive-hash.html

[12] https://dev.mysql.com/doc/refman/8.0/en/innodb-redo-log-buffer.html

[13] https://dev.mysql.com/doc/refman/8.0/en/memory-use.html

作者信息：宋华雄（桦雄）来自RDS MySQL内核组，从事RDS MySQL内核研发工作。有任何问题和咨询请发邮件至：[e-mail]

  / End /  

推荐阅读

点击「阅读原文」了解云数据库RDS MySQL更多内容