我所说的页数是指：https://dev.mysql.com/doc/internals/en/innodb-page-structure.html这些16kb的mysql页面会在内存或磁盘中碎片化吗？这意味着，如果我们使用磁盘映像或内存映像，是否有可能这些16kb的页面被碎片化？也就是说，如果我拍摄mysql文件夹的图像，16kb的页面会是连续的还是有些会变得支离破碎？或者mysql以一种不会被碎片化的方式来实现它们？如果是，怎么做？
dm7nw8vv1#
与mysql或innodb相比，这更像是一个文件系统或操作系统问题。innodb正在写入一个文件，而且确实有可能文件系统将写入的内容分割成一个16kib的innodb页，这样它在物理磁盘上就不连续了。但是，使用现代服务器和ssd存储，基本上100%的时间都是在底层介质上进行的。至少对我来说，这不是什么大问题。
1cklez4t2#
（我已经在你的类似问题中讨论了一段时间。我在这里给拉姆讲。）大约20年前，超过一半的CPU已经转移到“虚拟”地址，这与“物理”地址不同。为了实现这一点，硬件人员实现了一种“转换”机制，该机制将程序使用的32位（或64位）虚拟地址Map为访问ram的物理地址。这是在相对较低的硬件水平上完成的。随着硬件的出现，当物理地址被交换到磁盘或尚未分配给用户程序时，异常的处理也随之出现。为了保证翻译的精确性，制造商们大多选择4kb的页面大小。也就是说，底部的12位（2^12=4k）是通过翻译馈送的，不受影响；顶层位被Map（通过片上查找表，由ram中的数组支持），从虚拟到物理。这是为每一个内存访问（除了可能在引导期间）。通过这种机制，用户程序可以完全忘记4kb页面在ram中的位置，以及它们是否分散。一句话：忘记记忆图像。碎片化真的不是问题。另一方面，交换可能是一个问题。我认为mysql和innodb的设计是基于ram中的所有东西都留在ram中的假设。请注意它们是如何缓存数据块、索引块、表定义等的。因此，不要调优mysql以便系统需要交换。
2条答案
按热度按时间dm7nw8vv1#
与mysql或innodb相比，这更像是一个文件系统或操作系统问题。innodb正在写入一个文件，而且确实有可能文件系统将写入的内容分割成一个16kib的innodb页，这样它在物理磁盘上就不连续了。但是，使用现代服务器和ssd存储，基本上100%的时间都是在底层介质上进行的。
至少对我来说，这不是什么大问题。
1cklez4t2#
（我已经在你的类似问题中讨论了一段时间。我在这里给拉姆讲。）
大约20年前，超过一半的CPU已经转移到“虚拟”地址，这与“物理”地址不同。为了实现这一点，硬件人员实现了一种“转换”机制，该机制将程序使用的32位（或64位）虚拟地址Map为访问ram的物理地址。这是在相对较低的硬件水平上完成的。随着硬件的出现，当物理地址被交换到磁盘或尚未分配给用户程序时，异常的处理也随之出现。
为了保证翻译的精确性，制造商们大多选择4kb的页面大小。也就是说，底部的12位（2^12=4k）是通过翻译馈送的，不受影响；顶层位被Map（通过片上查找表，由ram中的数组支持），从虚拟到物理。这是为每一个内存访问（除了可能在引导期间）。
通过这种机制，用户程序可以完全忘记4kb页面在ram中的位置，以及它们是否分散。
一句话：忘记记忆图像。碎片化真的不是问题。
另一方面，交换可能是一个问题。我认为mysql和innodb的设计是基于ram中的所有东西都留在ram中的假设。请注意它们是如何缓存数据块、索引块、表定义等的。因此，不要调优mysql以便系统需要交换。