本文根據(jù)作者的一點(diǎn)經(jīng)驗(yàn)，討論了Mysql服務(wù)器優(yōu)化中兩個非常重要的參數(shù)，分別是table_cache，key_buffer_size。

table_cache指示表高速緩存的大小。當(dāng)Mysql訪問一個表時，如果在Mysql表緩沖區(qū)中還有空間，那么這個表就被打開并放入表緩沖區(qū)，這樣做的好處是可以更快速地訪問表中的內(nèi)容。一般來說，可以通過查看數(shù)據(jù)庫運(yùn)行峰值時間的狀態(tài)值Open_tables和Opened_tables，用以判斷是否需要增加table_cache的值，即如果open_tables接近table_cache的時候，并且Opened_tables這個值在逐步增加，那就要考慮增加這個值的大小了。

在mysql默認(rèn)安裝情況下，table_cache的值在2G內(nèi)存以下的機(jī)器中的值默認(rèn)時256到512，如果機(jī)器有4G內(nèi)存,則默認(rèn)這個值是2048，但這決意味著機(jī)器內(nèi)存越大，這個值應(yīng)該越大，因?yàn)閠able_cache加大后，使得mysql對SQL響應(yīng)的速度更快了，不可避免的會產(chǎn)生更多的死鎖（dead lock），這樣反而使得數(shù)據(jù)庫整個一套操作慢了下來，嚴(yán)重影響性能。所以平時維護(hù)中還是要根據(jù)庫的實(shí)際情況去作出判斷，找到最適合你維護(hù)的庫的table_cache值，有人說：“性能優(yōu)化是一門藝術(shù)”，這話一點(diǎn)沒錯。大凡藝術(shù)品，大都是經(jīng)過千錘百煉，精雕細(xì)琢而成。

這里還要說明一個問題，就是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 作出調(diào)整，但是這個調(diào)整實(shí)際是不對的，換個終端后，這個值又會回到原始值，所以最好用sysctl或者修改/etc/sysctl.conf文件，同時還要在配置文件中把open_files_limit這個參數(shù)增大，對于4G內(nèi)存服務(wù)器，相信現(xiàn)在購買的服務(wù)器都差不多用4G的了，那這個這個open_files_limit至少要增大到4096，如果沒有什么特殊情況，設(shè)置成8192就可以了。

下面說說key_buffer_size這個參數(shù)，key_buffer_sizeO表示索引緩沖區(qū)的大小，嚴(yán)格說是它決定了數(shù)據(jù)庫索引處理的速度，尤其是索引讀的速度。根據(jù)網(wǎng)絡(luò)一些高手寫的文章表示可以檢查狀態(tài)值Key_read_requests和Key_reads，即可知道key_buffer_size設(shè)置是否合理。比例key_reads / key_read_requests應(yīng)該盡可能的低，至少是1:100，1:1000更好，雖然我還沒有找到理論的依據(jù)，但是，我在自己維護(hù)的幾臺實(shí)際運(yùn)行良好的庫做過的測試后表明，這個比值接近1：20000，這從結(jié)果證明了他們說這話的正確性，我們不妨用之。

最新評論