在一个有 100 万行的 TB 中，如果我这样做（在我重新启动计算机之后 - 因此没有缓存任何内容）：
1. SELECT price,city,state FROM tb1 WHERE zipId=13458;
结果是 0.270 秒内有 23 行
在我运行'LOAD INDEX INTO CACHE tb1'（key_buffer_size=128M，tb 的总索引大小为 82M）之后：
2. SELECT price,city,state FROM tb1 WHERE zipId=24781;
结果是 0.252 秒内有 23 行，Key_reads 保持不变，Key_read_requests 增加了 23
BUT将“zipId”加载到操作系统缓存后，如果我再次运行查询：
2. SELECT price,city,state FROM tb1 WHERE zipId=20548;
结果是 0.006 秒内有 22 行
这只是一个简单的例子，但我运行了几十次测试和组合。但结果总是相同的。
我使用：MySql 与 MyISAM，WINDOWS 7 64，query_cache 为 0；
key_cache 不应该比 OS cache 更快吗？
在我将索引加载到缓存中之后，速度不应该有很大差异吗？
（在我的测试中几乎没有区别）。
我读过很多关于这个问题的网站、教程和博客，但没有一个真正讨论过速度的差异。所以，任何想法或链接都将不胜感激。
谢谢。
答案1
所有查询都极有可能同时使用 myisam 键缓存和 OS 缓存。
MyISAM 使用自己的缓存来存储索引，使用操作系统的缓存来存储数据文件。“LOAD INDEX INTO cache”会加载整个索引（如果可能），但运行 select 只会加载所需的位，还会根据需要加载数据块。
“LOAD INDEX INTO cache” 不会加载数据文件块，只会加载索引块。索引块可能不会导致大多数 IO 满足查询要求。
您可以使用 EXPLAIN 检查解释计划，以查看查询是否使用覆盖索引 - 我认为不会。如果查询不使用覆盖索引，则需要一些磁盘 IO 来从数据文件中读取数据块，即使您执行了仅加载索引的“LOAD INDEX”。
我希望这是有道理的。
话虽如此，但在这么小的桌子上，这真的无关紧要。
操作系统缓存和密钥缓存执行不同的操作，有时都需要。
如果您有这么小的数据库，如果其内容实际上是只读的（即您不需要耐用性），请考虑从 ramdisc 中运行它