共計 1165 個字符，預計需要花費 3 分鐘才能閱讀完成。

這篇文章主要介紹 MySQL 中 table_cache 優化的示例分析，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

table_cache 指定表高速緩存的大小。每當 MySQL 訪問一個表時，如果在表緩沖區中還有空間，該表就被打開并放入其中，這樣可以更快地訪問表內容。通過檢查峰值時間的狀態值 Open_tables 和 Opened_tables，可以決定是否需要增加 table_cache 的值。如果你發現 open_tables 等于 table_cache，并且 opened_tables 在不斷增長，那么你就需要增加 table_cache 的值了（上述狀態值可以使用 SHOW STATUS LIKE‘Open%tables’獲得）。注意，不能盲目地把 table_cache 設置成很大的值。如果設置得太高，可能會造成文件描述符不足，從而造成性能不穩定或者連接失敗。

首先是 MyISAM： 
從官方網站上面看，每個線程會獨自持有一個數據文件的文件描述符，而索引文件的文件描述符是公用的。當 table cache 不夠用的時候，MySQL 會采用 LRU 算法踢掉最長時間沒有使用的表。如果 table_cache 設置過小，MySQL 就會反復打開、關閉 frm 文件，造成一定的性能損失。那么，table_cache 設置是不是越大越好呢？從 table_cache negative scalability 這篇文章的測試可以看出，如果 table_cache 設置過大，MySQL 將會消耗很多 CPU 去做 table cache 的算法運算（具體是哪個算法目前不清楚，有可能是 LRU）。因此 table_cache 的值一定要設置合理，沒事多看一看 opened_tables 參數，如果一直增長的話，就需要適當增加 table_cache 的值了。 
 
接著是 InnoDB： 
InnoDB 的元數據管理是放在共享表空間里面做的，所以獲取表的結構不需要去反復解析 frm 文件，這是比 MyISAM 強的地方。即使 table_cache 設置過小，對于 InnoDB 的影響也是很小的，因為它根本不需要反復打開、關閉 frm 文件去獲取元數據。  根據 How innodb_open_files affects performance 這篇文章的測試可以看出，table_cache 和   innodb_open_files 的大小對 InnoDB 效率的影響比較小。但是在 InnoDB crash 的情況下，innodb_open_files 設置過小會影響 recovery 的效率。所以用 InnoDB 的時候還是把 innodb_open_files 放大一些比較合適。

以上是“MySQL 中 table_cache 優化的示例分析”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注丸趣 TV 行業資訊頻道！