MySQL配置參數(shù)優(yōu)化

本文來(lái)自道森學(xué)習(xí)筆記，版權(quán)歸 http://wubx.net/?所有

MyISAM存儲(chǔ)引擎優(yōu)化

涉及參數(shù)如下：

Key_buffery_size

Concurrent_insert = 2 | WAAYS

Bulk_insert_buffer_size=8M

?

Myisam_recover_options=FORCE

Myisam_recover_threads=1

Myisam_sort_buffer_size=1G

參數(shù)解釋：

?

key_buffery_size ? ? ?

主要用于存放myisam表的索引信息，而且還有專門(mén)的IO調(diào)度算法，如果搞不定將會(huì)將其buffer沖掉

#在mysql 5.6版本默認(rèn)引擎調(diào)整為了innodb，臨時(shí)表默認(rèn)引擎也一樣，所以myisam引擎基本調(diào)整一下key_buffer_size 即可，但是不能禁掉，因?yàn)閙ysql庫(kù)目前里面大多數(shù)都是myisam

只有幾張表是innodb，所以這里面很多都是myisam引擎 不能將其禁掉

但是對(duì)于5.6版本中key_buffer_size 給8M就可以

?

bulk_inser_buffer_size = 8M (默認(rèn))

在高版本中默認(rèn)8M，低版本默認(rèn)還是4M；所以如果小的話可以改大一點(diǎn)，這個(gè)值通常來(lái)說(shuō)一般sql為 ：?

insert into tb (c1,c2,c3) values(),()....;

如果配置的是1M，那么insert執(zhí)行了4M的數(shù)據(jù)，這樣的話會(huì)報(bào)錯(cuò)，默認(rèn)情況下不用調(diào)整，但是如果做數(shù)據(jù)采集之類的場(chǎng)景，需要將其調(diào)大

?

對(duì)于myisam表 可能會(huì)出現(xiàn)壞掉了之類的情況，這個(gè)里面可以將以下幾個(gè)參數(shù)開(kāi)打：

Myisam_recover_options=FORCE

Myisam_recover_threads=1

Myisam_sort_buffer_size=1G

這樣會(huì)自動(dòng)進(jìn)行修復(fù)，對(duì)于myisam表是一種修復(fù)

?

本文來(lái)自道森學(xué)習(xí)筆記，版權(quán)歸 http://wubx.net/?所有

但是有缺點(diǎn)，如果使用Myisam_recover_options=FORCE ，很可能會(huì)丟失數(shù)據(jù)，因?yàn)閙yisam表已經(jīng)不能保證數(shù)據(jù)一致性，所以丟數(shù)據(jù)也避免不了，所以，如果業(yè)務(wù)數(shù)據(jù)非常重要，對(duì)于安全性要求很高，那么盡量不要用myisam

因?yàn)?.5之后官方不會(huì)對(duì)myisam做任何升級(jí)和維護(hù)；5.6之后默認(rèn)引擎為innodb。臨時(shí)表也改為innodb

?

本文來(lái)自道森學(xué)習(xí)筆記，版權(quán)歸 http://wubx.net/?所有

?

innodb引擎優(yōu)化

innodb_buffer_pool_size???? （面試必問(wèn)）

主要存放熱數(shù)據(jù)，按照page來(lái)存放，page為最小單位，甚至是按段來(lái)存放

建議值： 如果是專用數(shù)據(jù)庫(kù)server 建議分到物理內(nèi)存的50% -- 75%?

?

如果跑有其他服務(wù)，那么建議“2/8的原則”：

比如100G的數(shù)據(jù)，最少達(dá)到10%的活躍數(shù)據(jù)，那么建議buffer pool分20G

如果是好友關(guān)系系統(tǒng)，這樣的數(shù)據(jù)都幾乎是熱數(shù)據(jù)，那么建議30%-50%的內(nèi)存

再比如偷菜游戲，幾乎所有都能達(dá)到90%的熱數(shù)據(jù)，那么你懂的

?

innodb_buffer_pool_instances?? ? ? ?

主要為了方便buffer pool全局的鎖，

一般情況下設(shè)置為8 ，在5.5版本是分到4 ，到了5.6版本之后要分到8，不能改成其他值，因?yàn)檫@是壓測(cè)得出的結(jié)果，8是可能得到最好的性能

?

innodb_log_file_size ? ? ? ? ? ? ? ?

建議設(shè)置為data page的百分比，比如page為15% 那么buffer pool為100G ，那么兩邊相乘得出結(jié)果為15G，其實(shí)建議的是與data page配置的相等，有可能都配置不了那么大，那么就將file_size設(shè)置為1g

?

那么如果我們要用多個(gè)log file，就會(huì)涉及到以下參數(shù)?：

innodb_log_file_in_gourp

可以設(shè)置有幾個(gè)log文件，至于如何計(jì)算：

Innodb的redo log?????????? 文件大小，總大小為innodb_log_file_size *

Innodb_log_file_ingroup???? 總大小不要低于600M

?

一般建議3個(gè)log file即可 多了沒(méi)有必要

?

?

本文來(lái)自道森學(xué)習(xí)筆記，版權(quán)歸 http://wubx.net/?所有

innodb_file_per_table ? ? ? ? ?

是否設(shè)置獨(dú)立表空間

在5.6之前是關(guān)閉的， 在5.6之后默認(rèn)為打開(kāi)，建議是打開(kāi)狀態(tài)

?

innodb_file_format ? ? #建議指定為 Barracuda

???????????????????????????????????????????????????????

?

innodb_flush_log_at_trx_commit

如果在導(dǎo)數(shù)據(jù)，可能是2天或者3天也沒(méi)有導(dǎo)完，那么可能是這個(gè)參數(shù)設(shè)置為1的結(jié)果導(dǎo)致

1 ?為每一次事務(wù)進(jìn)一次刷新到磁盤(pán)，安全度高，但是性能最低，經(jīng)常會(huì)導(dǎo)致導(dǎo)數(shù)據(jù)最慢

0 ?每秒鐘進(jìn)一下事務(wù)的刷新到磁盤(pán)

2 ?一般建議值，大約每秒一次事務(wù)的刷新及同步到磁盤(pán)，實(shí)際只寫(xiě)到操作系統(tǒng)的buffer中，操作系統(tǒng)如果斷電會(huì)導(dǎo)致失誤丟失；#因?yàn)閷?dǎo)數(shù)據(jù)都是人為參與的過(guò)程所以設(shè)置為2，讓速度最大化完成，如果出錯(cuò)再手動(dòng)搞一次即可，建議值

?

innodb_flush_log_at_timeout ?(在5.6中被引入）

·該參數(shù)用于控制每N秒（1-2700秒之間）刷新一次日志。是對(duì)group commit的一個(gè)增強(qiáng)功能，默認(rèn)是1秒，1秒鐘刷新一次并由croup commit來(lái)處理，實(shí)際可以在1-2700秒之間來(lái)搞，如果系統(tǒng)對(duì)性能要求很高，可以將這個(gè)值設(shè)置大一些，吞吐率也會(huì)更高，因?yàn)間roup commit工作也會(huì)更好一點(diǎn)，如果說(shuō)對(duì)同步實(shí)時(shí)性要求很高，那么就設(shè)置低一點(diǎn)，默認(rèn)值即可

之間是一個(gè)相對(duì)的關(guān)系，如果調(diào)大會(huì)得到一個(gè)很好的性能，但是從庫(kù)可能會(huì)出現(xiàn)延遲

如果調(diào)整為3秒，那么這3秒做一次commit，那么在第2秒的時(shí)候掛掉了，那么在這2秒的時(shí)候數(shù)據(jù)會(huì)丟失

?

?

innodb_flush_method

用指定數(shù)據(jù)實(shí)際寫(xiě)到磁盤(pán)上的方法，直接使用O_DIRECT即可

O_DIRECT 工作在XFS或EXT4上性能都很不錯(cuò)的

最大問(wèn)題就是O_DIRECT用來(lái)減小系統(tǒng)的VFS級(jí)別的cache，節(jié)省出來(lái)的內(nèi)存可以提供buffer pool來(lái)使用

如果用fsync來(lái)做，其會(huì)占用vfs級(jí)別的cache，會(huì)占用大量?jī)?nèi)存，如果buffer pool很大，那么容易造成oom

所以使用O_DIRECT來(lái)做是為了節(jié)省內(nèi)存提供buffer pool更大空間

?

innodb_flush_neighbors

默認(rèn)是0 在用這個(gè)參數(shù)之后會(huì)臨近extent臟頁(yè)面進(jìn)行刷新
比如在進(jìn)行寫(xiě)入的時(shí)間，會(huì)將臟也進(jìn)行check ，這個(gè)時(shí)間會(huì)將臟頁(yè)面合并成順序?qū)?就是說(shuō)將臨近的extent也合并進(jìn)去

再比如第一個(gè)extent和第二個(gè)extent 是挨著的，那么移到這里之后發(fā)現(xiàn)第二個(gè)也有，那么順便將第二個(gè)也刷過(guò)去

如果是sas sata 盤(pán)建議使用1；但是對(duì)于ssd是沒(méi)有尋址延遲，所以不需要臟頁(yè)面刷新，因?yàn)樵染褪菬釘?shù)據(jù)但是刷新之后又變?yōu)槔鋽?shù)據(jù)數(shù)據(jù)又會(huì)做一次加載

?

本文來(lái)自道森學(xué)習(xí)筆記，版權(quán)歸 http://wubx.net/?所有

IO相關(guān)優(yōu)化

innodb_io_capacity ? #重要

該參數(shù)為innodb io最大數(shù)?

一般來(lái)說(shuō)10W iops很正常，后期進(jìn)行了優(yōu)化： hdd 150 * 磁盤(pán)數(shù) ， ssd 2000-1萬(wàn)?

比如 6塊盤(pán)做了RAID10 那么這樣計(jì)算的話是 150*3

需要考慮的是6塊盤(pán)做的RAID 需要考慮多少快盤(pán)的IO能力 ；再考慮如果先做RAID 1能否提升IO能力，如果不能提升那么無(wú)非是0可以提升IO能力，所以是6塊盤(pán)的RAID10 只能獲得3塊盤(pán)的IO能力

以下是對(duì)capactiy的補(bǔ)充參數(shù)

比如這里配置的是3塊盤(pán)的450個(gè)，但是峰值會(huì)更高，可能會(huì)達(dá)到1000個(gè)或更多，那么可以對(duì)以下參數(shù)指定最大值

?

innodb_io_capacity_max????????????? #設(shè)置io_capacity 最大值?

?

讀寫(xiě)相關(guān)：

Innodb_write_io_threads

Innodb_read_io_threads

建議配置值：

保持與CPU的數(shù)量一樣就可以了，比如是16核心的cpu 那么配置為16即可

如果是8核就配成8 以此類推

配置太高的話會(huì)到導(dǎo)致系統(tǒng)很卡 ，所以保持一致即可?

?

?

Innodb_write_io_threshold

只允許一次prefech多個(gè)page到bp中 （0-64）

?

Innodb_random_read_ahead

Prefech到bp功能是否打開(kāi)

?

考慮到一些順序IO 和數(shù)據(jù)加載的問(wèn)題

比如現(xiàn)在read io threshold?

比如在一個(gè)用戶系統(tǒng)中讀取了一個(gè)用戶的信息，那么會(huì)將這個(gè)page加載到dp中

那么可能需要說(shuō)是否要將臨近的page也加載進(jìn)來(lái)，這里面有個(gè)問(wèn)題 如果是用戶系統(tǒng) 那么就在一個(gè)page中不需要加載臨近的page 直接將其關(guān)掉，那么這個(gè)參數(shù)絕對(duì)是0 因?yàn)椴恍枰~外的數(shù)據(jù)

但是如果是好友關(guān)系的話，數(shù)據(jù)讀到這個(gè)用戶 那么通過(guò)程序需要將其臨近的用戶也讀取出來(lái)并加載那么可以將這個(gè)參數(shù)設(shè)置大一些 讓其多讀一些 比如3個(gè)

這個(gè)參數(shù)需要根據(jù)業(yè)務(wù)系統(tǒng)進(jìn)行結(jié)合如果把我不住就不要管他

?

?

?

?

?

轉(zhuǎn)載于:https://blog.51cto.com/yijiu/1622117

總結(jié)

以上是生活随笔為你收集整理的mysql存储引擎优化参数的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。