MySQL服務(wù)器端的參數(shù)有很多，但是對于大多數(shù)初學(xué)者來說，眾多的參數(shù)往往使得我們不知所措，但是哪些參數(shù)是需要我們調(diào)整的，哪些對服務(wù)器的性能影響最大呢？對于使用Myisam存儲引擎來說，主要有key_buffer_size和table_cache兩個參數(shù)。對于InnoDB引擎來說主要還是以innodb_開始的參數(shù)，也很好辨認。

查看MySQL參數(shù)，可以使用show variables和show status命令查看，前者查看服務(wù)器靜態(tài)參數(shù)，即在數(shù)據(jù)庫啟動后不會動態(tài)更改的值，比如緩沖區(qū)、字符集等。后者查看服務(wù)器的動態(tài)運行狀態(tài)信息，即數(shù)據(jù)庫運行期間動態(tài)變化的信息，比如鎖，當前連接數(shù)等。

key_buffer_size這個參數(shù)是用來設(shè)置索引塊（index blocks）緩存的大小，它被所有線程共享，嚴格說是它決定了數(shù)據(jù)庫索引處理的速度，尤其是索引讀的速度。那我們怎么才能知道key_buffer_size的設(shè)置是否合理呢，一般可以檢查狀態(tài)值Key_read_requests和Key_reads，比例key_reads / key_read_requests應(yīng)該盡可能的低，比如1:100，1:1000 ，1:10000。其值可以用以i下命令查得：

mysql> show status like 'key_read%';
+-------------------+------------+
| Variable_name     | Value      |
+-------------------+------------+
| Key_read_requests | 3916880184 |
| Key_reads         | 1014261    |
+-------------------+------------+
2 rows in set (0.00 sec)

3916880184/1024/1024=?M    //單位為兆

我的key_buffer_size值為：

key_buffer_size=536870912/1024/1024=512M,

key_reads / key_read_requests=1014261: 3916880184≈1:4000，照上面來看，健康狀況還行。

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

open_tables表示當前打開的表緩存數(shù)，如果執(zhí)行flush tables操作，則此系統(tǒng)會關(guān)閉一些當前沒有使用的表緩存而使得此狀態(tài)值減小；

opend_tables表示曾經(jīng)打開的表緩存數(shù)，會一直進行累加，如果執(zhí)行flush tables操作，值不會減小。

在mysql默認安裝情況下，table_cache的值在2G內(nèi)存以下的機器中的值默認時256到512，如果機器有4G內(nèi)存,則默認這個值是2048，但這決意味著機器內(nèi)存越大，這個值應(yīng)該越大，因為table_cache加大后，使得mysql對SQL響應(yīng)的速度更快了，不可避免的會產(chǎn)生更多的死鎖（dead lock），這樣反而使得數(shù)據(jù)庫整個一套操作慢了下來，嚴重影響性能。所以平時維護中還是要根據(jù)庫的實際情況去作出判斷，找到最適合你維護的庫的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 作出調(diào)整，但是這個調(diào)整實際是不對的，換個終端后，這個值又會回到原始值，所以最好用sysctl或者修改/etc/sysctl.conf文件，同時還要在配置文件中把open_files_limit這個參數(shù)增大，對于4G內(nèi)存服務(wù)器，相信現(xiàn)在購買的服務(wù)器都差不多用4G的了，那這個這個open_files_limit至少要增大到4096，如果沒有什么特殊情況，設(shè)置成8192就可以了。

innodb_buffer_pool_size 這個參數(shù)和MyISAM的key_buffer_size有相似之處，但也是有差別的。這個參數(shù)主要緩存innodb表的索引，數(shù)據(jù)，插入數(shù)據(jù)時的緩沖。為Innodb加速優(yōu)化首要參數(shù)?！　≡搮?shù)分配內(nèi)存的原則：這個參數(shù)默認分配只有8M，可以說是非常小的一個值。如果是一個專用ＤＢ服務(wù)器，那么他可以占到內(nèi)存的70%-80%。這個參數(shù)不能動態(tài)更改，所以分配需多考慮。分配過大，會使Swap占用過多，致使Mysql的查詢特慢。如果你的數(shù)據(jù)比較小，那么可分配是你的數(shù)據(jù)大?。保埃プ笥易鰹檫@個參數(shù)的值。

最新評論