mysql性能優(yōu)化解決方案.doc

MySQL數(shù)據(jù)庫(kù)性能優(yōu)化Renhao 2011/11/301. 資源管理平臺(tái)數(shù)據(jù)庫(kù)1.1. 操作系統(tǒng)Red Hat Enterprise Linux Server release 5.4 (Tikanga)ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped32位Linux服務(wù)器，單獨(dú)作為MySQL服務(wù)器使用。1.2. MySQL系統(tǒng)使用的是MySQL5.1，最新的MySQL5.5較之老版本有了大幅改進(jìn)。主要體現(xiàn)在以下幾個(gè)方面：1） 默認(rèn)存儲(chǔ)引擎更改為InnoDBInnoDB作為成熟、高效的事務(wù)引擎，目前已經(jīng)廣泛使用，但MySQL5.1之前的版本默認(rèn)引擎均為MyISAM，此次MySQL5.5終于將默認(rèn)數(shù)據(jù)庫(kù)存儲(chǔ)引擎改為InnoDB，并且引進(jìn)了Innodb plugin 1.0.7。此次更新對(duì)數(shù)據(jù)庫(kù)的好處是顯而易見(jiàn)的：InnoDB的數(shù)據(jù)恢復(fù)時(shí)間從過(guò)去的一個(gè)甚至幾個(gè)小時(shí)，縮短到幾分鐘(InnoDB plugin 1.0.7，InnoDB plugin 1.1， 恢復(fù)時(shí)采用紅-黑樹(shù))。InnoDB Plugin 支持?jǐn)?shù)據(jù)壓縮存儲(chǔ)，節(jié)約存儲(chǔ)，提高內(nèi)存命中率，并且支持adaptive flush checkpoint, 可以在某些場(chǎng)合避免數(shù)據(jù)庫(kù)出現(xiàn)突發(fā)性能瓶頸。Multi Rollback Segments： 原來(lái)InnoDB只有一個(gè)Segment，同時(shí)只支持1023的并發(fā)?，F(xiàn)已擴(kuò)充到128個(gè)Segments，從而解決了高并發(fā)的限制。2） 多核性能提升Metadata Locking (MDL) Framework替換LOCK_open mutex (lock)，使得MySQL5.1及過(guò)去版本在多核心處理器上的性能瓶頸得到解決。3） 制功能(Replication)加強(qiáng)過(guò)去的異步復(fù)制方式意味著極端情況下的數(shù)據(jù)風(fēng)險(xiǎn)，MySQL5.5將首次支持半同步(semi-sync replication)在MySQL的高可用方案中將產(chǎn)生更多更加可靠的方案。4） 增強(qiáng)表分區(qū)功能MySQL 5.5的分區(qū)更易于使用的增強(qiáng)功能，以及TRUNCATE PARTITION命令都可以為管理和維護(hù)數(shù)據(jù)庫(kù)節(jié)省大量的時(shí)間，并且具有更加靈活高效的分區(qū)方式。1.3. CPU系統(tǒng)所用CPU是單個(gè)4核CPU。對(duì)于CPU密集的負(fù)載，MySQL通常從更快的CPU中獲益，而不是更多CPU。MySQL5.1的架構(gòu)對(duì)多CPU的擴(kuò)展性不好，并且MySQL不能在多個(gè)CPU上并行地運(yùn)行某個(gè)查詢，因此在對(duì)于單個(gè)CPU進(jìn)行密集的查詢時(shí)，CPU速度限制了響應(yīng)時(shí)間。為了實(shí)現(xiàn)低延遲，即快速響應(yīng)時(shí)間，需要快速的CPU，因?yàn)閱蝹€(gè)查詢只能使用一個(gè)CPU。值得注意的是，MySQL5.5在多核心處理器上的性能有了很大的提升。另外，MySQL在64位架構(gòu)上工作得更好，比32位架構(gòu)更能有效地使用大量?jī)?nèi)存。盡管本系統(tǒng)使用的是32位操作系統(tǒng)，CPU運(yùn)行在32位模式下，但它仍支持64位計(jì)算。（cat /proc/cpuinfo | grep flags | grep lm | wc -l）1.4. 磁盤(pán)空間系統(tǒng)的磁盤(pán)空間目前沒(méi)有壓力。1.5. 內(nèi)存內(nèi)存總大小為4G，只供操作系統(tǒng)和數(shù)據(jù)庫(kù)使用。1.6. 數(shù)據(jù)庫(kù)的表和文件數(shù)據(jù)庫(kù)addb共有339張表：其中InnoDB表303張，MyISAM表34張，MEMORY表2張。InnoDB數(shù)據(jù)文件ibdata1大小為30138MB，一周后ibdata1大小為30234MB， MyISAM數(shù)據(jù)文件（包括表結(jié)構(gòu)、索引及數(shù)據(jù)）總大小約為1642MB，一周后約為1639MB。可以看出，數(shù)據(jù)庫(kù)的數(shù)據(jù)量較穩(wěn)定，InnoDB數(shù)據(jù)文件增加了約106MB，總大小一周內(nèi)沒(méi)有大的變化。MyISAM表中，值得注意的是表terminalalarm_bak，該表總大小約為1623MB，占整個(gè)MyISAM表總大小比重近99%。二進(jìn)制日志單個(gè)文件大小為1GB，二進(jìn)制日志文件總大小接近20GB。1.7. 數(shù)據(jù)分布情況服務(wù)器某時(shí)間點(diǎn)非精確值：數(shù)據(jù)量范圍表數(shù)量（總共339張，其中分區(qū)表2張）1000萬(wàn)rows5000萬(wàn)4張（MyISAM表1張）500萬(wàn)rows1000萬(wàn)6張100萬(wàn)rows500萬(wàn)5張50萬(wàn)rows100萬(wàn)4張10萬(wàn)rows50萬(wàn)12張（MyISAM表1張）5萬(wàn)rows10萬(wàn)9張（MyISAM表1張）1萬(wàn)rows5萬(wàn)23張（MyISAM表2張）1 rows1萬(wàn)136張（MyISAM表9張，MEMORY表2張）rows=0（無(wú)數(shù)據(jù)）140張觀察系統(tǒng)中數(shù)據(jù)量很大且未進(jìn)行表分區(qū)的InnoDB表l adrotateresultdetail_fail的數(shù)據(jù)量達(dá)到4千萬(wàn)，createTime列是datatime類型，且有索引，意味著存在以該列為查詢條件或關(guān)聯(lián)條件查詢的需求，因此可以在該列上以自然月份進(jìn)行表分區(qū)。l terminalalarm的數(shù)據(jù)量也突破千萬(wàn)，AlarmTime列是datatime類型，且有索引，意味著存在以該列為查詢條件或關(guān)聯(lián)條件查詢的需求，因此可以在該列上以自然月份進(jìn)行表分區(qū)。在事件ev_terminalalarm中會(huì)查詢?cè)摫?，若進(jìn)行表分區(qū)，也能一定程度上提高事件的執(zhí)行效率。l terminalalarminfo表僅自增列有索引，主要用于存儲(chǔ)數(shù)據(jù)，可不用分區(qū)。l Terminallogin表的loginTime列是datatime類型，且有索引，意味著存在以該列為查詢條件或關(guān)聯(lián)條件查詢的需求，因此可以在該列上以自然月份進(jìn)行表分區(qū)。l adplayinfo_bak表存在多個(gè)以INT類型為索引的列，根據(jù)實(shí)際業(yè)務(wù)情況選擇查詢頻率高且能以范圍值來(lái)分區(qū)的整型列對(duì)該表進(jìn)行分區(qū)。l adrotateresultdetail的createTime列是datatime類型，且有索引，意味著存在以該列為查詢條件或關(guān)聯(lián)條件查詢的需求，因此可以在該列上以自然月份進(jìn)行表分區(qū)。l upfile_bak表僅自增列有索引，若存在查詢或者統(tǒng)計(jì)業(yè)務(wù)則可以createTime列進(jìn)行分區(qū)，若該表沒(méi)有查詢方面業(yè)務(wù)可不必進(jìn)行分區(qū)。除去配置參數(shù)等屬性表，對(duì)于數(shù)據(jù)量大且不斷遞增的業(yè)務(wù)數(shù)據(jù)表，最直接的辦法可以按照時(shí)間字段進(jìn)行分區(qū)，或是根據(jù)查詢業(yè)務(wù)來(lái)選擇合適的列進(jìn)行表分區(qū)和創(chuàng)建索引，這樣能夠有效提高存儲(chǔ)和查詢效率。1.8. 服務(wù)器配置參數(shù)記錄查詢：普通日志log、慢速日志log_slow_queriesMySQL有兩種查詢?nèi)罩荆浩胀ㄈ罩竞吐偃罩荆鼈兌紩?huì)記錄查詢。普通日志記錄了服務(wù)器接收到的每一個(gè)查詢，也包含了沒(méi)有被執(zhí)行的查詢，比如因?yàn)殄e(cuò)誤而未被執(zhí)行的查詢，還有一些非查詢事件，比如連接和斷開(kāi)連接，普通日志不包含執(zhí)行時(shí)間或其他只有在查詢結(jié)束之后才能得到的信息。相反，慢速日志只包含了已經(jīng)執(zhí)行過(guò)的查詢，如果是啟動(dòng)狀態(tài)，它記錄了執(zhí)行時(shí)間超過(guò)了特定長(zhǎng)度的查詢。兩種日志都有助于分析，但是慢速日志更有利找到性能較慢的查詢。一個(gè)相關(guān)配置是log_queries_not_using_indexes，它使服務(wù)器把沒(méi)有使用索引的查詢記錄到慢速查詢?nèi)罩局校瑹o(wú)論它們執(zhí)行速度有多快。盡管打開(kāi)慢速日志相對(duì)于執(zhí)行慢速查詢來(lái)說(shuō)，通常只增加了很少的時(shí)間，但是如果沒(méi)有使用索引的查詢非常快，例如從小數(shù)據(jù)量表中查詢，這樣就會(huì)記錄它們可能導(dǎo)致服務(wù)器變慢，甚至還會(huì)使用大量的磁盤(pán)空間，慢速日志也許就會(huì)被那些快速高效的查詢?nèi)麧M。慢查詢?nèi)罩究梢杂脕?lái)找到執(zhí)行時(shí)間長(zhǎng)的查詢，可以用于優(yōu)化。慢日志打開(kāi)后，通過(guò)設(shè)置long_query_time來(lái)配置記錄查詢超過(guò)的指定時(shí)間，默認(rèn)值為10秒，根據(jù)系統(tǒng)的負(fù)載和性能要求進(jìn)行設(shè)置(SET GLOBAL long_query_time = )。檢查又長(zhǎng)又慢的查詢?nèi)罩緯?huì)很麻煩，可以使用MySQLdumpslow命令獲得日志中顯示的查詢摘要來(lái)處理慢查詢?nèi)罩?。系統(tǒng)兩種日志都沒(méi)有開(kāi)啟，可以在需要的時(shí)候打開(kāi)慢速日志來(lái)幫助分析性能較慢的查詢。具體實(shí)施參考MySQL手冊(cè)。需要注意的是查詢?cè)谌罩局兄怀霈F(xiàn)一次并不意味著它是一個(gè)不好的查詢，也不意味將來(lái)也會(huì)慢，查詢時(shí)快是慢有多種原因：1） 表也許被鎖定，導(dǎo)致查詢處于等待狀態(tài)；2） 數(shù)據(jù)或索引也許沒(méi)有被緩存在內(nèi)存中；3） 或者正在進(jìn)行批處理大量的數(shù)據(jù)，使得磁盤(pán)I/O變慢；4） 服務(wù)器可能同時(shí)在運(yùn)行其他的查詢，影響了當(dāng)前查詢的效率。因此，只能把慢速查詢?nèi)罩究闯烧{(diào)優(yōu)工作的一部分，可以用它來(lái)找到可疑的查詢，但需要對(duì)它們進(jìn)行仔細(xì)地排查和分析。u 啟用系統(tǒng)慢速日志，分析查詢性能慢的時(shí)候可以觀察該日志信息。Qcache_hitsCom_selectQcache_inserts檢查是否從查詢緩存中受益的最直接辦法就是檢查緩存命中率。它是提供緩存提供的查詢結(jié)果的數(shù)量，而不是服務(wù)器執(zhí)行的數(shù)量。當(dāng)服務(wù)器收到select語(yǔ)句的時(shí)候，Qcache_hits和Com_select這兩個(gè)變量會(huì)根據(jù)查詢緩存的情況進(jìn)行遞增。查詢緩存命中率的計(jì)算公式：Qcache_hits/(Qcache_hits+Com_select)，根據(jù)公式計(jì)算得出查詢緩存命中率為7%。初看上去該命中率很低，但注意到com_select等于qcache_inserts + qcache_not_cache + 權(quán)限檢查錯(cuò)誤的總和，即這個(gè)比率中包含了緩存失效的因素，而對(duì)于數(shù)據(jù)變更頻繁的系統(tǒng)來(lái)說(shuō)，緩存是及其容易失效的，表的任何時(shí)刻的數(shù)據(jù)插入或更新都會(huì)使該表的緩存失效，所以本系統(tǒng)緩存的插入率很低，拋開(kāi)失效的緩存因素，用如下公式計(jì)算緩存命中率：Qcache_hits/(Qcache_hits+Qcache_inserts)= 84.87%，該比值要好得多，意味著大部分的查詢都命中了緩存，換一種說(shuō)法就是仍有一小部分查詢沒(méi)有被緩存。沒(méi)被緩存和緩存失效是兩個(gè)概念，分別計(jì)數(shù)，但都會(huì)引起com_select的值增加。命中率要多少才好，這視情況而定，因?yàn)閷?duì)于每一個(gè)查詢，不執(zhí)行它所節(jié)約的資源遠(yuǎn)大于緩存中保存結(jié)果以及讓查詢失效的開(kāi)銷，如果緩存命中代表了開(kāi)銷最大的查詢，那么即使很低的命中率也是有好處的。緩存可能會(huì)因?yàn)樗槠?、?nèi)存不足或數(shù)據(jù)改變而失效。如果已經(jīng)給緩存分配了足夠的內(nèi)存，并且把Query_cache_min_res_unit調(diào)整到了合適的值，那么大部分緩存失效都應(yīng)該是由數(shù)據(jù)改變而引起的。Com_update, Com_delete等的值知道有多少查詢修改了數(shù)據(jù)，也可以通過(guò)檢查Qcache_lowmen_prunes的值了解有多少查詢因?yàn)閮?nèi)存不足而失效。u 接近85%的命中率可以滿足系統(tǒng)要求，如果該命中率持續(xù)降低則需要對(duì)系統(tǒng)進(jìn)行性能分析并調(diào)整。系統(tǒng)表數(shù)據(jù)變更頻繁，查詢緩存的失效率較高，如果對(duì)變更頻繁大表的查詢頻率較高，則使用SQL_NO_CACHE 和SQL_CACHE來(lái)控制是否需要使用查詢緩存。Query_cache_size分配給查詢的總內(nèi)存必須是1024的倍數(shù)，系統(tǒng)設(shè)置為128MB。在服務(wù)器啟動(dòng)的時(shí)候，MySQL會(huì)為查詢緩存一次性分配變量所定義數(shù)量的內(nèi)存。如果更新了變量，MySQL會(huì)立即刪除所有緩存的查詢，重新把緩存設(shè)置為定義的大小，并重新初始化緩存的內(nèi)存。Query_cache_type Query_cache_type設(shè)置在何場(chǎng)景下使用 Query Cache。系統(tǒng)的查詢緩存是開(kāi)啟狀態(tài)。_cache_type可以設(shè)置為0(OFF)，1(ON)或者2(DEMOND)，分別表示完全不使用query cache，除顯式要求不使用query cache(使用sql_no_cache)之外的所有的select都使用query cache，只有顯示要求才使用query cache(使用sql_cache)。Query_cache_limit該選項(xiàng)限制了MySQL存儲(chǔ)的最大結(jié)果為2M，如果查詢的結(jié)果比這個(gè)值大，那么就不會(huì)被緩存。服務(wù)器在產(chǎn)生結(jié)果的同時(shí)進(jìn)行緩存，它無(wú)法預(yù)先知道結(jié)果是否會(huì)超過(guò)這一限制。如果在緩存的過(guò)程中發(fā)現(xiàn)已經(jīng)超過(guò)了限制，MySQL會(huì)自動(dòng)增加Qcache_not_cached的值，并且丟掉已經(jīng)緩存過(guò)的值。如果預(yù)先判斷會(huì)有這種情況，可以給查詢加上SQL_NO_CHACHE來(lái)避免這種開(kāi)銷。u 以查詢某表（18列）中的5000條結(jié)果為例，結(jié)果集數(shù)據(jù)大小約為1.4M，該設(shè)置是能滿足要求的，保持該值即可。但如果查詢結(jié)果數(shù)據(jù)過(guò)萬(wàn)的情況較多的話則應(yīng)適當(dāng)增加該值，最大不要超過(guò)4M。Qcache_free_memory如果緩存由大結(jié)果和小結(jié)果混合而成，那么就很難找到一個(gè)合適的大小，既能避免碎片，也能避免過(guò)多的內(nèi)存分配，但是緩存大結(jié)果沒(méi)有太大的益處，可以通過(guò)降低Query_cache_limit的值阻止緩存大結(jié)果，它有時(shí)有助于在碎片和在緩存中保存結(jié)果的開(kāi)銷中得到平衡。Query_cache_min_res_unitQcache_free_blocksQcache_total_blocksQcache_lowmen_prunes可以通過(guò)檢查Qcache_free_blocks的值來(lái)觀察緩存中碎片的情況，它可以顯示緩存中有多少內(nèi)存塊處于空閑狀態(tài)。碎片最嚴(yán)重的情況就是在每?jī)蓚€(gè)存儲(chǔ)了數(shù)據(jù)的塊之間都有一個(gè)比最小值稍小的可用塊，這樣每隔一個(gè)存儲(chǔ)塊就有一個(gè)自由塊，因此，如果Qcache_free_blocks大致等于Qcache_total_blocks/2，則說(shuō)明碎片非常嚴(yán)重。Qcache_lowmem_prunes表示由于緩存內(nèi)存不足被清除出查詢緩存的條數(shù)，如果Qcache_lowmem_prunes的值正在增加，并且有大量的自由塊，就說(shuō)明碎片導(dǎo)致查詢正被從緩存中永久刪除。查詢緩存碎片率 = Qcache_free_blocks / Qcache_total_blocks * 100%如果查詢緩存碎片率超過(guò)20%，可以用FLUSH QUERY CACHE整理緩存碎片，或者試試減小query_cache_min_res_unit，如果你的查詢都是小數(shù)據(jù)量的話。使用FLUSH QUERY CACHE命令移除碎片，該命令會(huì)把所有的存儲(chǔ)塊向上移動(dòng)，并把自由塊移到底部。當(dāng)它運(yùn)行的時(shí)候，會(huì)阻止訪問(wèn)查詢緩存，這會(huì)鎖定整個(gè)服務(wù)器，但它通常會(huì)很快，除非緩存特別大。如果緩存沒(méi)有碎片，但是命中率卻不高，那么就應(yīng)該給緩存分配較少的內(nèi)存，如果服務(wù)器找不到足夠大小的塊來(lái)存儲(chǔ)結(jié)果，就應(yīng)該從緩存中清理掉一些查詢，可以使用RESET QUERY CACHE命令從緩存中移除查詢。當(dāng)服務(wù)器清理查詢的時(shí)候，Qcache_lowmen_prunes值會(huì)增加，如果它的值增加得很快，可能有兩個(gè)原因：1）如果有很多自由塊，就可能是有碎片引起的；2）如果自由塊比較少，就可能表示工作負(fù)載使用的內(nèi)存大小超過(guò)了所分配的內(nèi)存，可以檢查Qcache_free_memory知道為使用的內(nèi)存數(shù)量。如果有很多自由塊，碎片很少，由于內(nèi)存不足引起的清理工作也很少，但命中率仍然不高，這說(shuō)明工作負(fù)載也許不能從緩存中受益，一定有什么阻止了查詢使用緩存，很多update語(yǔ)句可能會(huì)是原因，另一個(gè)原因可能是查詢是不可緩存的。查詢緩存分配的最小塊的大小Query_cache_min_res_unit為4MB。當(dāng)查詢進(jìn)行的時(shí)候，MySQL把查詢結(jié)果保存在查詢緩存中，但如果要保存的結(jié)果比較大，超過(guò)query_cache_min_res_unit的值 ，這時(shí)候MySQL會(huì)一邊檢索結(jié)果，一邊保存結(jié)果，所以，有時(shí)候并不是把所有結(jié)果全部得到后再進(jìn)行一次性保存，而是每次分配一塊query_cache_min_res_unit 大小的內(nèi)存空間保存結(jié)果集，使用完后，接著再分配一個(gè)這樣的塊，如果還不夠，接著再分配一個(gè)塊，依此類推，也就是說(shuō)，有可能在一次查詢中，MySQL要進(jìn)行多次內(nèi)存分配的操作。當(dāng)一塊分配的內(nèi)存沒(méi)有完全使用時(shí)，MySQL會(huì)把這塊內(nèi)存截掉，把沒(méi)有使用的那部分歸還以重復(fù)利用，當(dāng)連續(xù)操作后剩下的內(nèi)存大小不足以分配一個(gè)內(nèi)存單元時(shí)，內(nèi)存碎片便產(chǎn)生了。通常無(wú)法避免所有的碎片，但是仔細(xì)選擇Query_cache_min_res_unit可以避免在查詢緩存中造成大量的內(nèi)存浪費(fèi)，關(guān)鍵在于每一個(gè)新塊和服務(wù)器已分配給存儲(chǔ)結(jié)果的塊的數(shù)量之間找到平衡，如果值過(guò)小，服務(wù)器將會(huì)浪費(fèi)較少的內(nèi)存，但會(huì)更頻繁地分配塊，這對(duì)服務(wù)器意味著更多的工作。如果值過(guò)大，碎片將會(huì)很多，合適的折中是在浪費(fèi)內(nèi)存和增加處理時(shí)間上取得平衡。u 空緩存百分比：Qcache_free_blocks / Qcache_total_blocks 16%，且系統(tǒng)Qcache_free_blocks值較高，有可能是出現(xiàn)碎片了，使用flush query cache整理查詢緩存并消除碎片，該命令不會(huì)從緩存中移除任何查詢。同時(shí)定期觀察內(nèi)存碎片情況。Key_buffer_sizeKey_readsKey_reads_requests鍵緩存讀命中率：100-（Key_reads*100）/ Key_reads_requests）= 99.975Key_read_requests和Key_reads是兩個(gè)計(jì)數(shù)器，Key_read_requests是從緩存讀取索引的請(qǐng)求次數(shù)，Key_reads是從磁盤(pán)讀取索引的請(qǐng)求次數(shù)。key_buffer_size指定MyISAM表索引緩沖區(qū)的大小，它決定索引處理的速度，尤其是索引讀的速度。MyISAM鍵緩存默認(rèn)只有一個(gè)緩沖區(qū)，MyISAM自身只緩存了索引，沒(méi)有數(shù)據(jù)，它讓操作系統(tǒng)緩存數(shù)據(jù)，它的值應(yīng)該占到所有保留內(nèi)存的25%到50%，操作系統(tǒng)緩存用來(lái)保存從MYD文件中讀取出來(lái)的數(shù)據(jù)。該變量給鍵緩沖分配指定大小的空間，但是操作系統(tǒng)只有在實(shí)際用到這些空間的時(shí)候才會(huì)進(jìn)行分配，也可以創(chuàng)建多個(gè)鍵緩存，如果對(duì)于一個(gè)非默認(rèn)大小的鍵緩存設(shè)置為0，MySQL就會(huì)把每一個(gè)索引從特定的緩存移到默認(rèn)的緩存中，并且在沒(méi)有對(duì)象使用特定的緩存時(shí)就將其刪掉，給一個(gè)不存在的緩存設(shè)置這個(gè)變量將會(huì)創(chuàng)建緩存，對(duì)一個(gè)已有的緩存設(shè)置非零值將會(huì)沖洗緩存，這是一個(gè)在線操作，它會(huì)阻止所有訪問(wèn)該緩存的動(dòng)作，直到緩存沖洗完成。另一個(gè)參考指標(biāo)是單位時(shí)間內(nèi)Key_reads值的變化情況。u 系統(tǒng)使用MyISAM表查詢頻率較低，鍵緩存讀命中率在99%以上，表明鍵緩存能滿足系統(tǒng)的性能要求。Key_blocks_unusedKey_blocks_used鍵緩存使用率= Key_blocks_used/ (Key_blocks_used+ Key_blocks_unused)=37%u 盡管鍵緩存使用率較低，說(shuō)明key_buffer_size設(shè)置較高，MySQL沒(méi)有將其使用完，基于鍵緩存各方面都能滿足系統(tǒng)要求且內(nèi)存夠用，不必調(diào)整。table_cache_size/table_open_cache (5.1.2之后叫做table_open_cache)Open_tablesOpened_tablesOpen_tables表示當(dāng)前打開(kāi)的表緩存數(shù)，如果執(zhí)行flush tables操作，則此系統(tǒng)會(huì)關(guān)閉一些當(dāng)前沒(méi)有使用的表緩存而使得此狀態(tài)值減?。籵pend_tables表示曾經(jīng)打開(kāi)的表緩存數(shù)，會(huì)一直進(jìn)行累加，如果執(zhí)行flush tables操作，值不會(huì)減小。應(yīng)該將Open_tables的值和table_cache進(jìn)行對(duì)照。如果每秒有太多Opened_tables，那么說(shuō)明table_cache還不夠大，表緩存沒(méi)有被完全利用上時(shí)，顯式的臨時(shí)表也能導(dǎo)致Opened_tables增加。table_cache指定表高速緩存的大小。設(shè)置該變量不會(huì)立即生效，要等到下一個(gè)線程打開(kāi)表的時(shí)候才會(huì)生效，當(dāng)它生效的時(shí)候，MySQL會(huì)檢查變量的值，如果值大于緩存表中的數(shù)量，線程就可以把新打開(kāi)的表插入到緩存中，這樣可以更快地訪問(wèn)表內(nèi)容。如果值小于緩存表中的數(shù)量，MySQL就會(huì)從緩存中刪除掉沒(méi)有使用的表。通過(guò)檢查峰值時(shí)間的狀態(tài)值Open_tables和Opened_tables，可以決定是否需要增加table_cache的值。如果發(fā)現(xiàn)open_tables等于table_cache，并且opened_tables在不斷增長(zhǎng)，那么就需要增加table_cache的值了。u Open_tables值與table_cache相等，且觀察到Opened_tables較大，應(yīng)適當(dāng)增加table_cache，可將其設(shè)置為512。thread_cache_sizethread_cache_size是緩存的同時(shí)操作的線程數(shù)。線程緩存保存了和當(dāng)前連接無(wú)關(guān)的線程，這些線程可以供新連接使用。當(dāng)一個(gè)新連接被創(chuàng)建出來(lái)并且緩存中有一個(gè)線程的時(shí)候，MySQL會(huì)把這個(gè)線程從緩存中刪除，并且把它賦給連接。連接關(guān)閉時(shí)，MySQL會(huì)回收線程，把它放回到緩存中。如果緩存中沒(méi)空間了，MySQL就會(huì)銷毀該線程。只要緩存中有自由的線程，MySQL就能很快地響應(yīng)連接請(qǐng)求，因?yàn)樗恍枰獮槊總€(gè)連接都創(chuàng)建新的線程。設(shè)置該變量不會(huì)立即生效，需要等到下一次線程關(guān)閉的時(shí)候，MySQL會(huì)檢查緩存中是否有空間存儲(chǔ)線程。如果是，他會(huì)把線程緩存起來(lái)，供另外一個(gè)連接使用，如果不是，它會(huì)直接結(jié)束線程，這種情況下，緩存中線程的數(shù)量，以及線程緩存使用的內(nèi)存數(shù)量不會(huì)立即下降。只有當(dāng)新連接為了使用線程而把它從緩存中移走的時(shí)候才會(huì)看到下降。MySQL只有在連接關(guān)閉的時(shí)候才會(huì)把線程加入緩存，也只有在創(chuàng)建新連接的時(shí)候才從緩存中移除線程。Connectionsthread_connectedthreads_createdConnections變量表示連接意圖的數(shù)量，而不是當(dāng)前接連的數(shù)量（threads_connected），如果它的值快速增加，比如每秒幾百，就應(yīng)該檢查連接以及操作系統(tǒng)的網(wǎng)絡(luò)設(shè)置。本系統(tǒng)中該值正常。thread_cache_size定義了MySQL能在緩存中保存的線程數(shù)量，可以通過(guò)觀察threads_created變量的值，以確定線程緩存是否足夠大。如果Threads_created的值較大或正在增加，可以嘗試增加thread_cache_size的值，通過(guò)檢查Threads_created知道有多少緩存已經(jīng)在緩存中了。如果每秒創(chuàng)建的線程數(shù)量少于10個(gè)，緩存的大小就是足夠的。另外，可以觀察thread_connected值的變化來(lái)設(shè)置線程緩存，本系統(tǒng)中它的值保持在100以下。大多數(shù)情況，非常大的線程緩存是沒(méi)有必要的，通常需要把線程緩存保持足夠大以使threads_created不會(huì)經(jīng)常增加，但是如果它的值非常大，本系統(tǒng)已超過(guò)一萬(wàn)就屬于非常大了，那么就應(yīng)該把它設(shè)置得小一點(diǎn)，因?yàn)椴僮飨到y(tǒng)不能很好地處理太多的線程，即使它們處于睡眠狀態(tài)也不行。通常情況，據(jù)物理內(nèi)存設(shè)置規(guī)則如下：1G內(nèi)存設(shè)為8，2G內(nèi)存設(shè)為16，3G內(nèi)存設(shè)為32，4G或4G以上設(shè)為64。u 本系統(tǒng)內(nèi)存為4G，且thread_connected 的增幅并不大，thread_cache_size設(shè)置為64，不需要更改。read_buffer_sizeread_buffer_size是MySQL讀入緩沖區(qū)大小。對(duì)表進(jìn)行順序掃描的請(qǐng)求將分配一個(gè)讀入緩沖區(qū)，MySQL會(huì)為它分配一段內(nèi)存緩沖區(qū)。read_buffer_size變量控制這一緩沖區(qū)的大小。如果對(duì)表的順序掃描請(qǐng)求非常頻繁，并且頻繁掃描進(jìn)行得太慢，可以通過(guò)增加該變量值以及內(nèi)存緩沖區(qū)大小提高其性能。MySQL只有在查詢需要的時(shí)候才會(huì)為該緩存分配內(nèi)存，并且是一次性把指定的大小分配給該緩存。read_rnd_buffer_sizeread_rnd_buffer_size是MySQL的隨機(jī)讀緩沖區(qū)大小。當(dāng)按任意順序讀取行時(shí)(例如，按照排序順序)，將分配一個(gè)隨機(jī)讀緩存區(qū)。進(jìn)行排序查詢時(shí)，MySQL會(huì)首先掃描一遍該緩沖，以避免磁盤(pán)搜索，提高查詢速度，如果需要排序大量數(shù)據(jù)，可適當(dāng)調(diào)高該值。但MySQL會(huì)為每個(gè)客戶連接發(fā)放該緩沖空間，所以應(yīng)盡量適當(dāng)設(shè)置該值，以避免內(nèi)存開(kāi)銷過(guò)大。MySQL只有在查詢需要的時(shí)候才會(huì)為該緩存分配內(nèi)存，并且只會(huì)分配所需的內(nèi)存。sort_buffer_sizesort_buffer_size是MySQL執(zhí)行排序使用的緩沖大小。如果想要增加ORDER BY的速度，首先看是否可以讓MySQL使用索引而不是額外的排序階段。如果不能，可以嘗試增加sort_buffer_size變量的大小。MySQL只有在查詢需要排序的時(shí)候才會(huì)為該緩沖區(qū)分配內(nèi)存，只要發(fā)生了排序，MySQL會(huì)立即分配變量定義的所有內(nèi)存，不管是否需要這么大的空間。如果它的值大于排序需要的空間，那么就意味著浪費(fèi)。sort_buffer_size有可能會(huì)受CPU緩存的影響。Sort_merge_passesSort_merge_passes的值較大說(shuō)明應(yīng)該增加sort_buffer_size，也許僅僅是為某些查詢，最好的辦法就是優(yōu)化排序性能較慢的查詢。u sort_buffer_size為3M，能夠滿足系統(tǒng)的查詢要求。對(duì)于排序沒(méi)有額外要求的情況下不需要調(diào)整。innodb_log_file_sizeInnodb_log_files_in_groupInnoDB日志文件總體大小由innodb_log_file_size和innodb_log_files_in_group控制，并且它們對(duì)寫(xiě)入的性能影響較大。這兩個(gè)文件默認(rèn)大小都較小，對(duì)于高性能的負(fù)載，這個(gè)大小是不夠的，日志文件總大小的上限是4GB，但是即使是寫(xiě)入負(fù)載極高的查詢也只需要幾百兆，比如總共256MB。innodb_log_buffer_sizeInnoDB 在寫(xiě)事務(wù)日志的時(shí)候，為了提高性能，也是先將信息寫(xiě)入 Innodb_log _buffer中，當(dāng)滿足innodb_flush_log_at_trx_commit參數(shù)所設(shè)置的相應(yīng)條件(或者日志緩沖區(qū)寫(xiě)滿)之后，才會(huì)將日志寫(xiě)到文件中?？梢酝ㄟ^(guò) innodb_log_buffer_size 參數(shù)設(shè)置其可以使用的最大內(nèi)存空間?？刂凭彌_大小的變量是innodb_log_buffer_size。不需要把緩沖區(qū)變得很大。推薦值是1MB到8MB。除非要寫(xiě)入大量的巨型BLOB記錄，否則這個(gè)大小就足夠了，日志相對(duì)InnoDB的正常數(shù)據(jù)要緊湊得多。它們不是基于頁(yè)面的，所以它們不會(huì)在存儲(chǔ)數(shù)據(jù)的時(shí)候浪費(fèi)整個(gè)頁(yè)面。innodb_os_log_written可以通過(guò)show innodb status命令的log部分檢測(cè)InnoDB向日志文件寫(xiě)入了多少數(shù)據(jù)，一個(gè)好的辦法就是觀察10秒到100秒時(shí)間間隔內(nèi)的數(shù)據(jù)，并且注意最大值，可以使用這個(gè)值來(lái)判斷日志緩沖大小是否合適。例如，如果最大數(shù)據(jù)是每秒寫(xiě)入100KB，那么1MB的日志緩存可能就足夠了。也可以使用這個(gè)指標(biāo)來(lái)決定日志文件的合適大小。如果最大值是每秒100KB，256MB日志文件就已足夠了。innodb_flush_log_at_trx_commit如果比起持久性而更在意性能，可以通過(guò)設(shè)置innodb_flush_log_at_trx_commit的值來(lái)控制日志緩存被刷寫(xiě)到什么地方及刷寫(xiě)的頻率。該參數(shù)可以設(shè)置為0，1，2，解釋如下：0：log buffer中的數(shù)據(jù)將以每秒一次的頻率寫(xiě)入到log file中，且同時(shí)會(huì)進(jìn)行文件系統(tǒng)到磁盤(pán)的同步操作，但是每個(gè)事務(wù)的提交并不會(huì)觸發(fā)任何log buffer 到log file的刷新或者文件系統(tǒng)到磁盤(pán)的刷新操作；1：在每次事務(wù)提交的時(shí)候?qū)og buffer 中的數(shù)據(jù)都會(huì)寫(xiě)入到log file，同時(shí)也會(huì)觸發(fā)文件系統(tǒng)到磁盤(pán)的同步；2：事務(wù)提交會(huì)觸發(fā)log buffer 到log file的刷新，但并不會(huì)觸發(fā)磁盤(pán)文件系統(tǒng)到磁盤(pán)的同步。此外，每秒會(huì)有一次文件系統(tǒng)到磁盤(pán)同步操作。上午10點(diǎn)抽樣查看半小時(shí)的日志數(shù)據(jù)情況，每分鐘InnoDB向日志文件寫(xiě)入了多少數(shù)據(jù)，抽取其中數(shù)據(jù)較大的10條信息分析查看：u InnoDB平均每分鐘向日志文件寫(xiě)入約9.2MB，而本系統(tǒng)大部分情況下每分鐘寫(xiě)入約5MB6MB，每秒寫(xiě)入約100KB，本系統(tǒng)innodb_log_file_size設(shè)置為64MB，可以將該值設(shè)置為256MB，使其足夠大滿足性能要求，日志文件越大，越節(jié)省IO，但是會(huì)增長(zhǎng)恢復(fù)時(shí)間。該抽樣可能不是系統(tǒng)最高峰值，在系統(tǒng)負(fù)載最大時(shí)分析得出的結(jié)果更加準(zhǔn)確。innodb_max_dirty_pages_pctinnodb_max_dirty_pages_pct不是用來(lái)設(shè)置用于緩存某種數(shù)據(jù)的內(nèi)存大小的一個(gè)參數(shù)，而是用來(lái)控制在 InnoDB緩沖池中可以不用寫(xiě)入數(shù)據(jù)文件中的臟數(shù)據(jù)頁(yè)的比例（本系統(tǒng)為默認(rèn)值：90%），即已經(jīng)被修改但還沒(méi)有從內(nèi)存中寫(xiě)入到數(shù)據(jù)文件的臟數(shù)據(jù)。這個(gè)比例值越大，從內(nèi)存到磁盤(pán)的寫(xiě)入操作就會(huì)相對(duì)減少，所以能夠一定程度下減少寫(xiě)入操作的磁盤(pán)I/O。u 保持默認(rèn)值。innodb_file_per_tableinnodb_file_per_table選項(xiàng)使InnoDB為每一個(gè)表使用一個(gè)文件，它在數(shù)據(jù)庫(kù)目錄中以表名.ibd文件形式保存數(shù)據(jù)，這使得刪除表后回收數(shù)據(jù)變得比較容易，并且它對(duì)于把表分布到多個(gè)磁盤(pán)上也很有用處，但將數(shù)據(jù)放在多個(gè)文件中能導(dǎo)致浪費(fèi)更多的存儲(chǔ)空間，因?yàn)樗褑蝹€(gè)InnoDB表空間的碎片都放在了ibd文件中，這對(duì)于小表尤其會(huì)成為一個(gè)問(wèn)題，因?yàn)镮nnoDB的頁(yè)面大小是16KB，即使表只有1KB數(shù)據(jù)，它也需要至少16KB的磁盤(pán)空間。即使開(kāi)啟了innodb_file_per_table選項(xiàng)，還需要為撤銷日志和其他系統(tǒng)數(shù)據(jù)定義表空間，而且不能簡(jiǎn)單地通過(guò)拷貝文件來(lái)移動(dòng)、備份或恢復(fù)表，且肯定不能在服務(wù)器之間拷貝數(shù)據(jù)。u 本系統(tǒng)數(shù)據(jù)小于1萬(wàn)條表比重超過(guò)80%，不需要為每個(gè)表使用一個(gè)文件，保持默認(rèn)值。concurrent_insert可以使用concurrent_insert變量配置MyISAM表的并發(fā)插入行為，它有下面的值：0，MyISAM不允許并發(fā)插入，每一次插入都會(huì)把表鎖?。?，默認(rèn)值，只要表中沒(méi)有空缺，MyISAM就允許并發(fā)插入；2，它強(qiáng)制并發(fā)插入到表尾，即使表有空缺也不例外，如果沒(méi)有線程從表中讀取數(shù)據(jù)，MySQL就會(huì)把新數(shù)據(jù)插入到空缺中。使用了該值，表的碎片會(huì)增多，也就需要更經(jīng)常地對(duì)表進(jìn)行優(yōu)化。u 保持默認(rèn)值。delay_key_write對(duì)于MyISAM表，可以通過(guò)配置把一些操作延遲，然后合并到一起執(zhí)行，例如可以使用delay_key_write延遲寫(xiě)入索引，但也會(huì)帶來(lái)一些矛盾：立即寫(xiě)入索引，安全但代價(jià)較高，或者等待寫(xiě)入并邪王在寫(xiě)入前不要斷電，這樣更快，但斷電就會(huì)導(dǎo)致大規(guī)模的索引損壞。innodb_thread_concurrencyInnoDB控制并發(fā)最基本的方式是使用innodb_thread_concurrency變量，它限制了一次有多少線程，它限制了一次有多少線程能進(jìn)入內(nèi)核，沒(méi)有辦法為所有的架構(gòu)和負(fù)載確定最佳的并發(fā)數(shù)量，但通常情況下可以這樣計(jì)算：u 并發(fā)=CPU數(shù)量磁盤(pán)數(shù)量2，本系統(tǒng)計(jì)算并發(fā)數(shù)為8。innodb_thread_sleep_delay如果InnoDB內(nèi)核中已經(jīng)有了允許數(shù)量的線程，那么線程就不能再進(jìn)入內(nèi)核了，InnoDB采用了一種兩階段的過(guò)程來(lái)保證線程可以盡可能高效地進(jìn)入內(nèi)核，這種策略減少了操作系統(tǒng)引起的開(kāi)銷。線程首先睡眠innodb_thread_sleep_delay所規(guī)定的微秒數(shù)，然后再進(jìn)行嘗試，如果還是不能進(jìn)入，它就會(huì)進(jìn)入一個(gè)等待線程的隊(duì)列中并且把控制權(quán)交給操作系統(tǒng)。第一階段默認(rèn)的睡眠時(shí)間是10000微秒，當(dāng)有很多線程都處于正在等待進(jìn)入隊(duì)列這一狀態(tài)時(shí)，改變這個(gè)值有助于提高系統(tǒng)并發(fā)，而默認(rèn)值在有大量小查詢的時(shí)候會(huì)太大了，因?yàn)樗o查詢?cè)黾恿?0毫秒延時(shí)。u 保持默認(rèn)值，當(dāng)并發(fā)使用大查詢時(shí)才有必要調(diào)整該值。innodb_commit_concurrencyInnoDB在提交階段還有另外一種形式的并發(fā)瓶頸，就是刷寫(xiě)操作造成的密集I/O操作。innodb_commit_concurrency變量決定了某一時(shí)刻有多少線程能進(jìn)行提交。當(dāng)系統(tǒng)有大量線程狀況不佳時(shí)，可以嘗試將該變量增加。u 保持默認(rèn)值，即不限制并發(fā)提交線程數(shù)。max_length_for_sort_datamax_sort_lengthMySQL有兩種文件排序算法，如果需要進(jìn)行排序的列的總大小超過(guò)了max_length_for_sort_data定義的字節(jié)，MySQL就會(huì)使用雙路排序，反之就會(huì)選擇單路排序，雙路排序需要兩次訪問(wèn)數(shù)據(jù)，尤其是第二次讀取操作會(huì)導(dǎo)致大量的隨機(jī)I/O操作。如果將并不需要的Columns也取出來(lái)，就會(huì)極大地浪費(fèi)排序過(guò)程所需要的內(nèi)存，為了盡可能地提高排序性能，盡量使用第二種排序算法，所以在查詢中僅取出需要的列是非常有必要的。u 對(duì)于本系統(tǒng)，默認(rèn)值足夠大，能滿足性能要求。Aborted_clients如果Aborted_clients變量隨時(shí)間增加，那么就要確定是否正常地關(guān)閉了連接。如果不是，就要檢查網(wǎng)絡(luò)性能，并且檢查max_allowed_packet變量，超多了max_allowed_packet的查詢會(huì)被強(qiáng)制地中斷。Aborted_connectsAborted_connects變量的值應(yīng)接近于0，否則就可能有網(wǎng)絡(luò)問(wèn)題，有幾個(gè)被中斷的連接是正常的。例如，試著從錯(cuò)誤的主機(jī)連接、使用了錯(cuò)誤的用戶名和密碼，或者定義了無(wú)效的數(shù)據(jù)庫(kù)，都會(huì)發(fā)生這樣的情況。u 觀察本系統(tǒng)10分鐘內(nèi)的Aborted_clients變化，一直保持為0，說(shuō)明沒(méi)有連接方面的異常情況，可以定期觀察該變量分析連接問(wèn)題。binlog_cache_sizeBinlog_cache_disk_useBinlog_cache_use當(dāng)使用事務(wù)的表存儲(chǔ)引擎InnoDB時(shí)，所有未提交的二進(jìn)制日志會(huì)被記錄到一個(gè)緩存中，等該事務(wù)提交時(shí)直接將緩沖中的二進(jìn)制日志寫(xiě)入二進(jìn)制日志文件，而該緩沖的大小由binlog_cache_size決定，默認(rèn)大小為32KB。此外，binlog_cache_size是基于會(huì)話的，當(dāng)一個(gè)線程開(kāi)始一個(gè)事務(wù)時(shí)，MySQL會(huì)自動(dòng)分配一個(gè)大小為binlog_cache_size的緩存，因此該值不能設(shè)置過(guò)大。當(dāng)一個(gè)事務(wù)的記錄大于設(shè)定的binlog_cache_size時(shí)，MySQL會(huì)把緩沖中的日志寫(xiě)入一個(gè)臨時(shí)文件中，因此該值又不能設(shè)得太小。通過(guò)查看binlog_cache_use、binlog_cache_disk_use的狀態(tài),可以判斷當(dāng)前binlog_cache_size的設(shè)置是否合適。Binlog_cache_use記錄了使用緩沖寫(xiě)二進(jìn)制日志的次數(shù)，binlog_cache_disk_use記錄了使用臨時(shí)文件寫(xiě)二進(jìn)制日志的次數(shù)。如果binlog_cache_disk_use與Binlog_cache_use之間的比值很大，就應(yīng)該增加binlog_cache_size的值，只要保證大部分的事務(wù)都在二進(jìn)制日志緩存里就可以了。u binlog_cache_disk_use/Binlog_cache_use比值非常小，說(shuō)明本系統(tǒng)絕大部份事務(wù)都能下入在二進(jìn)制日志緩存。Created_tmp_disk_tablesCreated_tmp_tables每次創(chuàng)建臨時(shí)表時(shí)，Created_tmp_tables增加，如果是在磁盤(pán)上創(chuàng)建臨時(shí)表，則Created_tmp_disk_tables也會(huì)增加，通?？梢酝ㄟ^(guò)Created_tmp_tables/(Created_tmp_disk_tables + Created_tmp_tables)來(lái)判斷基于內(nèi)存的臨時(shí)表利用率。如果Created_tmp_disk_tables太大，則需要檢查并優(yōu)化查詢語(yǔ)句，或有可能是tmp_table_size和max_heap_table_size不夠大。Created_tmp_disk_tables / Created_tmp_tables 100% （理想值 85%）。MySQL服務(wù)器實(shí)際上允許max_connections+1個(gè)客戶端進(jìn)行連接。額外的連接保留給具有SUPER權(quán)限的賬戶。通過(guò)為系統(tǒng)管理員而不是普通用戶授予SUPER權(quán)限（普通用戶不應(yīng)具有該權(quán)限），系統(tǒng)管理員能夠連接到服務(wù)器來(lái)診斷問(wèn)題，即使已連接的無(wú)特權(quán)客戶端數(shù)已達(dá)到最大值也同樣。u 本系統(tǒng)中設(shè)置的最大連接數(shù)是600，而響應(yīng)的連接數(shù)是601，應(yīng)適當(dāng)增加Max_connections變量的值。Open_files和Open_files_limit如果Open_files的值與Open_files_limit的值較為接近，那就應(yīng)該增加Open_files_limit。max_connections 和 table_open_cache 與 open_files_limit 的關(guān)系：max_1 = 10 + max_connections + table_cache * 2，該值為1122；max_2 = max_connections * 5，該值為3000；max_3 = max_os_open_files，該值為1024，表示操作系統(tǒng)單個(gè)進(jìn)程最大允許打開(kāi)文件句柄（文件描述符）。u open_files_limit 取三個(gè)值中的最大值 ，設(shè)置3000較合理，不需要調(diào)整。Select_full_join全聯(lián)接是無(wú)索引聯(lián)接，它真正影響性能，最好能避免全聯(lián)接，即使是每分鐘一次也較多，如果聯(lián)接沒(méi)有索引，則最好能優(yōu)化查詢和索引。select_full_range_join如果select_full_range_join的值過(guò)高，就說(shuō)明運(yùn)行了許多使用了范圍查詢聯(lián)接表，有時(shí)大的范圍查詢也會(huì)比較慢，可以從中進(jìn)行優(yōu)化。Select_range_checkSelect_range_check變量記錄了在聯(lián)接時(shí)，對(duì)每一行數(shù)據(jù)重新檢查索引的查詢計(jì)劃的數(shù)量，它的性能開(kāi)銷很大，如果該值較高或正在增加，則說(shuō)明一些查詢沒(méi)有找到好索引。u 上述變量目前正常，如果發(fā)生明顯變化，則結(jié)合慢查詢?nèi)罩靖櫲?lián)接性能較差的查詢。Slow_launch_threads該變量如果較大則說(shuō)明某些因素正在延遲聯(lián)接的新線程，服務(wù)器存在一些問(wèn)題。它通常表示系統(tǒng)過(guò)載，導(dǎo)致操作系統(tǒng)不能給新創(chuàng)建的線程分配時(shí)間片。Table_locks_waitedTable_locks_waited變量顯示了有多少表被鎖住了并且導(dǎo)致服務(wù)器級(jí)的鎖等待，InnoDB的行級(jí)鎖不會(huì)使該變量增加。如果該值較高并且正在增加，則說(shuō)明存在嚴(yán)重的并發(fā)瓶頸，這時(shí)應(yīng)該考慮使用InnoDB或另外使用行級(jí)鎖的存儲(chǔ)引擎，或者手動(dòng)對(duì)大表進(jìn)行分區(qū)，并優(yōu)化查詢，啟用并發(fā)插入或?qū)︽i設(shè)置進(jìn)行優(yōu)化。u 本系統(tǒng)該變量在半小時(shí)內(nèi)變化幅度不超過(guò)3，不必調(diào)整。2. MySQL優(yōu)化策略2.1. 索引策略索引是幫助MySQL高效獲取數(shù)據(jù)的數(shù)據(jù)結(jié)構(gòu)，它對(duì)于高性能非常關(guān)鍵，因此建立索引是現(xiàn)實(shí)中性能問(wèn)題的首要原因。索引在數(shù)據(jù)越大的時(shí)候越重要。規(guī)模小，負(fù)載輕的數(shù)據(jù)庫(kù)即使沒(méi)有索引，也能有好的性能，但是當(dāng)數(shù)據(jù)增加的時(shí)候，性能就會(huì)下降。MySQL有多種類型類型的索引，它們各有自己的性能特點(diǎn)。索引是在存儲(chǔ)引擎層實(shí)現(xiàn)的，而不是在服務(wù)器層，因此它們并不是標(biāo)準(zhǔn)化的，每個(gè)引擎的索引工作方式略有不同，并不是所有的引擎都支持所有類型的索引。即使多個(gè)引擎支持同樣的索引，他們的實(shí)現(xiàn)方式也可能有所不同。MySQL索引類型的各自特點(diǎn)可以查閱相關(guān)資料去進(jìn)一步了解。即使已經(jīng)了解了關(guān)于索引的知識(shí)，但也許還不知道如何從實(shí)際的表開(kāi)始。雖然通常情況下是檢查系統(tǒng)中最常運(yùn)行的查詢，但往往性能瓶頸可能就出現(xiàn)在不那么經(jīng)常進(jìn)行的插入或更新操作，要避免在不知道什么查詢會(huì)使用索引之前就創(chuàng)建它這種常見(jiàn)錯(cuò)誤，并且要考慮是否所有的索引能形成一個(gè)優(yōu)化的配置。有時(shí)只從查詢就可以知道需要什么索引，只要把它們加上就可以了。但是有時(shí)各種類型的查詢，卻不能找