Question

我有innodb_buffer_pool_size =1G innodb_old_blocks_time = 5000 innodb_old_blocks_pct = 37

最初是innodb引擎的状态

BUFFER POOL AND MEMORY
Total memory allocated 1098907648; in additional pool allocated 0
Dictionary memory allocated 58256
Buffer pool size   65536
Free buffers       64932
Database pages     603
Old database pages 242
Modified db pages  0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 0, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 603, created 0, written 2
6.00 reads/s, 0.00 creates/s, 0.50 writes/s
Buffer pool hit rate 995 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 603, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]

后

select count(*) from tenMillion;


BUFFER POOL AND MEMORY
Total memory allocated 1098907648; in additional pool allocated 0
Dictionary memory allocated 404498
Buffer pool size   65536
Free buffers       873
Database pages     64660
Old database pages 23888
Modified db pages  3
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 0, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 64660, created 0, written 20
1085.69 reads/s, 0.00 creates/s, 0.31 writes/s
Buffer pool hit rate 955 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 1081.34/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 64660, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]

这是正确的行为..？因为我希望它只占据37％的数据库页面，因为整个缓存应该是旧块

如果我将innodb _old_blocks_time设置为5000毫秒并且表格大小超过37（我的innodb_old_blocks_pct）百分比好奇地知道是否只有37 pct，那么最初将如何填充innodb free缓冲区（在重新启动服务器之后）被填补或因为没有年轻人也不需要驱逐，如果它将被填充超过我的innodb缓冲池的37％？

请解释

Answer 1

在“old_blocks”和“37％”的日子之前，会发生这种情况：

当你的同事在一个几千兆字节的大桌子上做一个无辜的COUNT(*)时，你会很高兴地在你的buffer_pool中缓存1GB的东西。
噗！您的所有查询现在运行得更慢 - 因为他的查询从buffer_pool中删除了所有缓存的块。（他们会逐渐回来。）

现在，

你很高兴地徒步旅行......
COUNT(*)出现，但他的“表扫描”仅限于缓冲池的37％。
（如果有人碰巧接触到某些表格，那么触摸的块将从“旧”升级，从而转移到其他63％。）
您的查询继续运行良好，因为您仍然拥有大部分已缓存的内容。
另有COUNT(*)出现 - 好吧，它会在37％的情况下乱七八糟，仍然不会干扰（太多）你的“正常”查询。

注意：Buffer pool hit rate 995 / 1000 - 从99.5％（非常好）降至95.5％（仍然非常好）。

Old database pages 23888（在65536中）确认了我所说的被限制在37％的内容。

以下是2009年底发布的5.1.41和5.5.0版本中所说的内容：

InnoDB缓冲池分为两个子列表：一个新的子列表   包含查询大量使用的块和旧的子列表   包含较少使用的块和驱逐候选者   拍摄。在缓冲池的默认操作中，读取时为块   in加载到中点，然后立即移动到头部   一旦访问发生，新的子列表。在表格的情况下   扫描（例如为mysqldump操作执行），每个块读取   扫描最终会移动到新子列表的头部，因为   从每个块访问多行。这甚至发生在   一次扫描，其他块不使用块   查询。块也可以由预读后台线程加载   然后通过单一访问移动到新子列表的头部。   这些效果可能是不利的，因为它们推动了块   被旧的子列表中的其他查询大量使用   子列表，他们将被驱逐。

InnoDB现在提供了两个启用LRU算法的系统变量   调谐：
innodb_old_blocks_pct

Specifies the approximate percentage of the buffer pool used for the old block sublist. The range of values is 5 to 95. The default
值为37（即池的3/8）。
innodb_old_blocks_time

Specifies how long in milliseconds (ms) a block inserted into the old sublist must stay there after its first access before it can be
转移到新的子列表。默认值为0：插入一个块   进入旧的子列表会立即移动到新的子列表中   无论插入访问后多久，都可以访问它   发生。如果该值大于0，则块保留在旧值中   子列表，直到访问发生在第一个之后至少那么多ms   访问。例如，值1000会导致块保留旧值   在第一次访问之前，子列表成为1秒   有资格移动到新的子列表。

请参阅InnoDB缓冲池。（Bug＃45015）

有人可以解释一下innodb缓冲池行为....？

1 个答案: