mysql存儲引擎優化參數

時間 2019-12-24

標籤 mysql 存儲引擎優化參數欄目 MySQL 简体版

原文原文鏈接

MySQL配置參數優化mysql

本文來自道森學習筆記，版權歸 http://wubx.net/ 全部面試

MyISAM存儲引擎優化算法

涉及參數以下：sql

Key_buffery_size數據庫

Concurrent_insert = 2 | WAAYS安全

Bulk_insert_buffer_size=8Mdom

Myisam_recover_options=FORCEide

Myisam_recover_threads=1性能

Myisam_sort_buffer_size=1G學習

參數解釋：

key_buffery_size

主要用於存放myisam表的索引信息，並且還有專門的IO調度算法，若是搞不定將會將其buffer沖掉

#在mysql 5.6版本默認引擎調整爲了innodb，臨時表默認引擎也同樣，因此myisam引擎基本調整一下key_buffer_size 便可，可是不能禁掉，由於mysql庫目前裏面大多數都是myisam

只有幾張表是innodb，因此這裏面不少都是myisam引擎不能將其禁掉

可是對於5.6版本中key_buffer_size 給8M就能夠

bulk_inser_buffer_size = 8M (默認)

在高版本中默認8M，低版本默認仍是4M；因此若是小的話能夠改大一點，這個值一般來講通常sql爲：

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

若是配置的是1M，那麼insert執行了4M的數據，這樣的話會報錯，默認狀況下不用調整，可是若是作數據採集之類的場景，須要將其調大

對於myisam表可能會出現壞掉了之類的狀況，這個裏面能夠將如下幾個參數開打：

Myisam_recover_options=FORCE

Myisam_recover_threads=1

Myisam_sort_buffer_size=1G

這樣會自動進行修復，對於myisam表是一種修復

本文來自道森學習筆記，版權歸 http://wubx.net/ 全部

可是有缺點，若是使用Myisam_recover_options=FORCE ，極可能會丟失數據，由於myisam表已經不能保證數據一致性，因此丟數據也避免不了，因此，若是業務數據很是重要，對於安全性要求很高，那麼儘可能不要用myisam

由於5.5以後官方不會對myisam作任何升級和維護；5.6以後默認引擎爲innodb。臨時表也改成innodb

本文來自道森學習筆記，版權歸 http://wubx.net/ 全部

innodb引擎優化

innodb_buffer_pool_size （面試必問）

主要存放熱數據，按照page來存放，page爲最小單位，甚至是按段來存放

建議值：若是是專用數據庫server 建議分到物理內存的50% -- 75%

若是跑有其餘服務，那麼建議「2/8的原則」：

好比100G的數據，最少達到10%的活躍數據，那麼建議buffer pool分20G

若是是好友關係系統，這樣的數據都幾乎是熱數據，那麼建議30%-50%的內存

再好比偷菜遊戲，幾乎全部都能達到90%的熱數據，那麼你懂的

innodb_buffer_pool_instances

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

通常狀況下設置爲8 ，在5.5版本是分到4 ，到了5.6版本以後要分到8，不能改爲其餘值，由於這是壓測得出的結果，8是可能獲得最好的性能

innodb_log_file_size

建議設置爲data page的百分比，好比page爲15% 那麼buffer pool爲100G ，那麼兩邊相乘得出結果爲15G，其實建議的是與data page配置的相等，有可能都配置不了那麼大，那麼就將file_size設置爲1g

那麼若是咱們要用多個log file，就會涉及到如下參數：

innodb_log_file_in_gourp

能夠設置有幾個log文件，至於如何計算：

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

Innodb_log_file_ingroup 總大小不要低於600M

通常建議3個log file便可多了沒有必要

本文來自道森學習筆記，版權歸 http://wubx.net/ 全部

innodb_file_per_table

是否設置獨立表空間

在5.6以前是關閉的，在5.6以後默認爲打開，建議是打開狀態

innodb_file_format #建議指定爲 Barracuda

innodb_flush_log_at_trx_commit

若是在導數據，多是2天或者3天也沒有導完，那麼多是這個參數設置爲1的結果致使

1 爲每一次事務進一次刷新到磁盤，安全度高，可是性能最低，常常會致使導數據最慢

0 每秒鐘進一下事務的刷新到磁盤

2 通常建議值，大約每秒一次事務的刷新及同步到磁盤，實際只寫到操做系統的buffer中，操做系統若是斷電會致使失誤丟失；#由於導數據都是人爲參與的過程因此設置爲2，讓速度最大化完成，若是出錯再手動搞一次便可，建議值

innodb_flush_log_at_timeout (在5.6中被引入）

·該參數用於控制每N秒（1-2700秒之間）刷新一第二天志。是對group commit的一個加強功能，默認是1秒，1秒鐘刷新一次並由croup commit來處理，實際能夠在1-2700秒之間來搞，若是系統對性能要求很高，能夠將這個值設置大一些，吞吐率也會更高，由於group commit工做也會更好一點，若是說對同步實時性要求很高，那麼就設置低一點，默認值便可

之間是一個相對的關係，若是調大會獲得一個很好的性能，可是從庫可能會出現延遲

若是調整爲3秒，那麼這3秒作一次commit，那麼在第2秒的時候掛掉了，那麼在這2秒的時候數據會丟失

innodb_flush_method

用指定數據實際寫到磁盤上的方法，直接使用O_DIRECT便可

O_DIRECT 工做在XFS或EXT4上性能都很不錯的

最大問題就是O_DIRECT用來減少系統的VFS級別的cache，節省出來的內存能夠提供buffer pool來使用

若是用fsync來作，其會佔用vfs級別的cache，會佔用大量內存，若是buffer pool很大，那麼容易形成oom

因此使用O_DIRECT來作是爲了節省內存提供buffer pool更大空間

innodb_flush_neighbors

默認是0 在用這個參數以後會臨近extent髒頁面進行刷新
好比在進行寫入的時間，會將髒也進行check ，這個時間會將髒頁面合併成順序寫就是說將臨近的extent也合併進去

再好比第一個extent和第二個extent 是挨着的，那麼移到這裏以後發現第二個也有，那麼順便將第二個也刷過去

若是是sas sata 盤建議使用1；可是對於ssd是沒有尋址延遲，因此不須要髒頁面刷新，由於原先就是熱數據可是刷新以後又變爲冷數據數據又會作一次加載