低MySQL表緩存命中率

Question

我一直在優化我的網站和數據庫，我一直在使用mysqltuner.pl來幫助解決這個問題。除了表緩存命中率之外，我已經得到了一切正確的結果，不管我在my.cnf中提高了多高，我仍然達到0％（打開284個/ 79k）。

我的問題是我真的不明白究竟是什麼影響這個，所以我真的不知道在我的查詢/數據庫結構中尋找什麼來解決這個問題。

Answer 1

緩存應該保留熱數據的副本。熱數據是大量使用的數據。如果您無法從某個緩存中檢索數據，則意味着數據庫必須轉到磁盤才能檢索到該數據。

- 編輯 -

對不起，如果定義顯得有點討厭。一個特定的緩存經常覆蓋很多實體，並且這些實體都是特定於數據庫的，您需要首先找出緩存的內容。

--edit：一些調查 -

好吧，it seems（從回覆這個帖子），即MySQL使用的用來表示一個表中的數據結構表緩存。數據結構（通過封裝或通過爲每個表具有重複的表項）表示爲文件系統上的數據文件打開的一組文件描述符。 MyIsam引擎使用一個表作爲索引，另外每個索引使用一個索引，另外每個活動查詢元素都需要自己的描述符。

文件描述符是用於文件IO的內核實體，它表示特定文件讀取或寫入的低級上下文。

我認爲你要麼不正確地解釋該值，要麼在這種情況下需要對它們進行不同的解釋。 284是您獲取快照的實例中的活動表的數量，第二個值表示自啓動Mysql後獲取表的次數。

我會冒險猜測您需要對此讀數執行多個快照，並查看第一個值（在該實例中的活動fd）是否超過您的高速緩存容量。

p.s.內核通常對每個進程打開的文件描述符數量有一個上限 - 所以你可能需要調整它，如果它太低。

Answer 2

table cache定義了MySQL打開的併發文件描述符的數量。因此，表緩存命中率將受到相對於您的限制的表數量以及重新引用表的頻率的影響（請記住，它不僅計算單個連接，而且同時連接）

例如，如果您的限制爲100，並且您有101個表，並且您按順序查詢每個表，則永遠不會獲得任何表緩存命中。另一方面，如果你只有一個表，你通常應該接近100％命中率，除非你運行FLUSH TABLES很多（只要你的table_cache被設置爲高於通常同時連接的數量）。

因此，對於調整，您需要查看一個進程/客戶端可能引用多少個不同的表，然後查看您通常可能擁有多少個同時連接。

沒有更多的細節，我不能猜測你的情況是由於太多的同時連接或太多頻繁引用的表。