Mysql優化調優中兩個主要參數table_cache和key_buffer。本站提示廣大學習愛好者：（Mysql優化調優中兩個主要參數table_cache和key_buffer）文章只能為提供參考，不一定能成為您想要的結果。以下是Mysql優化調優中兩個主要參數table_cache和key_buffer正文
本文依據作者的一點經歷，評論辯論了Mysql辦事器優化中兩個異常主要的參數，分離是table_cache，key_buffer_size。
table_cache指導表高速緩存的年夜小。當Mysql拜訪一個表時，假如在Mysql表緩沖區中還有空間，那末這個表就被翻開並放入表緩沖區，如許做的利益是可以更疾速地拜訪表中的內容。普通來講，可以經由過程檢查數據庫運轉峰值時光的狀況值Open_tables和Opened_tables，用以斷定能否須要增長table_cache的值，即假如open_tables接近table_cache的時刻，而且Opened_tables這個值在慢慢增長，那就要斟酌增長這個值的年夜小了。
在mysql默許裝置情形下，table_cache的值在2G內存以下的機械中的值默許時256到512，假如機械有4G內存,則默許這個值是2048，但這決意味著機械內存越年夜，這個值應當越年夜，由於table_cache加年夜後，使得mysql對SQL呼應的速度更快了，弗成防止的會發生更多的逝世鎖（dead lock），如許反而使得數據庫全部一套操作慢了上去，嚴重影響機能。所以日常平凡保護中照樣要依據庫的現實情形去作出斷定，找到最合適你保護的庫的table_cache值，有人說：“機能優化是一門藝術”，這話一點沒錯。年夜凡藝術品，年夜都是經由千錘百煉，精雕細琢而成。
這裡還要解釋一個成績，就是table_cache加年夜後碰著文件描寫符不敷用的成績，在mysql的設置裝備擺設文件中有這麼一段提醒
援用
“The number of open tables for all threads. Increasing this value increases the number of file descriptors that mysqld requires.
Therefore you have to make sure to set the amount of open files allowed to at least 4096 in the variable "open-files-limit" in” section [mysqld_safe]”
說的就是要留意這個成績，一想到這裡，部門兄弟能夠會用ulimit -n 作出調劑，然則這個調劑現實是纰謬的，換個終端後，這個值又會回到原始值，所以最好用sysctl或許修正/etc/sysctl.conf文件，同時還要在設置裝備擺設文件中把open_files_limit這個參數增年夜，關於4G內存辦事器，信任如今購置的辦事器都差不多用4G的了，那這個這個open_files_limit至多要增年夜到4096，假如沒有甚麼特別情形，設置成8192便可以了。
上面說說key_buffer_size這個參數，key_buffer_sizeO表現索引緩沖區的年夜小，嚴厲說是它決議了數據庫索引處置的速度，特別是索引讀的速度。依據收集一些高手寫的文章表現可以檢討狀況值Key_read_requests和Key_reads，便可曉得key_buffer_size設置能否公道。比例key_reads / key_read_requests應當盡量的低，至多是1:100，1:1000更好，固然我還沒有找到實際的根據，然則，我在本身保護的幾台現實運轉優越的庫做過的測試後注解，這個比值接近1：20000，這從成果證實了他們說這話的准確性，我們無妨用之。
