哪個更快，key_cache 或 OS 記憶體？
在 1 百萬的 tb 中。如果我這樣做了行（在我重新啟動電腦之後 - 所以它沒有被記憶體）：
1. SELECT price,city,state FROM tb1 WHERE zipId=13458;結果是 23rows in 0.270s
在我執行’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 with MyISAM，WINDOWS 7 64，query_cache為0；
不應該 key_cache 比作業系統記憶體快？？
將索引載入到記憶體後，速度應該不會有很大差異？？
（在我的測試中幾乎沒有區別）。
我已經閱讀了很多關於這個問題的網站、教程和部落格，但沒有一個真正討論速度的差異。因此，任何想法或連結將不勝感激。
謝謝你。
很可能所有查詢都使用 myisam 鍵記憶體和作業系統記憶體。
MyISAM 使用自己的記憶體來儲存索引，而作業系統的記憶體用於數據文件。“LOAD INDEX INTO 記憶體”會載入整個索引（如果可能），但執行 select 只會載入所需的位，還會根據需要載入數據塊。
“LOAD INDEX INTO 記憶體”不載入數據文件塊，只載入索引塊。索引塊可能不會導致大多數 IO 滿足查詢。
您可以使用 EXPLAIN 檢查解釋計劃以查看查詢是否使用覆蓋索引 - 我希望它不會。如果查詢不使用覆蓋索引，則需要一些磁碟 IO 才能從數據文件中讀取數據塊，即使您已經完成了僅載入索引的“LOAD INDEX”。
我希望這有點道理。
話雖如此，在這樣一張微不足道的小桌子上，這真的無關緊要。
作業系統記憶體和密鑰記憶體做不同的事情，有時兩者都需要。
如果你有這麼小的數據庫，如果它的內容實際上是只讀的（即你不需要持久性），請考慮從 ramdisc 中執行它