Linux上MySQL優(yōu)化提升性能，哪些可以?xún)?yōu)化關(guān)閉NUMA特性？

Linux上MySQL優(yōu)化提升性能，可以?xún)?yōu)化關(guān)閉NUMA特性如下：

創(chuàng)新互聯(lián)是一家集網(wǎng)站建設(shè),克山企業(yè)網(wǎng)站建設(shè),克山品牌網(wǎng)站建設(shè),網(wǎng)站定制,克山網(wǎng)站建設(shè)報(bào)價(jià),網(wǎng)絡(luò)營(yíng)銷(xiāo),網(wǎng)絡(luò)優(yōu)化,克山網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競(jìng)爭(zhēng)力。可充分滿(mǎn)足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時(shí)我們時(shí)刻保持專(zhuān)業(yè)、時(shí)尚、前沿，時(shí)刻以成就客戶(hù)成長(zhǎng)自我，堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。

這些其實(shí)都源于CPU最新的技術(shù)：節(jié)能模式。操作系統(tǒng)和CPU硬件配合，系統(tǒng)不繁忙的時(shí)候，為了節(jié)約電能和降低溫度，它會(huì)將CPU降頻。

為了保證MySQL能夠充分利用CPU的資源，建議設(shè)置CPU為最大性能模式。這個(gè)設(shè)置可以在BIOS和操作系統(tǒng)中設(shè)置，當(dāng)然，在BIOS中設(shè)置該選項(xiàng)更好，更徹底。

然后我們看看內(nèi)存方面，我們有哪些可以?xún)?yōu)化的。

i)我們先看看numa

非一致存儲(chǔ)訪(fǎng)問(wèn)結(jié)構(gòu)(NUMA：Non-UniformMemoryAccess)也是最新的內(nèi)存管理技術(shù)。它和對(duì)稱(chēng)多處理器結(jié)構(gòu)(SMP：SymmetricMulti-Processor)是對(duì)應(yīng)的。

我們可以直觀的看到：SMP訪(fǎng)問(wèn)內(nèi)存的都是代價(jià)都是一樣的;但是在NUMA架構(gòu)下，本地內(nèi)存的訪(fǎng)問(wèn)和非本地內(nèi)存的訪(fǎng)問(wèn)代價(jià)是不一樣的。對(duì)應(yīng)的根據(jù)這個(gè)特性，操作系統(tǒng)上，我們可以設(shè)置進(jìn)程的內(nèi)存分配方式。目前支持的方式包括：

--interleave=nodes

--membind=nodes

--cpunodebind=nodes

--physcpubind=cpus

--localalloc

--preferred=node

簡(jiǎn)而言之，就是說(shuō)，你可以指定內(nèi)存在本地分配，在某幾個(gè)CPU節(jié)點(diǎn)分配或者輪詢(xún)分配。除非是設(shè)置為--interleave=nodes輪詢(xún)分配方式，即內(nèi)存可以在任意NUMA節(jié)點(diǎn)上分配這種方式以外。其他的方式就算其他NUMA節(jié)點(diǎn)上還有內(nèi)存剩余，Linux也不會(huì)把剩余的內(nèi)存分配給這個(gè)進(jìn)程，而是采用SWAP的方式來(lái)獲得內(nèi)存。

所以最簡(jiǎn)單的方法，還是關(guān)閉掉這個(gè)特性。

關(guān)閉特性的方法，分別有：可以從BIOS，操作系統(tǒng)，啟動(dòng)進(jìn)程時(shí)臨時(shí)關(guān)閉這個(gè)特性。

a)由于各種BIOS類(lèi)型的區(qū)別，如何關(guān)閉NUMA千差萬(wàn)別，我們這里就不具體展示怎么設(shè)置了。

b)在操作系統(tǒng)中關(guān)閉，可以直接在/etc/grub.conf的kernel行最后添加numa=off，如下所示：

kernel/vmlinuz-2.6.32-220.el6.x86_64roroot=/dev/mapper/VolGroup-rootrd_NO_LUKS.UTF-8rd_LVM_LV=VolGroup/rootrd_NO_MDquietSYSFONT=latarcyrheb-sun16rhgbcrashkernel=autord_LVM_LV=VolGroup/swaprhgbcrashkernel=autoquietKEYBOARDTYPE=pcKEYTABLE=usrd_NO_DMnuma=off

另外可以設(shè)置vm.zone_reclaim_mode=0盡量回收內(nèi)存。

c)啟動(dòng)MySQL的時(shí)候，關(guān)閉NUMA特性：

numactl--interleave=allmysqld

當(dāng)然，最好的方式是在BIOS中關(guān)閉。

ii)我們?cè)倏纯磛m.swappiness。

vm.swappiness是操作系統(tǒng)控制物理內(nèi)存交換出去的策略。它允許的值是一個(gè)百分比的值，最小為0，最大運(yùn)行100，該值默認(rèn)為60。vm.swappiness設(shè)置為0表示盡量少swap，100表示盡量將inactive的內(nèi)存頁(yè)交換出去。

具體的說(shuō)：當(dāng)內(nèi)存基本用滿(mǎn)的時(shí)候，系統(tǒng)會(huì)根據(jù)這個(gè)參數(shù)來(lái)判斷是把內(nèi)存中很少用到的inactive內(nèi)存交換出去，還是釋放數(shù)據(jù)的cache。

MySQL性能調(diào)優(yōu) – 你必須了解的15個(gè)重要變量

前言:

MYSQL 應(yīng)該是最流行了 WEB 后端數(shù)據(jù)庫(kù)。雖然 NOSQL 最近越來(lái)越多的被提到，但是相信大部分架構(gòu)師還是會(huì)選擇 MYSQL 來(lái)做數(shù)據(jù)存儲(chǔ)。本文作者總結(jié)梳理MySQL性能調(diào)優(yōu)的15個(gè)重要變量，又不足需要補(bǔ)充的還望大佬指出。

1.DEFAULT_STORAGE_ENGINE

如果你已經(jīng)在用MySQL 5.6或者5.7，并且你的數(shù)據(jù)表都是InnoDB，那么表示你已經(jīng)設(shè)置好了。如果沒(méi)有，確保把你的表轉(zhuǎn)換為InnoDB并且設(shè)置default_storage_engine為InnoDB。

為什么？簡(jiǎn)而言之，因?yàn)镮nnoDB是MySQL(包括Percona Server和MariaDB)最好的存儲(chǔ)引擎 – 它支持事務(wù)，高并發(fā)，有著非常好的性能表現(xiàn)(當(dāng)配置正確時(shí))。這里有詳細(xì)的版本介紹為什么

2.INNODB_BUFFER_POOL_SIZE

這個(gè)是InnoDB最重要變量。實(shí)際上，如果你的主要存儲(chǔ)引擎是InnoDB，那么對(duì)于你，這個(gè)變量對(duì)于MySQL是最重要的。

基本上，innodb_buffer_pool_size指定了MySQL應(yīng)該分配給InnoDB緩沖池多少內(nèi)存，InnoDB緩沖池用來(lái)存儲(chǔ)緩存的數(shù)據(jù)，二級(jí)索引，臟數(shù)據(jù)(已經(jīng)被更改但沒(méi)有刷新到硬盤(pán)的數(shù)據(jù))以及各種內(nèi)部結(jié)構(gòu)如自適應(yīng)哈希索引。

根據(jù)經(jīng)驗(yàn)，在一個(gè)獨(dú)立的MySQL服務(wù)器應(yīng)該分配給MySQL整個(gè)機(jī)器總內(nèi)存的80%。如果你的MySQL運(yùn)行在一個(gè)共享服務(wù)器，或者你想知道InnoDB緩沖池大小是否正確設(shè)置，詳細(xì)請(qǐng)看這里。

3.INNODB_LOG_FILE_SIZE

InnoDB重做日志文件的設(shè)置在MySQL社區(qū)也叫做事務(wù)日志。直到MySQL 5.6.8事務(wù)日志默認(rèn)值innodb_log_file_size=5M是唯一最大的InnoDB性能殺手。從MySQL 5.6.8開(kāi)始，默認(rèn)值提升到48M,但對(duì)于許多稍繁忙的系統(tǒng)，還遠(yuǎn)遠(yuǎn)要低。

根據(jù)經(jīng)驗(yàn)，你應(yīng)該設(shè)置的日志大小能在你服務(wù)器繁忙時(shí)能存儲(chǔ)1-2小時(shí)的寫(xiě)入量。如果不想這么麻煩，那么設(shè)置1-2G的大小會(huì)讓你的性能有一個(gè)不錯(cuò)的表現(xiàn)。這個(gè)變量也相當(dāng)重要，更詳細(xì)的介紹請(qǐng)看這里。

當(dāng)然，如果你有大量的大事務(wù)更改，那么，更改比默認(rèn)innodb日志緩沖大小更大的值會(huì)對(duì)你的性能有一定的提高，但是你使用的是autocommit，或者你的事務(wù)更改小于幾k，那還是保持默認(rèn)的值吧。

4.INNODB_FLUSH_LOG_AT_TRX_COMMIT

默認(rèn)下，innodb_flush_log_at_trx_commit設(shè)置為1表示InnoDB在每次事務(wù)提交后立即刷新同步數(shù)據(jù)到硬盤(pán)。如果你使用autocommit，那么你的每一個(gè)INSERT, UPDATE或DELETE語(yǔ)句都是一個(gè)事務(wù)提交。

同步是一個(gè)昂貴的操作(特別是當(dāng)你沒(méi)有寫(xiě)回緩存時(shí))，因?yàn)樗婕皩?duì)硬盤(pán)的實(shí)際同步物理寫(xiě)入。所以如果可能，并不建議使用默認(rèn)值。

兩個(gè)可選的值是0和2:

* 0表示刷新到硬盤(pán)，但不同步(提交事務(wù)時(shí)沒(méi)有實(shí)際的IO操作)

* 2表示不刷新和不同步(也沒(méi)有實(shí)際的IO操作)

所以你如果設(shè)置它為0或2，則同步操作每秒執(zhí)行一次。所以明顯的缺點(diǎn)是你可能會(huì)丟失上一秒的提交數(shù)據(jù)。具體來(lái)說(shuō)，你的事務(wù)已經(jīng)提交了，但服務(wù)器馬上斷電了，那么你的提交相當(dāng)于沒(méi)有發(fā)生過(guò)。

顯示的，對(duì)于金融機(jī)構(gòu)，如銀行，這是無(wú)法忍受的。不過(guò)對(duì)于大多數(shù)網(wǎng)站，可以設(shè)置為innodb_flush_log_at_trx_commit=0|2，即使服務(wù)器最終崩潰也沒(méi)有什么大問(wèn)題。畢竟，僅僅在幾年前有許多網(wǎng)站還是用MyISAM，當(dāng)崩潰時(shí)會(huì)丟失30s的數(shù)據(jù)(更不要提那令人抓狂的慢修復(fù)進(jìn)程)。

那么，0和2之間的實(shí)際區(qū)別是什么？性能明顯的差異是可以忽略不計(jì)，因?yàn)樗⑿碌讲僮飨到y(tǒng)緩存的操作是非常快的。所以很明顯應(yīng)該設(shè)置為0，萬(wàn)一MySQL崩潰(不是整個(gè)機(jī)器)，你不會(huì)丟失任何數(shù)據(jù)，因?yàn)閿?shù)據(jù)已經(jīng)在OS緩存，最終還是會(huì)同步到硬盤(pán)的。

5.SYNC_BINLOG

已經(jīng)有大量的文檔寫(xiě)到sync_binlog，以及它和innodb_flush_log_at_trx_commit的關(guān)系，下面我們來(lái)簡(jiǎn)單的介紹下：

a) 如果你的服務(wù)器沒(méi)有設(shè)置從服務(wù)器，而且你不做備份，那么設(shè)置sync_binlog=0將對(duì)性能有好處。

b) 如果你有從服務(wù)器并且做備份，但你不介意當(dāng)主服務(wù)器崩潰時(shí)在二進(jìn)制日志丟失一些事件，那么為了更好的性能還是設(shè)置為sync_binlog=0.

c) 如果你有從服務(wù)器并且備份，你非常在意從服務(wù)器的一致性，以及能及時(shí)恢復(fù)到一個(gè)時(shí)間點(diǎn)(通過(guò)使用最新的一致性備份和二進(jìn)制日志將數(shù)據(jù)庫(kù)恢復(fù)到特定時(shí)間點(diǎn)的能力)，那么你應(yīng)該設(shè)置innodb_flush_log_at_trx_commit=1，并且需要認(rèn)真考慮使用sync_binlog=1。

問(wèn)題是sync_binlog=1代價(jià)比較高 – 現(xiàn)在每個(gè)事務(wù)也要同步一次到硬盤(pán)。你可能會(huì)想為什么不把兩次同步合并成一次，想法正確 – 新版本的MySQL(5.6和5.7，MariaDB和Percona Server)已經(jīng)能合并提交，那么在這種情況下sync_binlog=1的操作也不是這么昂貴了，但在舊的mysql版本中仍然會(huì)對(duì)性能有很大影響。

6.INNODB_FLUSH_METHOD

將innodb_flush_method設(shè)置為O_DIRECT以避免雙重緩沖.唯一一種情況你不應(yīng)該使用O_DIRECT是當(dāng)你操作系統(tǒng)不支持時(shí)。但如果你運(yùn)行的是Linux，使用O_DIRECT來(lái)激活直接IO。

不用直接IO，雙重緩沖將會(huì)發(fā)生，因?yàn)樗械臄?shù)據(jù)庫(kù)更改首先會(huì)寫(xiě)入到OS緩存然后才同步到硬盤(pán) – 所以InnoDB緩沖池和OS緩存會(huì)同時(shí)持有一份相同的數(shù)據(jù)。特別是如果你的緩沖池限制為總內(nèi)存的50%，那意味著在寫(xiě)密集的環(huán)境中你可能會(huì)浪費(fèi)高達(dá)50%的內(nèi)存。如果沒(méi)有限制為50%，服務(wù)器可能由于OS緩存的高壓力會(huì)使用到swap。

簡(jiǎn)單地說(shuō)，設(shè)置為innodb_flush_method=O_DIRECT。

7.INNODB_BUFFER_POOL_INSTANCES

MySQL 5.5引入了緩沖實(shí)例作為減小內(nèi)部鎖爭(zhēng)用來(lái)提高M(jìn)ySQL吞吐量的手段。

在5.5版本這個(gè)對(duì)提升吞吐量幫助很小，然后在MySQL 5.6版本這個(gè)提升就非常大了，所以在MySQL5.5中你可能會(huì)保守地設(shè)置innodb_buffer_pool_instances=4，在MySQL 5.6和5.7中你可以設(shè)置為8-16個(gè)緩沖池實(shí)例。

你設(shè)置后觀察會(huì)覺(jué)得性能提高不大，但在大多數(shù)高負(fù)載情況下，它應(yīng)該會(huì)有不錯(cuò)的表現(xiàn)。

對(duì)了，不要指望這個(gè)設(shè)置能減少你單個(gè)查詢(xún)的響應(yīng)時(shí)間。這個(gè)是在高并發(fā)負(fù)載的服務(wù)器上才看得出區(qū)別。比如多個(gè)線(xiàn)程同時(shí)做許多事情。

8.INNODB_THREAD_CONCURRENCY

InnoDB有一種方法來(lái)控制并行執(zhí)行的線(xiàn)程數(shù) – 我們稱(chēng)為并發(fā)控制機(jī)制。大部分是由innodb_thread_concurrency值來(lái)控制的。如果設(shè)置為0，并發(fā)控制就關(guān)閉了，因此InnoDB會(huì)立即處理所有進(jìn)來(lái)的請(qǐng)求(盡可能多的)。

在你有32CPU核心且只有4個(gè)請(qǐng)求時(shí)會(huì)沒(méi)什么問(wèn)題。不過(guò)想像下你只有4CPU核心和32個(gè)請(qǐng)求時(shí) – 如果你讓32個(gè)請(qǐng)求同時(shí)處理，你這個(gè)自找麻煩。因?yàn)檫@些32個(gè)請(qǐng)求只有4 CPU核心，顯然地會(huì)比平常慢至少8倍(實(shí)際上是大于8倍)，而然這些請(qǐng)求每個(gè)都有自己的外部和內(nèi)部鎖，這有很大可能堆積請(qǐng)求。

下面介紹如何更改這個(gè)變量，在mysql命令行提示符執(zhí)行：

對(duì)于大多數(shù)工作負(fù)載和服務(wù)器，設(shè)置為8是一個(gè)好開(kāi)端，然后你可以根據(jù)服務(wù)器達(dá)到了這個(gè)限制而資源使用率利用不足時(shí)逐漸增加。可以通過(guò)show engine innodb status\G來(lái)查看目前查詢(xún)處理情況，查找類(lèi)似如下行：

9.SKIP_NAME_RESOLVE

這一項(xiàng)不得不提及，因?yàn)槿匀挥泻芏嗳藳](méi)有添加這一項(xiàng)。你應(yīng)該添加skip_name_resolve來(lái)避免連接時(shí)DNS解析。

大多數(shù)情況下你更改這個(gè)會(huì)沒(méi)有什么感覺(jué)，因?yàn)榇蠖鄶?shù)情況下DNS服務(wù)器解析會(huì)非常快。不過(guò)當(dāng)DNS服務(wù)器失敗時(shí)，它會(huì)出現(xiàn)在你服務(wù)器上出現(xiàn)“unauthenticated connections” ，而就是為什么所有的請(qǐng)求都突然開(kāi)始慢下來(lái)了。

所以不要等到這種事情發(fā)生才更改。現(xiàn)在添加這個(gè)變量并且避免基于主機(jī)名的授權(quán)。

10.INNODB_IO_CAPACITY, INNODB_IO_CAPACITY_MAX

* innodb_io_capacity：用來(lái)當(dāng)刷新臟數(shù)據(jù)時(shí)，控制MySQL每秒執(zhí)行的寫(xiě)IO量。

* innodb_io_capacity_max: 在壓力下，控制當(dāng)刷新臟數(shù)據(jù)時(shí)MySQL每秒執(zhí)行的寫(xiě)IO量

首先，這與讀取無(wú)關(guān) – SELECT查詢(xún)執(zhí)行的操作。對(duì)于讀操作，MySQL會(huì)盡最大可能處理并返回結(jié)果。至于寫(xiě)操作，MySQL在后臺(tái)會(huì)循環(huán)刷新，在每一個(gè)循環(huán)會(huì)檢查有多少數(shù)據(jù)需要刷新，并且不會(huì)用超過(guò)innodb_io_capacity指定的數(shù)來(lái)做刷新操作。這也包括更改緩沖區(qū)合并（在它們刷新到磁盤(pán)之前，更改緩沖區(qū)是輔助臟頁(yè)存儲(chǔ)的關(guān)鍵）。

第二，我需要解釋一下什么叫“在壓力下”，MySQL中稱(chēng)為”緊急情況”，是當(dāng)MySQL在后臺(tái)刷新時(shí)，它需要刷新一些數(shù)據(jù)為了讓新的寫(xiě)操作進(jìn)來(lái)。然后，MySQL會(huì)用到innodb_io_capacity_max。

那么，應(yīng)該設(shè)置innodb_io_capacity和innodb_io_capacity_max為什么呢？

最好的方法是測(cè)量你的存儲(chǔ)設(shè)置的隨機(jī)寫(xiě)吞吐量，然后給innodb_io_capacity_max設(shè)置為你的設(shè)備能達(dá)到的最大IOPS。innodb_io_capacity就設(shè)置為它的50-75%，特別是你的系統(tǒng)主要是寫(xiě)操作時(shí)。

通常你可以預(yù)測(cè)你的系統(tǒng)的IOPS是多少。例如由8 15k硬盤(pán)組成的RAID10能做大約每秒1000隨機(jī)寫(xiě)操作，所以你可以設(shè)置innodb_io_capacity=600和innodb_io_capacity_max=1000。許多廉價(jià)企業(yè)SSD可以做4,000-10,000 IOPS等。

這個(gè)值設(shè)置得不完美問(wèn)題不大。但是，要注意默認(rèn)的200和400會(huì)限制你的寫(xiě)吞吐量，因此你可能偶爾會(huì)捕捉到刷新進(jìn)程。如果出現(xiàn)這種情況，可能是已經(jīng)達(dá)到你硬盤(pán)的寫(xiě)IO吞吐量，或者這個(gè)值設(shè)置得太小限制了吞吐量。

11.INNODB_STATS_ON_METADATA

如果你跑的是MySQL 5.6或5.7，你不需要更改innodb_stats_on_metadata的默認(rèn)值，因?yàn)樗呀?jīng)設(shè)置正確了。

不過(guò)在MySQL 5.5或5.1，強(qiáng)烈建議關(guān)閉這個(gè)變量 – 如果是開(kāi)啟，像命令show table status會(huì)立即查詢(xún)INFORMATION_SCHEMA而不是等幾秒再執(zhí)行，這會(huì)使用到額外的IO操作。

從5.1.32版本開(kāi)始，這個(gè)是動(dòng)態(tài)變量，意味著你不需要重啟MySQL服務(wù)器來(lái)關(guān)閉它。

12.INNODB_BUFFER_POOL_DUMP_AT_SHUTDOWN INNODB_BUFFER_POOL_LOAD_AT_STARTUP

innodb_buffer_pool_dump_at_shutdown和innodb_buffer_pool_load_at_startup這兩個(gè)變量與性能無(wú)關(guān)，不過(guò)如果你偶爾重啟mysql服務(wù)器(如生效配置)，那么就有關(guān)。當(dāng)兩個(gè)都激活時(shí)，MySQL緩沖池的內(nèi)容(更具體地說(shuō)，是緩存頁(yè))在停止MySQL時(shí)存儲(chǔ)到一個(gè)文件。當(dāng)你下次啟動(dòng)MySQL時(shí)，它會(huì)在后臺(tái)啟動(dòng)一個(gè)線(xiàn)程來(lái)加載緩沖池的內(nèi)容以提高預(yù)熱速度到3-5倍。

兩件事：

第一，它實(shí)際上沒(méi)有在關(guān)閉時(shí)復(fù)制緩沖池內(nèi)容到文件，僅僅是復(fù)制表空間ID和頁(yè)面ID – 足夠的信息來(lái)定位硬盤(pán)上的頁(yè)面了。然后它就能以大量的順序讀非常快速的加載那些頁(yè)面，而不是需要成千上萬(wàn)的小隨機(jī)讀。

第二，啟動(dòng)時(shí)是在后臺(tái)加載內(nèi)容，因?yàn)镸ySQL不需要等到緩沖池內(nèi)容加載完成再開(kāi)始接受請(qǐng)求(所以看起來(lái)不會(huì)有什么影響)。

從MySQL 5.7.7開(kāi)始，默認(rèn)只有25%的緩沖池頁(yè)面在mysql關(guān)閉時(shí)存儲(chǔ)到文件，但是你可以控制這個(gè)值 – 使用innodb_buffer_pool_dump_pct，建議75-100。

這個(gè)特性從MySQL 5.6才開(kāi)始支持。

13.INNODB_ADAPTIVE_HASH_INDEX_PARTS

如果你運(yùn)行著一個(gè)大量SELECT查詢(xún)的MySQL服務(wù)器(并且已經(jīng)盡可能優(yōu)化)，那么自適應(yīng)哈希索引將下你的下一個(gè)瓶頸。自適應(yīng)哈希索引是InnoDB內(nèi)部維護(hù)的動(dòng)態(tài)索引，可以提高最常用的查詢(xún)模式的性能。這個(gè)特性可以重啟服務(wù)器關(guān)閉，不過(guò)默認(rèn)下在mysql的所有版本開(kāi)啟。

這個(gè)技術(shù)非常復(fù)雜，在大多數(shù)情況下它會(huì)對(duì)大多數(shù)類(lèi)型的查詢(xún)直到加速的作用。不過(guò)，當(dāng)你有太多的查詢(xún)往數(shù)據(jù)庫(kù)，在某一個(gè)點(diǎn)上它會(huì)花過(guò)多的時(shí)間等待AHI鎖和閂鎖。

如果你的是MySQL 5.7，沒(méi)有這個(gè)問(wèn)題 – innodb_adaptive_hash_index_parts默認(rèn)設(shè)置為8，所以自適應(yīng)哈希索引被切割為8個(gè)分區(qū)，因?yàn)椴淮嬖谌只コ狻?/p>

不過(guò)在mysql 5.7前的版本，沒(méi)有AHI分區(qū)數(shù)量的控制。換句話(huà)說(shuō)，有一個(gè)全局互斥鎖來(lái)保護(hù)AHI，可能導(dǎo)致你的select查詢(xún)經(jīng)常撞墻。

所以如果你運(yùn)行的是5.1或5.6，并且有大量的select查詢(xún)，最簡(jiǎn)單的方案就是切換成同一版本的Percona Server來(lái)激活A(yù)HI分區(qū)。

14.QUERY_CACHE_TYPE

如果人認(rèn)為查詢(xún)緩存效果很好，肯定應(yīng)該使用它。好吧，有時(shí)候是有用的。不過(guò)這個(gè)只在你在低負(fù)載時(shí)有用，特別是在低負(fù)載下大多數(shù)是讀取，小量寫(xiě)或者沒(méi)有。

如果是那樣的情況，設(shè)置query_cache_type=ON和query_cache_size=256M就好了。不過(guò)記住不能把256M設(shè)置更高的值了，否則會(huì)由于查詢(xún)緩存失效時(shí)，導(dǎo)致引起嚴(yán)重的服務(wù)器停頓。

如果你的MySQL服務(wù)器高負(fù)載動(dòng)作，建議設(shè)置query_cache_size=0和query_cache_type=OFF，并重啟服務(wù)器生效。那樣Mysql就會(huì)停止在所有的查詢(xún)使用查詢(xún)緩存互斥鎖。

15.TABLE_OPEN_CACHE_INSTANCES

從MySQL 5.6.6開(kāi)始，表緩存能分割到多個(gè)分區(qū)。

表緩存用來(lái)存放目前已打開(kāi)表的列表，當(dāng)每一個(gè)表打開(kāi)或關(guān)閉互斥體就被鎖定 – 即使這是一個(gè)隱式臨時(shí)表。使用多個(gè)分區(qū)絕對(duì)減少了潛在的爭(zhēng)用。

從MySQL 5.7.8開(kāi)始，table_open_cache_instances=16是默認(rèn)的配置。

歡迎做Java的工程師朋友們私信我資料免費(fèi)獲取免費(fèi)的Java架構(gòu)學(xué)習(xí)資料（里面有高可用、高并發(fā)、高性能及分布式、Jvm性能調(diào)優(yōu)、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個(gè)知識(shí)點(diǎn)的架構(gòu)資料）

其中覆蓋了互聯(lián)網(wǎng)的方方面面，期間碰到各種產(chǎn)品各種場(chǎng)景下的各種問(wèn)題，很值得大家借鑒和學(xué)習(xí)，擴(kuò)展自己的技術(shù)廣度和知識(shí)面。

如何設(shè)置合理的mysql的參數(shù)？

[client]\x0d\x0aport = 3306\x0d\x0asocket = /tmp/mysql.sock\x0d\x0a[mysqld]\x0d\x0aport = 3306\x0d\x0asocket = /tmp/mysql.sock\x0d\x0a\x0d\x0abasedir = /usr/local/mysql\x0d\x0adatadir = /data/mysql\x0d\x0apid-file = /data/mysql/mysql.pid\x0d\x0auser = mysql\x0d\x0abind-address = 0.0.0.0\x0d\x0aserver-id = 1 #表示是本機(jī)的序號(hào)為1,一般來(lái)講就是master的意思\x0d\x0a\x0d\x0askip-name-resolve\x0d\x0a# 禁止MySQL對(duì)外部連接進(jìn)行DNS解析，使用這一選項(xiàng)可以消除MySQL進(jìn)行DNS解析的時(shí)間。但需要注意，如果開(kāi)啟該選項(xiàng)，\x0d\x0a# 則所有遠(yuǎn)程主機(jī)連接授權(quán)都要使用IP地址方式，否則MySQL將無(wú)法正常處理連接請(qǐng)求\x0d\x0a\x0d\x0a#skip-networking\x0d\x0a\x0d\x0aback_log = 600\x0d\x0a# MySQL能有的連接數(shù)量。當(dāng)主要MySQL線(xiàn)程在一個(gè)很短時(shí)間內(nèi)得到非常多的連接請(qǐng)求，這就起作用，\x0d\x0a# 然后主線(xiàn)程花些時(shí)間(盡管很短)檢查連接并且啟動(dòng)一個(gè)新線(xiàn)程。back_log值指出在MySQL暫時(shí)停止回答新請(qǐng)求之前的短時(shí)間內(nèi)多少個(gè)請(qǐng)求可以被存在堆棧中。\x0d\x0a# 如果期望在一個(gè)短時(shí)間內(nèi)有很多連接，你需要增加它。也就是說(shuō)，如果MySQL的連接數(shù)據(jù)達(dá)到max_connections時(shí)，新來(lái)的請(qǐng)求將會(huì)被存在堆棧中，\x0d\x0a# 以等待某一連接釋放資源，該堆棧的數(shù)量即back_log，如果等待連接的數(shù)量超過(guò)back_log，將不被授予連接資源。\x0d\x0a# 另外，這值（back_log）限于您的操作系統(tǒng)對(duì)到來(lái)的TCP/IP連接的偵聽(tīng)隊(duì)列的大小。\x0d\x0a# 你的操作系統(tǒng)在這個(gè)隊(duì)列大小上有它自己的限制（可以檢查你的OS文檔找出這個(gè)變量的最大值），試圖設(shè)定back_log高于你的操作系統(tǒng)的限制將是無(wú)效的。\x0d\x0a\x0d\x0amax_connections = 1000\x0d\x0a# \x0d\x0aMySQL的最大連接數(shù)，如果服務(wù)器的并發(fā)連接請(qǐng)求量比較大，建議調(diào)高此值，以增加并行連接數(shù)量，當(dāng)然這建立在機(jī)器能支撐的情況下，因?yàn)槿绻B接數(shù)越多，\x0d\x0a介于MySQL會(huì)為每個(gè)連接提供連接緩沖區(qū)，就會(huì)開(kāi)銷(xiāo)越多的內(nèi)存，所以要適當(dāng)調(diào)整該值，不能盲目提高設(shè)值。可以過(guò)'conn%'通配符查看當(dāng)前狀態(tài)的連接\x0d\x0a數(shù)量，以定奪該值的大小。\x0d\x0a\x0d\x0amax_connect_errors = 6000\x0d\x0a# 對(duì)于同一主機(jī)，如果有超出該參數(shù)值個(gè)數(shù)的中斷錯(cuò)誤連接，則該主機(jī)將被禁止連接。如需對(duì)該主機(jī)進(jìn)行解禁，執(zhí)行：FLUSH HOST。\x0d\x0a\x0d\x0aopen_files_limit = 65535\x0d\x0a# MySQL打開(kāi)的文件描述符限制，默認(rèn)最小1024;當(dāng)open_files_limit沒(méi)有被配置的時(shí)候，比較max_connections*5和ulimit -n的值，哪個(gè)大用哪個(gè)，\x0d\x0a# 當(dāng)open_file_limit被配置的時(shí)候，比較open_files_limit和max_connections*5的值，哪個(gè)大用哪個(gè)。\x0d\x0a\x0d\x0atable_open_cache = 128\x0d\x0a# MySQL每打開(kāi)一個(gè)表，都會(huì)讀入一些數(shù)據(jù)到table_open_cache緩存中，當(dāng)MySQL在這個(gè)緩存中找不到相應(yīng)信息時(shí)，才會(huì)去磁盤(pán)上讀取。默認(rèn)值64\x0d\x0a# 假定系統(tǒng)有200個(gè)并發(fā)連接，則需將此參數(shù)設(shè)置為200*N(N為每個(gè)連接所需的文件描述符數(shù)目)；\x0d\x0a# 當(dāng)把table_open_cache設(shè)置為很大時(shí)，如果系統(tǒng)處理不了那么多文件描述符，那么就會(huì)出現(xiàn)客戶(hù)端失效，連接不上\x0d\x0a\x0d\x0amax_allowed_packet = 4M\x0d\x0a# 接受的數(shù)據(jù)包大小；增加該變量的值十分安全，這是因?yàn)閮H當(dāng)需要時(shí)才會(huì)分配額外內(nèi)存。例如，僅當(dāng)你發(fā)出長(zhǎng)查詢(xún)或MySQLd必須返回大的結(jié)果行時(shí)MySQLd才會(huì)分配更多內(nèi)存。\x0d\x0a# 該變量之所以取較小默認(rèn)值是一種預(yù)防措施，以捕獲客戶(hù)端和服務(wù)器之間的錯(cuò)誤信息包，并確保不會(huì)因偶然使用大的信息包而導(dǎo)致內(nèi)存溢出。\x0d\x0a\x0d\x0abinlog_cache_size = 1M\x0d\x0a# 一個(gè)事務(wù)，在沒(méi)有提交的時(shí)候，產(chǎn)生的日志，記錄到Cache中；等到事務(wù)提交需要提交的時(shí)候，則把日志持久化到磁盤(pán)。默認(rèn)binlog_cache_size大小32K\x0d\x0a\x0d\x0amax_heap_table_size = 8M\x0d\x0a# 定義了用戶(hù)可以創(chuàng)建的內(nèi)存表(memory table)的大小。這個(gè)值用來(lái)計(jì)算內(nèi)存表的最大行數(shù)值。這個(gè)變量支持動(dòng)態(tài)改變\x0d\x0a\x0d\x0atmp_table_size = 16M\x0d\x0a# MySQL的heap（堆積）表緩沖大小。所有聯(lián)合在一個(gè)DML指令內(nèi)完成，并且大多數(shù)聯(lián)合甚至可以不用臨時(shí)表即可以完成。\x0d\x0a# 大多數(shù)臨時(shí)表是基于內(nèi)存的(HEAP)表。具有大的記錄長(zhǎng)度的臨時(shí)表 (所有列的長(zhǎng)度的和)或包含BLOB列的表存儲(chǔ)在硬盤(pán)上。\x0d\x0a#\x0d\x0a \x0d\x0a如果某個(gè)內(nèi)部heap（堆積）表大小超過(guò)tmp_table_size，MySQL可以根據(jù)需要自動(dòng)將內(nèi)存中的heap表改為基于硬盤(pán)的MyISAM表。\x0d\x0a還可以通過(guò)設(shè)置tmp_table_size選項(xiàng)來(lái)增加臨時(shí)表的大小。也就是說(shuō)，如果調(diào)高該值，MySQL同時(shí)將增加heap表的大小，可達(dá)到提高聯(lián)接查\x0d\x0a詢(xún)速度的效果\x0d\x0a\x0d\x0aread_buffer_size = 2M\x0d\x0a# MySQL讀入緩沖區(qū)大小。對(duì)表進(jìn)行順序掃描的請(qǐng)求將分配一個(gè)讀入緩沖區(qū)，MySQL會(huì)為它分配一段內(nèi)存緩沖區(qū)。read_buffer_size變量控制這一緩沖區(qū)的大小。\x0d\x0a# 如果對(duì)表的順序掃描請(qǐng)求非常頻繁，并且你認(rèn)為頻繁掃描進(jìn)行得太慢，可以通過(guò)增加該變量值以及內(nèi)存緩沖區(qū)大小提高其性能\x0d\x0a\x0d\x0aread_rnd_buffer_size = 8M\x0d\x0a# MySQL的隨機(jī)讀緩沖區(qū)大小。當(dāng)按任意順序讀取行時(shí)(例如，按照排序順序)，將分配一個(gè)隨機(jī)讀緩存區(qū)。進(jìn)行排序查詢(xún)時(shí)，\x0d\x0a# MySQL會(huì)首先掃描一遍該緩沖，以避免磁盤(pán)搜索，提高查詢(xún)速度，如果需要排序大量數(shù)據(jù)，可適當(dāng)調(diào)高該值。但MySQL會(huì)為每個(gè)客戶(hù)連接發(fā)放該緩沖空間，所以應(yīng)盡量適當(dāng)設(shè)置該值，以避免內(nèi)存開(kāi)銷(xiāo)過(guò)大\x0d\x0a\x0d\x0asort_buffer_size = 8M\x0d\x0a# MySQL執(zhí)行排序使用的緩沖大小。如果想要增加ORDER BY的速度，首先看是否可以讓MySQL使用索引而不是額外的排序階段。\x0d\x0a# 如果不能，可以嘗試增加sort_buffer_size變量的大小\x0d\x0a\x0d\x0ajoin_buffer_size = 8M\x0d\x0a# 聯(lián)合查詢(xún)操作所能使用的緩沖區(qū)大小，和sort_buffer_size一樣，該參數(shù)對(duì)應(yīng)的分配內(nèi)存也是每連接獨(dú)享\x0d\x0a\x0d\x0athread_cache_size = 8\x0d\x0a# 這個(gè)值（默認(rèn)8）表示可以重新利用保存在緩存中線(xiàn)程的數(shù)量，當(dāng)斷開(kāi)連接時(shí)如果緩存中還有空間，那么客戶(hù)端的線(xiàn)程將被放到緩存中，\x0d\x0a# 如果線(xiàn)程重新被請(qǐng)求，那么請(qǐng)求將從緩存中讀取,如果緩存中是空的或者是新的請(qǐng)求，那么這個(gè)線(xiàn)程將被重新創(chuàng)建,如果有很多新的線(xiàn)程，\x0d\x0a# 增加這個(gè)值可以改善系統(tǒng)性能.通過(guò)比較Connections和Threads_created狀態(tài)的變量，可以看到這個(gè)變量的作用。(_表示要調(diào)整的值)\x0d\x0a# 根據(jù)物理內(nèi)存設(shè)置規(guī)則如下：\x0d\x0a# 1G — 8\x0d\x0a# 2G — 16\x0d\x0a# 3G — 32\x0d\x0a# 大于3G — 64\x0d\x0a\x0d\x0aquery_cache_size = 8M\x0d\x0a#MySQL的查詢(xún)緩沖大小（從4.0.1開(kāi)始，MySQL提供了查詢(xún)緩沖機(jī)制）使用查詢(xún)緩沖，MySQL將SELECT語(yǔ)句和查詢(xún)結(jié)果存放在緩沖區(qū)中，\x0d\x0a# 今后對(duì)于同樣的SELECT語(yǔ)句（區(qū)分大小寫(xiě)），將直接從緩沖區(qū)中讀取結(jié)果。根據(jù)MySQL用戶(hù)手冊(cè)，使用查詢(xún)緩沖最多可以達(dá)到238%的效率。\x0d\x0a# 通過(guò)檢查狀態(tài)值'Qcache_%'，可以知道query_cache_size設(shè)置是否合理：如果Qcache_lowmem_prunes的值非常大，則表明經(jīng)常出現(xiàn)緩沖不夠的情況，\x0d\x0a# 如果Qcache_hits的值也非常大，則表明查詢(xún)緩沖使用非常頻繁，此時(shí)需要增加緩沖大小；如果Qcache_hits的值不大，則表明你的查詢(xún)重復(fù)率很低，\x0d\x0a# 這種情況下使用查詢(xún)緩沖反而會(huì)影響效率，那么可以考慮不用查詢(xún)緩沖。此外，在SELECT語(yǔ)句中加入SQL_NO_CACHE可以明確表示不使用查詢(xún)緩沖\x0d\x0a\x0d\x0aquery_cache_limit = 2M\x0d\x0a#指定單個(gè)查詢(xún)能夠使用的緩沖區(qū)大小，默認(rèn)1M\x0d\x0a\x0d\x0akey_buffer_size = 4M\x0d\x0a#指定用于索引的緩沖區(qū)大小，增加它可得到更好處理的索引(對(duì)所有讀和多重寫(xiě))，到你能負(fù)擔(dān)得起那樣多。如果你使它太大，\x0d\x0a# 系統(tǒng)將開(kāi)始換頁(yè)并且真的變慢了。對(duì)于內(nèi)存在4GB左右的服務(wù)器該參數(shù)可設(shè)置為384M或512M。通過(guò)檢查狀態(tài)值Key_read_requests和Key_reads，\x0d\x0a# 可以知道key_buffer_size設(shè)置是否合理。比例key_reads/key_read_requests應(yīng)該盡可能的低，\x0d\x0a# 至少是1:100，1:1000更好(上述狀態(tài)值可以使用SHOW STATUS LIKE 'key_read%'獲得)。注意：該參數(shù)值設(shè)置的過(guò)大反而會(huì)是服務(wù)器整體效率降低\x0d\x0a\x0d\x0aft_min_word_len = 4\x0d\x0a# 分詞詞匯最小長(zhǎng)度，默認(rèn)4\x0d\x0a\x0d\x0atransaction_isolation = REPEATABLE-READ\x0d\x0a# MySQL支持4種事務(wù)隔離級(jí)別，他們分別是：\x0d\x0a# READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ, SERIALIZABLE.\x0d\x0a# 如沒(méi)有指定，MySQL默認(rèn)采用的是REPEATABLE-READ，ORACLE默認(rèn)的是READ-COMMITTED\x0d\x0a\x0d\x0alog_bin = mysql-bin\x0d\x0abinlog_format = mixed\x0d\x0aexpire_logs_days = 30 #超過(guò)30天的binlog刪除\x0d\x0a\x0d\x0alog_error = /data/mysql/mysql-error.log #錯(cuò)誤日志路徑\x0d\x0aslow_query_log = 1\x0d\x0along_query_time = 1 #慢查詢(xún)時(shí)間 超過(guò)1秒則為慢查詢(xún)\x0d\x0aslow_query_log_file = /data/mysql/mysql-slow.log\x0d\x0a\x0d\x0aperformance_schema = 0\x0d\x0aexplicit_defaults_for_timestamp\x0d\x0a\x0d\x0a#lower_case_table_names = 1 #不區(qū)分大小寫(xiě)\x0d\x0a\x0d\x0askip-external-locking #MySQL選項(xiàng)以避免外部鎖定。該選項(xiàng)默認(rèn)開(kāi)啟\x0d\x0a\x0d\x0adefault-storage-engine = InnoDB #默認(rèn)存儲(chǔ)引擎\x0d\x0a\x0d\x0ainnodb_file_per_table = 1\x0d\x0a# InnoDB為獨(dú)立表空間模式，每個(gè)數(shù)據(jù)庫(kù)的每個(gè)表都會(huì)生成一個(gè)數(shù)據(jù)空間\x0d\x0a# 獨(dú)立表空間優(yōu)點(diǎn)：\x0d\x0a# 1．每個(gè)表都有自已獨(dú)立的表空間。\x0d\x0a# 2．每個(gè)表的數(shù)據(jù)和索引都會(huì)存在自已的表空間中。\x0d\x0a# 3．可以實(shí)現(xiàn)單表在不同的數(shù)據(jù)庫(kù)中移動(dòng)。\x0d\x0a# 4．空間可以回收（除drop table操作處，表空不能自已回收）\x0d\x0a# 缺點(diǎn)：\x0d\x0a# 單表增加過(guò)大，如超過(guò)100G\x0d\x0a# 結(jié)論：\x0d\x0a# 共享表空間在Insert操作上少有優(yōu)勢(shì)。其它都沒(méi)獨(dú)立表空間表現(xiàn)好。當(dāng)啟用獨(dú)立表空間時(shí)，請(qǐng)合理調(diào)整：innodb_open_files\x0d\x0a\x0d\x0ainnodb_open_files = 500\x0d\x0a# 限制Innodb能打開(kāi)的表的數(shù)據(jù)，如果庫(kù)里的表特別多的情況，請(qǐng)?jiān)黾舆@個(gè)。這個(gè)值默認(rèn)是300\x0d\x0a\x0d\x0ainnodb_buffer_pool_size = 64M\x0d\x0a# InnoDB使用一個(gè)緩沖池來(lái)保存索引和原始數(shù)據(jù), 不像MyISAM.\x0d\x0a# 這里你設(shè)置越大,你在存取表里面數(shù)據(jù)時(shí)所需要的磁盤(pán)I/O越少.\x0d\x0a# 在一個(gè)獨(dú)立使用的數(shù)據(jù)庫(kù)服務(wù)器上,你可以設(shè)置這個(gè)變量到服務(wù)器物理內(nèi)存大小的80%\x0d\x0a# 不要設(shè)置過(guò)大,否則,由于物理內(nèi)存的競(jìng)爭(zhēng)可能導(dǎo)致操作系統(tǒng)的換頁(yè)顛簸.\x0d\x0a# 注意在32位系統(tǒng)上你每個(gè)進(jìn)程可能被限制在 2-3.5G 用戶(hù)層面內(nèi)存限制,\x0d\x0a# 所以不要設(shè)置的太高.\x0d\x0a\x0d\x0ainnodb_write_io_threads = 4\x0d\x0ainnodb_read_io_threads = 4\x0d\x0a# innodb使用后臺(tái)線(xiàn)程處理數(shù)據(jù)頁(yè)上的讀寫(xiě) I/O(輸入輸出)請(qǐng)求,根據(jù)你的 CPU 核數(shù)來(lái)更改,默認(rèn)是4\x0d\x0a# 注:這兩個(gè)參數(shù)不支持動(dòng)態(tài)改變,需要把該參數(shù)加入到my.cnf里，修改完后重啟MySQL服務(wù),允許值的范圍從 1-64\x0d\x0a\x0d\x0ainnodb_thread_concurrency = 0\x0d\x0a# 默認(rèn)設(shè)置為 0,表示不限制并發(fā)數(shù)，這里推薦設(shè)置為0，更好去發(fā)揮CPU多核處理能力，提高并發(fā)量\x0d\x0a\x0d\x0ainnodb_purge_threads = 1\x0d\x0a# InnoDB中的清除操作是一類(lèi)定期回收無(wú)用數(shù)據(jù)的操作。在之前的幾個(gè)版本中，清除操作是主線(xiàn)程的一部分，這意味著運(yùn)行時(shí)它可能會(huì)堵塞其它的數(shù)據(jù)庫(kù)操作。\x0d\x0a# 從MySQL5.5.X版本開(kāi)始，該操作運(yùn)行于獨(dú)立的線(xiàn)程中,并支持更多的并發(fā)數(shù)。用戶(hù)可通過(guò)設(shè)置innodb_purge_threads配置參數(shù)來(lái)選擇清除操作是否使用單\x0d\x0a# 獨(dú)線(xiàn)程,默認(rèn)情況下參數(shù)設(shè)置為0(不使用單獨(dú)線(xiàn)程),設(shè)置為 1 時(shí)表示使用單獨(dú)的清除線(xiàn)程。建議為1\x0d\x0a\x0d\x0ainnodb_flush_log_at_trx_commit = 2\x0d\x0a# 0：如果innodb_flush_log_at_trx_commit的值為0,log buffer每秒就會(huì)被刷寫(xiě)日志文件到磁盤(pán)，提交事務(wù)的時(shí)候不做任何操作（執(zhí)行是由mysql的master thread線(xiàn)程來(lái)執(zhí)行的。\x0d\x0a# 主線(xiàn)程中每秒會(huì)將重做日志緩沖寫(xiě)入磁盤(pán)的重做日志文件(REDO LOG)中。不論事務(wù)是否已經(jīng)提交）默認(rèn)的日志文件是ib_logfile0,ib_logfile1\x0d\x0a# 1：當(dāng)設(shè)為默認(rèn)值1的時(shí)候，每次提交事務(wù)的時(shí)候，都會(huì)將log buffer刷寫(xiě)到日志。\x0d\x0a# 2：如果設(shè)為2,每次提交事務(wù)都會(huì)寫(xiě)日志，但并不會(huì)執(zhí)行刷的操作。每秒定時(shí)會(huì)刷到日志文件。要注意的是，并不能保證100%每秒一定都會(huì)刷到磁盤(pán)，這要取決于進(jìn)程的調(diào)度。\x0d\x0a# 每次事務(wù)提交的時(shí)候?qū)?shù)據(jù)寫(xiě)入事務(wù)日志，而這里的寫(xiě)入僅是調(diào)用了文件系統(tǒng)的寫(xiě)入操作，而文件系統(tǒng)是有 緩存的，所以這個(gè)寫(xiě)入并不能保證數(shù)據(jù)已經(jīng)寫(xiě)入到物理磁盤(pán)\x0d\x0a# 默認(rèn)值1是為了保證完整的ACID。當(dāng)然，你可以將這個(gè)配置項(xiàng)設(shè)為1以外的值來(lái)?yè)Q取更高的性能，但是在系統(tǒng)崩潰的時(shí)候，你將會(huì)丟失1秒的數(shù)據(jù)。\x0d\x0a# 設(shè)為0的話(huà)，mysqld進(jìn)程崩潰的時(shí)候，就會(huì)丟失最后1秒的事務(wù)。設(shè)為2,只有在操作系統(tǒng)崩潰或者斷電的時(shí)候才會(huì)丟失最后1秒的數(shù)據(jù)。InnoDB在做恢復(fù)的時(shí)候會(huì)忽略這個(gè)值。\x0d\x0a# 總結(jié)\x0d\x0a# 設(shè)為1當(dāng)然是最安全的，但性能頁(yè)是最差的（相對(duì)其他兩個(gè)參數(shù)而言，但不是不能接受）。如果對(duì)數(shù)據(jù)一致性和完整性要求不高，完全可以設(shè)為2，如果只最求性能，例如高并發(fā)寫(xiě)的日志服務(wù)器，設(shè)為0來(lái)獲得更高性能\x0d\x0a\x0d\x0ainnodb_log_buffer_size = 2M\x0d\x0a# 此參數(shù)確定些日志文件所用的內(nèi)存大小，以M為單位。緩沖區(qū)更大能提高性能，但意外的故障將會(huì)丟失數(shù)據(jù)。MySQL開(kāi)發(fā)人員建議設(shè)置為1－8M之間\x0d\x0a\x0d\x0ainnodb_log_file_size = 32M\x0d\x0a# 此參數(shù)確定數(shù)據(jù)日志文件的大小，更大的設(shè)置可以提高性能，但也會(huì)增加恢復(fù)故障數(shù)據(jù)庫(kù)所需的時(shí)間\x0d\x0a\x0d\x0ainnodb_log_files_in_group = 3\x0d\x0a# 為提高性能，MySQL可以以循環(huán)方式將日志文件寫(xiě)到多個(gè)文件。推薦設(shè)置為3\x0d\x0a\x0d\x0ainnodb_max_dirty_pages_pct = 90\x0d\x0a# innodb主線(xiàn)程刷新緩存池中的數(shù)據(jù)，使臟數(shù)據(jù)比例小于90%\x0d\x0a\x0d\x0ainnodb_lock_wait_timeout = 120 \x0d\x0a# InnoDB事務(wù)在被回滾之前可以等待一個(gè)鎖定的超時(shí)秒數(shù)。InnoDB在它自己的鎖定表中自動(dòng)檢測(cè)事務(wù)死鎖并且回滾事務(wù)。InnoDB用LOCK TABLES語(yǔ)句注意到鎖定設(shè)置。默認(rèn)值是50秒\x0d\x0a\x0d\x0abulk_insert_buffer_size = 8M\x0d\x0a# 批量插入緩存大小， 這個(gè)參數(shù)是針對(duì)MyISAM存儲(chǔ)引擎來(lái)說(shuō)的。適用于在一次性插入100-1000+條記錄時(shí)， 提高效率。默認(rèn)值是8M。可以針對(duì)數(shù)據(jù)量的大小，翻倍增加。\x0d\x0a\x0d\x0amyisam_sort_buffer_size = 8M\x0d\x0a# MyISAM設(shè)置恢復(fù)表之時(shí)使用的緩沖區(qū)的尺寸，當(dāng)在REPAIR TABLE或用CREATE INDEX創(chuàng)建索引或ALTER TABLE過(guò)程中排序 MyISAM索引分配的緩沖區(qū)\x0d\x0a\x0d\x0amyisam_max_sort_file_size = 10G\x0d\x0a# 如果臨時(shí)文件會(huì)變得超過(guò)索引，不要使用快速排序索引方法來(lái)創(chuàng)建一個(gè)索引。注釋?zhuān)哼@個(gè)參數(shù)以字節(jié)的形式給出\x0d\x0a\x0d\x0amyisam_repair_threads = 1\x0d\x0a# 如果該值大于1，在Repair by sorting過(guò)程中并行創(chuàng)建MyISAM表索引(每個(gè)索引在自己的線(xiàn)程內(nèi)) \x0d\x0a\x0d\x0ainteractive_timeout = 28800\x0d\x0a# 服務(wù)器關(guān)閉交互式連接前等待活動(dòng)的秒數(shù)。交互式客戶(hù)端定義為在mysql_real_connect()中使用CLIENT_INTERACTIVE選項(xiàng)的客戶(hù)端。默認(rèn)值：28800秒（8小時(shí)）\x0d\x0a\x0d\x0await_timeout = 28800\x0d\x0a# 服務(wù)器關(guān)閉非交互連接之前等待活動(dòng)的秒數(shù)。在線(xiàn)程啟動(dòng)時(shí)，根據(jù)全局wait_timeout值或全局interactive_timeout值初始化會(huì)話(huà)wait_timeout值，\x0d\x0a# 取決于客戶(hù)端類(lèi)型(由mysql_real_connect()的連接選項(xiàng)CLIENT_INTERACTIVE定義)。參數(shù)默認(rèn)值：28800秒（8小時(shí)）\x0d\x0a# MySQL服務(wù)器所支持的最大連接數(shù)是有上限的，因?yàn)槊總€(gè)連接的建立都會(huì)消耗內(nèi)存，因此我們希望客戶(hù)端在連接到MySQL Server處理完相應(yīng)的操作后，\x0d\x0a# 應(yīng)該斷開(kāi)連接并釋放占用的內(nèi)存。如果你的MySQL Server有大量的閑置連接，他們不僅會(huì)白白消耗內(nèi)存，而且如果連接一直在累加而不斷開(kāi)，\x0d\x0a# 最終肯定會(huì)達(dá)到MySQL Server的連接上限數(shù)，這會(huì)報(bào)'too many connections'的錯(cuò)誤。對(duì)于wait_timeout的值設(shè)定，應(yīng)該根據(jù)系統(tǒng)的運(yùn)行情況來(lái)判斷。\x0d\x0a# 在系統(tǒng)運(yùn)行一段時(shí)間后，可以通過(guò)show processlist命令查看當(dāng)前系統(tǒng)的連接狀態(tài)，如果發(fā)現(xiàn)有大量的sleep狀態(tài)的連接進(jìn)程，則說(shuō)明該參數(shù)設(shè)置的過(guò)大，\x0d\x0a# 可以進(jìn)行適當(dāng)?shù)恼{(diào)整小些。要同時(shí)設(shè)置interactive_timeout和wait_timeout才會(huì)生效。\x0d\x0a\x0d\x0a[mysqldump]\x0d\x0aquick\x0d\x0amax_allowed_packet = 16M #服務(wù)器發(fā)送和接受的最大包長(zhǎng)度\x0d\x0a[myisamchk]\x0d\x0akey_buffer_size = 8M\x0d\x0asort_buffer_size = 8M\x0d\x0aread_buffer = 4M\x0d\x0awrite_buffer = 4M

標(biāo)題名稱(chēng)：mysql怎么設(shè)置性能 mysql性能調(diào)優(yōu)與架構(gòu)設(shè)計(jì)
網(wǎng)頁(yè)網(wǎng)址：http://chinadenli.net/article18/dojopdp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供移動(dòng)網(wǎng)站建設(shè)、企業(yè)建站、網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)、軟件開(kāi)發(fā)、做網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)