什么是MySQL的“密钥效率”

“Key Efficiency”表示从MySQL内存中保存的索引缓存中获得了多少价值。如果您的密钥效率很高,那么MySQL通常从内存空间中执行密钥查找,这比从磁盘检索相关索引块要快得多。

然而,正如michaeleakins所指出的,操作系统还保存着最近访问过的磁盘块的缓存。操作系统可用的内存越多,它可以缓存的磁盘块就越多。此外,磁盘驱动器本身(在某些情况下还有磁盘控制器)也有缓存,这同样可以加快从磁盘检索数据的速度。层次结构有点像这样:

1. 最快-从MySQL的索引缓存中检索索引数据。代价是一些内存操作。
3. 检索保存在磁盘系统缓存(控制器和驱动器)中的索引数据。代价是系统调用(用于读取)、与磁盘设备的通信以及一些内存操作。

实际上,除非您的系统非常繁忙,否则1和2之间的差异几乎是不明显的。另外,场景3不太可能(除非您的系统的备用RAM少于磁盘控制器)。

我使用了MyISAM表的服务器,索引缓存相对较小(512MB),但系统内存却很大(64GB),我发现很难演示增加索引缓存大小的价值。我想这取决于你的服务器上发生了什么。如果您运行的只是一个MySQL数据库,那么OS缓存很可能非常有效。但是,如果您在同一台服务器上运行其他作业,并且这些作业使用大量内存/磁盘访问,那么这些作业可能会清除有价值的缓存索引块,从而导致MySQL更频繁地访问磁盘。

一个有趣的练习(如果你有时间的话)是修改你的系统使它运行得更慢。在大型表上运行标准工作负载,减少MySQL缓冲区,直到影响变得明显为止。通过文件系统(cat large file>/dev/null)泵送大量(大于RAM)的无关数据,刷新文件系统缓存。在查询运行时观察iostat。

“钥匙效率”不是衡量你的钥匙有多好的标准。与高“密钥效率”相比,设计良好的密钥对性能的影响要大得多。不幸的是,MySQL在这方面没有太多的帮助。

可以独立增长。 ( http://bugs.mysql.com/bug.php?id=28384 )

仍然像泥一样清澈。

接下来的解释是:

密钥读取的部分有效使用

有一个部分合理的理由 检查Key_reads,假设我们 因为我们知道 磁盘相对于其他磁盘非常慢 回到我所说的 “大部分是事实”,因为 磁盘完全读取。如果要求 系统的缓存,那么一个Key_read就是一个 磁盘读取——但是如果它被缓存,那么 让我们来证明我们的第一个很难证明 假设:

难以证明的假设#1:A 可能是物理磁盘读取。如果我们 我们可能还有其他的理由去关心 “缓存未命中是非常重要的 比缓存命中慢“,这使得 理智。如果能像现在这样快 键读作为键读请求,什么 使用密钥缓冲区吗? 第一,因为他们设计了一个缓存命中 ( http://planet.mysql.com/entry/?id=23679 )