安裝好mysql后,配制文件應(yīng)該在/usr/local/mysql/share/mysql目錄中,配制文件有幾個,有my- huge.cnf my-medium.cnf my-large.cnf my-small.cnf,不同的流量的網(wǎng)站和不同配制的服務(wù)器環(huán)境,當(dāng)然需要有不同的配制文件了。
一般的情況下,my-medium.cnf這個配制文件就能滿足我們的大多需要;一般我們會把配置文件拷貝到/etc/my.cnf 只需要修改這個配置文件就可以了,使用mysqladmin variables extended-status –u root –p 可以看到目前的參數(shù),有3個配置參數(shù)是最重要的,即:
|
key_buffer_size只對MyISAM表起作用。
key_buffer_size指定索引緩沖區(qū)的大小,它決定索引處理的速度,尤其是索引讀的速度。一般我們設(shè)為16M,實際上稍微大一點的站點 這個數(shù)字是遠(yuǎn)遠(yuǎn)不夠的,通過檢查狀態(tài)值Key_read_requests和Key_reads,可以知道key_buffer_size設(shè)置是否合理。比例key_reads / key_read_requests應(yīng)該盡可能的低,至少是1:100,1:1000更好(上述狀態(tài)值可以使用SHOW STATUS LIKE ‘key_read%'獲得)。 或者如果你裝了phpmyadmin 可以通過服務(wù)器運行狀態(tài)看到,筆者推薦用phpmyadmin管理mysql,以下的狀態(tài)值都是本人通過phpmyadmin獲得的實例分析:
這個服務(wù)器已經(jīng)運行了20天
|
比例接近1:8000 健康狀況非常好
另外一個估計key_buffer_size的辦法:把你網(wǎng)站數(shù)據(jù)庫的每個表的索引所占空間大小加起來看看以此服務(wù)器為例:比較大的幾個表索引加起來大概125M 這個數(shù)字會隨著表變大而變大。
從4.0.1開始,MySQL提供了查詢緩沖機制。使用查詢緩沖,MySQL將SELECT語句和查詢結(jié)果存放在緩沖區(qū)中,今后對于同樣的SELECT語句(區(qū)分大小寫),將直接從緩沖區(qū)中讀取結(jié)果。根據(jù)MySQL用戶手冊,使用查詢緩沖最多可以達(dá)到238%的效率。
通過調(diào)節(jié)以下幾個參數(shù)可以知道query_cache_size設(shè)置得是否合理
|
Qcache_lowmem_prunes的值非常大,則表明經(jīng)常出現(xiàn)緩沖不夠的情況,同時Qcache_hits的值非常大,則表明查詢緩沖使用非常頻繁,此時需要增加緩沖大小Qcache_hits的值不大,則表明你的查詢重復(fù)率很低,這種情況下使用查詢緩沖反而會影響效率,那么可以考慮不用查詢緩沖。此外,在SELECT語句中加入SQL_NO_CACHE可以明確表示不使用查詢緩沖。
Qcache_free_blocks,如果該值非常大,則表明緩沖區(qū)中碎片很多query_cache_type指定是否使用查詢緩沖
我設(shè)置:
|
得到如下狀態(tài)值:
|
如果內(nèi)存允許32M應(yīng)該要往上加點
table_cache指定表高速緩存的大小。每當(dāng)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)定或者連接失敗。
對于有1G內(nèi)存的機器,推薦值是128-256。
筆者設(shè)置table_cache = 256
得到以下狀態(tài):
|
雖然open_tables已經(jīng)等于table_cache,但是相對于服務(wù)器運行時間來說,已經(jīng)運行了20天,opened_tables的值也非常低。因此,增加table_cache的值應(yīng)該用處不大。如果運行了6個小時就出現(xiàn)上述值 那就要考慮增大table_cache。
如果你不需要記錄2進制log 就把這個功能關(guān)掉,注意關(guān)掉以后就不能恢復(fù)出問題前的數(shù)據(jù)了,需要您手動備份,二進制日志包含所有更新數(shù)據(jù)的語句,其目的是在恢復(fù)數(shù)據(jù)庫時用它來把數(shù)據(jù)盡可能恢復(fù)到最后的狀態(tài)。另外,如果做同步復(fù)制( Replication )的話,也需要使用二進制日志傳送修改情況。
log_bin指定日志文件,如果不提供文件名,MySQL將自己產(chǎn)生缺省文件名。MySQL會在文件名后面自動添加數(shù)字引,每次啟動服務(wù)時,都會重新生成一個新的二進制文件。
此外,使用log-bin-index可以指定索引文件;使用binlog-do-db可以指定記錄的數(shù)據(jù)庫;使用binlog-ignore-db可以指定不記錄的數(shù)據(jù)庫。注意的是:binlog-do-db和binlog-ignore-db一次只指定一個數(shù)據(jù)庫,指定多個數(shù)據(jù)庫需要多個語句。而且,MySQL會將所有的數(shù)據(jù)庫名稱改成小寫,在指定數(shù)據(jù)庫時必須全部使用小寫名字,否則不會起作用。
關(guān)掉這個功能只需要在他前面加上#號
#log-bin
開啟慢查詢?nèi)罩? slow query log ) 慢查詢?nèi)罩緦τ诟櫽袉栴}的查詢非常有用。它記錄所有查過long_query_time的查詢,如果需要,還可以記錄不使用索引的記錄。下面是一個慢查詢?nèi)罩镜睦樱?/p>
開啟慢查詢?nèi)罩荆枰O(shè)置參數(shù)log_slow_queries、long_query_times、log-queries-not-using-indexes。
log_slow_queries指定日志文件,如果不提供文件名,MySQL將自己產(chǎn)生缺省文件名。
long_query_times指定慢查詢的閾值,缺省是10秒。
log-queries-not-using-indexes是4.1.0以后引入的參數(shù),它指示記錄不使用索引的查詢。筆者設(shè)置long_query_time=10
筆者設(shè)置:
|
參數(shù)說明:
back_log
要求MySQL能有的連接數(shù)量。當(dāng)主要MySQL線程在一個很短時間內(nèi)得到非常多的連接請求,這就起作用,然后主線程花些時間(盡管很短) 檢查連接并且啟動一個新線程。back_log值指出在MySQL暫時停止回答新請求之前的短時間內(nèi)多少個請求可以被存在堆棧中。只有如果期望在一個短時間內(nèi)有很多連接,你需要增加它,換句話說,這值對到來的TCP/IP連接的偵聽隊列的大小。你的操作系統(tǒng)在這個隊列大小上有它自己的限制。 Unix listen(2)系統(tǒng)調(diào)用的手冊頁應(yīng)該有更多的細(xì)節(jié)。檢查你的OS文檔找出這個變量的最大值。試圖設(shè)定back_log高于你的操作系統(tǒng)的限制將是無效的。
max_connections
并發(fā)連接數(shù)目最大,120 超過這個值就會自動恢復(fù),出了問題能自動解決
thread_cache
沒找到具體說明,不過設(shè)置為32后 20天才創(chuàng)建了400多個線程 而以前一天就創(chuàng)建了上千個線程 所以還是有用的
thread_concurrency
#設(shè)置為你的cpu數(shù)目x2,例如,只有一個cpu,那么thread_concurrency=2
#有2個cpu,那么thread_concurrency=4
skip-innodb
#去掉innodb支持
代碼:
|
補充:
優(yōu)化table_cachetable_cache指定表高速緩存的大小。每當(dāng)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)定或者連接失敗。對于有1G內(nèi)存的機器,推薦值是128-256。
案例1:該案例來自一個不是特別繁忙的服務(wù)器
table_cache – 512
open_tables – 103
opened_tables – 1273
uptime – 4021421 (measured in seconds)
該案例中table_cache似乎設(shè)置得太高了。在峰值時間,打開表的數(shù)目比table_cache要少得多。
案例2:該案例來自一臺開發(fā)服務(wù)器。
table_cache – 64
open_tables – 64
opened-tables – 431
uptime – 1662790 (measured in seconds)
雖然open_tables已經(jīng)等于table_cache,但是相對于服務(wù)器運行時間來說,opened_tables的值也非常低。因此,增加table_cache的值應(yīng)該用處不大。
案例3:該案例來自一個upderperforming的服務(wù)器
table_cache – 64
open_tables – 64
opened_tables – 22423
uptime – 19538
該案例中table_cache設(shè)置得太低了。雖然運行時間不到6小時,open_tables達(dá)到了最大值,opened_tables的值也非常高。這樣就需要增加table_cache的值。優(yōu)化key_buffer_sizekey_buffer_size指定索引緩沖區(qū)的大小,它決定索引處理的速度,尤其是索引讀的速度。通過檢查狀態(tài)值Key_read_requests和Key_reads,可以知道key_buffer_size 設(shè)置是否合理。比例key_reads / key_read_requests應(yīng)該盡可能的低,至少是1:100,1:1000更好(上述狀態(tài)值可以使用SHOW STATUS LIKE ‘key_read%'獲得)。key_buffer_size只對MyISAM表起作用。即使你不使用MyISAM表,但是內(nèi)部的臨時磁盤表是 MyISAM表,也要使用該值。可以使用檢查狀態(tài)值created_tmp_disk_tables得知詳情。對于1G內(nèi)存的機器,如果不使用 MyISAM表,推薦值是16M(8-64M)。
案例1:健康狀況
key_buffer_size – 402649088 (384M)
key_read_requests – 597579931
key_reads - 56188
案例2:警報狀態(tài)
key_buffer_size – 16777216 (16M)
key_read_requests – 597579931
key_reads - 53832731
案例1中比例低于1:10000,是健康的情況;案例2中比例達(dá)到1:11,警報已經(jīng)拉響。