鍘熸枃鏉ユ簮錛?http://www.mysqlperformanceblog.com/2006/09/29/what-to-tune-in-mysql-server-after-installation
璇戣咃細(xì)鍙墮噾鑽ｏ紙Email:
錛夛紝杞澆璇鋒敞鏄庤瘧鑰呭拰鍑哄錛屽茍涓斾笉鑳界敤浜庡晢涓氱敤閫旓紝榪濊呭繀絀躲?/span>
My favorite question during Interview for people to work as MySQL DBAs or be involved with MySQL Performance in some way is to ask them what should be tuned in MySQL Server straight after installation, assuming it was installed with default settings.
鍦ㄩ潰璇昅ySQL DBA鎴栬呴偅浜涙墦綆楀仛MySQL鎬ц兘浼樺寲鐨勪漢鏃訛紝鎴戞渶鍠滄闂鏄細(xì)MySQL鏈嶅姟鍣ㄦ寜鐓ч粯璁よ緗畨瑁呭畬涔嬪悗錛屽簲璇ュ仛鍝簺鏂歸潰鐨勮皟鑺傚憿錛?/p>
I鈥檓 surprised how many people fail to provide any reasonable answer to this question, and how many servers are where in wild which are running with default settings.
浠ゆ垜寰堟儕璁剁殑鏄紝鏈夊灝戜漢瀵硅繖涓棶棰樻棤娉曠粰鍑哄悎鐞嗙殑絳旀錛屽張鏈夊灝戞湇鍔″櫒閮借繍琛屽湪榛樿鐨勮緗笅銆?/p>
Even though you can tune quite a lot of variables in MySQL Servers only few of them are really important for most common workload. After you get these settings right other changes will most commonly offer only incremental performance improvements.
灝界浣犲彲浠ヨ皟鑺傚緢澶歁ySQL鏈嶅姟鍣ㄤ笂鐨勫彉閲忥紝浣嗘槸鍦ㄥぇ澶氭暟閫氬父鐨勫伐浣滆礋杞戒笅錛屽彧鏈夊皯鏁板嚑涓墠鐪熸閲嶈銆傚鏋滀綘鎶婅繖浜涘彉閲忚緗紜簡(jiǎn)錛岄偅涔堜慨鏀瑰叾浠栧彉閲忔渶澶氬彧鑳藉緋葷粺鎬ц兘鏀瑰杽鏈変竴瀹氭彁鍗囥?/p>
key_buffer_size - Very important if you use MyISAM tables. Set up to 30-40% of available memory if you use MyISAM tables exclusively. Right size depends on amount of indexes, data size and workload - remember MyISAM uses OS cache to cache the data so you need to leave memory for it as well, and data can be much larger than indexes in many cases. Check however if all of key_buffer is used over time - it is not rare to see key_buffer being set to 4G while combined size of .MYI files is just 1GB. This would be just a waste. If you use few MyISAM tables you鈥檒l want to keep it lower but still at least 16-32Mb so it is large enough to accommodate indexes for temporary tables which are created on disk.
key_buffer_size - 榪欏MyISAM琛ㄦ潵璇撮潪甯擱噸瑕併傚鏋滃彧鏄嬌鐢∕yISAM琛紝鍙互鎶婂畠璁劇疆涓哄彲鐢ㄥ唴瀛樼殑 30-40%銆傚悎鐞嗙殑鍊煎彇鍐充簬绱㈠紩澶у皬銆佹暟鎹噺浠ュ強(qiáng)璐熻澆 -- 璁頒綇錛孧yISAM琛ㄤ細(xì)浣跨敤鎿嶄綔緋葷粺鐨勭紦瀛樻潵緙撳瓨鏁版嵁錛屽洜姝ら渶瑕佺暀鍑洪儴鍒嗗唴瀛樼粰瀹冧滑錛屽緢澶氭儏鍐典笅鏁版嵁姣旂儲(chǔ)寮曞ぇ澶氫簡(jiǎn)銆傚敖綆″姝わ紝闇瑕佹繪槸媯(gè)鏌ユ槸鍚︽墍鏈夌殑 key_buffer 閮借鍒╃敤浜?-- .MYI 鏂囦歡鍙湁 1GB錛岃?key_buffer 鍗磋緗負(fù) 4GB 鐨勬儏鍐墊槸闈炲父灝戠殑銆傝繖涔堝仛澶氮璐逛簡(jiǎn)銆傚鏋滀綘寰堝皯浣跨敤MyISAM琛紝閭ｄ箞涔熶繚鐣欎綆浜?16-32MB 鐨?key_buffer_size 浠ラ傚簲緇欎簣紓佺洏鐨勪復(fù)鏃惰〃绱㈠紩鎵闇銆?/p>
innodb_buffer_pool_size This is very important variable to tune if you鈥檙e using Innodb tables. Innodb tables are much more sensitive to buffer size compared to MyISAM. MyISAM may work kind of OK with default key_buffer_size even with large data set but it will crawl with default innodb_buffer_pool_size. Also Innodb buffer pool caches both data and index pages so you do not need to leave space for OS cache so values up to 70-80% of memory often make sense for Innodb only installations. Same rules as for key_buffer apply - if you have small data set and it is not going to grow dramatically do not oversize innodb_buffer_pool_size you might find better use for memory available.
innodb_buffer_pool_size - 榪欏Innodb琛ㄦ潵璇撮潪甯擱噸瑕併侷nnodb鐩告瘮MyISAM琛ㄥ緙撳啿鏇翠負(fù)鏁忔劅銆侻yISAM鍙互鍦ㄩ粯璁ょ殑 key_buffer_size 璁劇疆涓嬭繍琛岀殑鍙互錛岀劧鑰孖nnodb鍦ㄩ粯璁ょ殑 innodb_buffer_pool_size 璁劇疆涓嬪嵈璺熻湕鐗涗技鐨勩傜敱浜嶪nnodb鎶婃暟鎹拰绱㈠紩閮界紦瀛樿搗鏉ワ紝鏃犻渶鐣欑粰鎿嶄綔緋葷粺澶鐨勫唴瀛橈紝鍥犳濡傛灉鍙渶瑕佺敤Innodb鐨勮瘽鍒欏彲浠ヨ緗畠楂樿揪 70-80% 鐨勫彲鐢ㄥ唴瀛樸備竴浜涘簲鐢ㄤ簬 key_buffer 鐨勮鍒欐湁 -- 濡傛灉浣犵殑鏁版嵁閲忎笉澶э紝騫朵笖涓嶄細(xì)鏆村錛岄偅涔堟棤闇鎶?innodb_buffer_pool_size 璁劇疆鐨勫お澶т簡(jiǎn)銆?/p>
innodb_additional_pool_size This one does not really affect performance too much, at least on OS with decent memory allocators. Still you might want to have it 20MB (sometimes larger) so you can see how much memory Innodb allocates for misc needs.
innodb_additional_pool_size - 榪欎釜閫夐」瀵規(guī)ц兘褰卞搷騫朵笉澶錛岃嚦灝戝湪鏈夊樊涓嶅瓚沖鍐呭瓨鍙垎閰嶇殑鎿嶄綔緋葷粺涓婃槸榪欐牱銆備笉榪囧鏋滀綘浠嶇劧鎯寵緗負(fù) 20MB(鎴栬呮洿澶?錛屽洜姝ゅ氨闇瑕佺湅涓涓婭nnodb鍏朵粬闇瑕佸垎閰嶇殑鍐呭瓨鏈夊灝戙?/p>
innodb_log_file_size Very important for write intensive workloads especially for large data sets. Larger sizes offer better performance but increase recovery times so be careful. I normally use values 64M-512M depending on server size.
innodb_log_file_size 鍦ㄩ珮鍐欏叆璐熻澆灝ゅ叾鏄ぇ鏁版嵁闆嗙殑鎯呭喌涓嬪緢閲嶈銆傝繖涓艱秺澶у垯鎬ц兘鐩稿瓚婇珮錛屼絾鏄娉ㄦ剰鍒板彲鑳戒細(xì)澧炲姞鎭㈠鏃墮棿銆傛垜緇忓父璁劇疆涓?64-512MB錛岃窡鎹湇鍔″櫒澶у皬鑰屽紓銆?/p>
innodb_log_buffer_size Default for this one is kind of OK for many workloads with medium write load and shorter transactions. If you have update activity spikes however or work with blobs a lot you might want to increase it. Do not set it too high however as it would be waste of memory - it is flushed every 1 sec anyway so you do not need space for more than 1 sec worth of updates. 8MB-16MB are typically enough. Smaller installations should use smaller values.
innodb_log_buffer_size 榛樿鐨勮緗湪涓瓑寮哄害鍐欏叆璐熻澆浠ュ強(qiáng)杈冪煭浜嬪姟鐨勬儏鍐典笅錛屾湇鍔″櫒鎬ц兘榪樺彲浠ャ傚鏋滃瓨鍦ㄦ洿鏂版搷浣滃嘲鍊兼垨鑰呰礋杞借緝澶э紝灝卞簲璇ヨ冭檻鍔犲ぇ瀹冪殑鍊間簡(jiǎn)銆傚鏋滃畠鐨勫艱緗お楂樹簡(jiǎn)錛屽彲鑳戒細(xì)嫻垂鍐呭瓨 -- 瀹冩瘡縐掗兘浼?xì)鍒锋栴C竴嬈★紝鍥犳鏃犻渶璁劇疆瓚呰繃1縐掓墍闇鐨勫唴瀛樼┖闂淬傞氬父 8-16MB 灝辮凍澶熶簡(jiǎn)銆傝秺灝忕殑緋葷粺瀹冪殑鍊艱秺灝忋?/p>
innodb_flush_logs_at_trx_commit Crying about Innodb being 100 times slower than MyISAM ? You probably forgot to adjust this value. Default value of 1 will mean each update transaction commit (or each statement outside of transaction) will need to flush log to the disk which is rather expensive, especially if you do not have Battery backed up cache. Many applications, especially those moved from MyISAM tables are OK with value 2 which means do not flush log to the disk but only flush it to OS cache. The log is still flushed to the disk each second so you normally would not loose more than 1-2 sec worth of updates. Value 0 is a bit faster but is a bit less secure as you can lose transactions even in case MySQL Server crashes. Value 2 only cause data loss with full OS crash.
innodb_flush_logs_at_trx_commit 鏄惁涓篒nnodb姣擬yISAM鎱?000鍊嶈屽ご澶э紵鐪嬫潵涔熻浣犲繕浜?jiǎn)淇敼杩欎釜鍙傛曨C簡(jiǎn)銆傞粯璁ゅ兼槸 1錛岃繖鎰忓懗鐫姣忔鎻愪氦鐨勬洿鏂頒簨鍔★紙鎴栬呮瘡涓簨鍔′箣澶栫殑璇彞錛夐兘浼?xì)鍒锋柊鍒凹倎鐩樹腑锛岃岃繖鐩稿綋鑰楄垂璧勬簮錛屽挨鍏舵槸娌℃湁鐢墊睜澶囩敤緙撳瓨鏃躲傚緢澶氬簲鐢ㄧ▼搴忥紝灝ゅ叾鏄粠 MyISAM杞彉榪囨潵鐨勯偅浜涳紝鎶婂畠鐨勫艱緗負(fù) 2 灝卞彲浠ヤ簡(jiǎn)錛屼篃灝辨槸涓嶆妸鏃ュ織鍒鋒柊鍒扮鐩樹笂錛岃屽彧鍒鋒柊鍒版搷浣滅郴緇熺殑緙撳瓨涓娿傛棩蹇椾粛鐒朵細(xì)姣忕鍒鋒柊鍒扮鐩樹腑鍘伙紝鍥犳閫氬父涓嶄細(xì)涓㈠け姣忕1-2嬈℃洿鏂扮殑娑堣椼傚鏋滆緗負(fù) 0 灝卞揩寰堝浜?jiǎn)锛屼笉杩囦篃鐩稿涓嶅畨鍏ㄤ?-- MySQL鏈嶅姟鍣ㄥ穿婧冩椂灝變細(xì)涓㈠け涓浜涗簨鍔°傝緗負(fù) 2 鎸囨尌涓㈠け鍒鋒柊鍒版搷浣滅郴緇熺紦瀛樼殑閭ｉ儴鍒嗕簨鍔°?/p>
table_cache - Opening tables can be expensive. For example MyISAM tables mark MYI header to mark table as currently in use. You do not want this to happen so frequently and it is typically best to size your cache so it is large enough to keep most of your tables open. It uses some OS resources and some memory but for modern hardware it is typically not the problem. 1024 is good value for applications with couple hundreds tables (remember each connection needs its own entry) if you have many connections or many tables increase it larger. I鈥檝e seen values over 100.000 used.
table_cache -- 鎵撳紑涓涓〃鐨勫紑閿鍙兘寰堝ぇ銆備緥濡侻yISAM鎶奙YI鏂囦歡澶存爣蹇楄琛ㄦ鍦ㄤ嬌鐢ㄤ腑銆備綘鑲畾涓嶅笇鏈涜繖縐嶆搷浣滃お棰戠箒錛屾墍浠ラ氬父瑕佸姞澶х紦瀛樻暟閲忥紝浣垮緱瓚充互鏈澶ч檺搴﹀湴緙撳瓨鎵撳紑鐨勮〃銆傚畠闇瑕佺敤鍒版搷浣滅郴緇熺殑璧勬簮浠ュ強(qiáng)鍐呭瓨錛屽褰撳墠鐨勭‖浠墮厤緗潵璇村綋鐒朵笉鏄粈涔堥棶棰樹簡(jiǎn)銆傚鏋滀綘鏈?00澶氫釜琛ㄧ殑璇濓紝閭ｄ箞璁劇疆涓?1024 涔熻姣旇緝鍚堥傦紙姣忎釜綰跨▼閮介渶瑕佹墦寮琛級(jí)錛屽鏋滆繛鎺ユ暟姣旇緝澶ч偅涔堝氨鍔犲ぇ瀹冪殑鍊箋傛垜鏇劇粡瑙佽繃璁劇疆涓?100,000 鐨勬儏鍐點(diǎn)?/p>
thread_cache Thread creation/destructions can be expensive, which happen at each connect/disconnect. I normally set this value to at least 16. If application has large jumps in amount of concurrent connections and I see fast growth of
Threads_Created variable I boost it higher. The goal is not to have threads created in normal operation.
thread_cache -- 綰跨▼鐨勫垱寤哄拰閿姣佺殑寮閿鍙兘寰堝ぇ錛屽洜涓烘瘡涓嚎紼嬬殑榪炴帴/鏂紑閮介渶瑕併傛垜閫氬父鑷沖皯璁劇疆涓?16銆傚鏋滃簲鐢ㄧ▼搴忎腑鏈夊ぇ閲忕殑璺寵穬騫跺彂榪炴帴騫朵笖 Threads_Created 鐨勫間篃姣旇緝澶э紝閭ｄ箞鎴戝氨浼?xì)鍔犲ぇ瀹冪殑鍊箋傚畠鐨勭洰鐨勬槸鍦ㄩ氬父鐨勬搷浣滀腑鏃犻渶鍒涘緩鏂扮嚎紼嬨?/p>
query_cache If your application is read intensive and you do not have application level caches this can be great help. Do not set it too large as it may slow things down as its maintenance may get expensive. Values from 32M to 512M normally make sense. Check it however after a while and see if it is well used. For certain workloads cache hit ratio is lower than would justify having it enabled.
query_cache -- 濡傛灉浣犵殑搴旂敤紼嬪簭鏈夊ぇ閲忚錛岃屼笖娌℃湁搴旂敤紼嬪簭綰у埆鐨勭紦瀛橈紝閭ｄ箞榪欏緢鏈夌敤銆備笉瑕佹妸瀹冭緗お澶т簡(jiǎn)錛屽洜涓烘兂瑕佺淮鎶ゅ畠涔熼渶瑕佷笉灝戝紑閿錛岃繖浼?xì)瀵艰嚧MySQL鍙樻參銆傞氬父璁劇疆涓?32-512Mb銆傝緗畬涔嬪悗鏈濂芥槸璺熻釜涓孌墊椂闂達(dá)紝鏌ョ湅鏄惁榪愯鑹ソ銆傚湪涓瀹氱殑璐熻澆鍘嬪姏涓嬶紝濡傛灉緙撳瓨鍛戒腑鐜囧お浣庝簡(jiǎn)錛屽氨鍚敤瀹冦?/p>
Note: as you can see all of these are global variables. These variables depend on hardware and mix of storage engines, while per session variables are typically workload specific. If you have simple queries there is no reason to increase sort_buffer_size even if you have 64GB of memory to waste. Furthermore doing so may decrease performance.
I normally leave per session variable tuning to second step after I can analyze workload.
娉ㄦ剰錛?/strong>灝卞儚浣犵湅鍒扮殑涓婇潰榪欎簺鍏ㄥ眬琛ㄩ噺錛屽畠浠兘鏄緷鎹‖浠墮厤緗互鍙?qiáng)涓嶅悓鐨勫瓨鍌ㄥ紩鎿庤屼笉鍚岋紝浣嗘槸浼?xì)璇濆彉閲忛氬父鏄牴鎹笉鍚岀殑璐熻澆鏉ヨ瀹氱殑銆傚鏋滀綘鍙湁涓浜涚畝鍗曠殑鏌ヨ錛岄偅涔堝氨鏃犻渶澧炲姞 sort_buffer_size 鐨勫間簡(jiǎn)錛屽敖綆′綘鏈?64GB 鐨勫唴瀛樸傛悶涓嶅ソ涔熻浼?xì)闄嶄綆鎬ц兘銆?br />鎴戦氬父鍦ㄥ垎鏋愮郴緇熻礋杞藉悗鎵嶆潵璁劇疆浼?xì)璇濆彉閲忋?/p>
P.S Note MySQL distribution contains bunch of sample my.cnf files which may be great templates to use. Typically they would already be much better than defaults if you chose correct one. P.S錛孧ySQL鐨勫彂琛岀増宸茬粡鍖呭惈浜?jiǎn)鍚効U?my.cnf 鑼冧緥鏂囦歡浜?jiǎn)锛屽彲浠ヤ綔湄?fù)閰嶇疆妯℃澘浣跨敤銆傞氬父榪欐瘮浣犱嬌鐢ㄩ粯璁よ緗ソ鐨勫浜?jiǎn)銆?/p>