共计 812 个字符，预计需要花费 3 分钟才能阅读完成。
问题
随着 MySQL 应用的内存越来越大，咱们倡议应用多个 buffer pool instance。
那么咱们的问题是: 一张表有多少在 buffer pool 中，一张表只能在一个 buffer pool instance 中么？
试验
这期的试验很短很简略，
先宽油起一个数据库：
接下来，咱们建一个有数据的表，建表的办法参考试验 11：
重复执行 insert，让表里有更多数据：
咱们查问一下 buffer pool 的散布：
这里会输入 196 行，咱们将后果手工简化一下来剖析（如果是 MySQL 8.0，能够用窗口函数来间接剖析，此处偷个懒，手工简化一下）：
咱们能够看到其中的法则：
- 咱们这张表的各个数据页，交替呈现在两个 buffer pool instance 中（POOL_ID 为 0 和 1，以下简称 POOL）；
- 3-35 页呈现在 POOL 1 中，36-63 空缺；
- 其后，每 64 页更换一个 POOL，两个 POOL 交替呈现。
来整顿一下思路：
为什么 buffer pool 须要应用多个 POOL?
拜访 buffer pool 时须要上锁，只是用一个 POOL，锁抵触比较严重。应用多个 POOL，能够分担锁的抵触压力。
一张表的各个页为什么交替呈现在各个 POOL 中？
为了让各个 POOL 中的数据量绝对均衡。
那为什么不是一页一轮换，而是 64 页一轮换？
咱们拜访数据，常常扫描间断的多个页。如果一页一轮换，那咱们一次扫描就要波及多个 POOL，那么 锁的抵触压力 就不得分担，迷失了最后的指标。
最初一个小技巧：
咱们来看一下 buffer pool 里有这张表的多少数据？
咱们能够大略评估 buffer pool 中有表 a 的多少数据，但行数并不齐全相等，原理留给大家思考（提醒：InnoDB 的数据页中，不齐全是 行数据）
小贴士
information_schema.INNODB_BUFFER_PAGE 的查问老本比拟高，未经测试的状况下，大家尽量不要在生产环境间接应用。
对于 MySQL 的技术内容，你们还有什么想晓得的吗？连忙留言通知小编吧！
