Mysql配置檔案 innodb引擎

阿新 • • 發佈：2021-12-14

innodb引數

innodb引數

innodb_buffer_pool_size

這個是Innodb最重要的引數，主要作用是快取innodb表的索引，資料，插入資料時的緩衝，預設值為128M。

如果是一個專用innodb引擎的伺服器，那麼它可以佔到記憶體的70%-80%。並不是設定的越大越好。設定的過大，會導致system的swap空間被佔用，導致作業系統變慢，從而減低sql查詢的效率。

如果你的資料比較小，那麼可分配是你的資料大小+10%左右做為這個引數的值。例如：資料大小為50M,那麼給這個值分配innodb_buffer_pool_size＝64M就夠了

查詢：
線上配置：
配置檔案：innodb_buffer_pool_size = 16G

innodb_read_io_threads|innodb_write_io_threads

在MySQL5.1.X版本中，innodb_file_io_threads引數預設是4，該引數在Linux系統上是不可更改的，但Windows系統上可以調整。這個引數的作用是：InnoDB使用後臺執行緒處理資料頁上讀寫I/O（輸入輸出）請求的數量。

在MySQL5.5.X版本中，或者說是在InnoDB Plugin1.0.4以後，就用兩個新的引數，即innodb_read_io_threads和innodb_write_io_threads，取代了innodb_file_io_threads如此調整後，在Linux平臺上就可以根據CPU核數來更改相應的引數值了，預設是4。

假如CPU是2顆8核的，共16核，那麼可以設定：
innodb_read_io_threads = 8
innodb_write_io_threads = 8

如果資料庫的讀操作比寫操作多，那麼可以設定：
innodb_read_io_threads = 10
innodb_write_io_threads = 6

innodb_open_files

限制Innodb能開啟的表的資料，預設為300，資料庫裡的表特別多的情況，可以適當增大為1000。innodb_open_files的大小對InnoDB效率的影響比較小。

但是在InnoDBcrash的情況下，innodb_open_files設定過小會影響recovery的效率。所以用InnoDB的時候還是把innodb_open_files放大一些比較合適。

查詢：
線上配置：
配置檔案：innodb_open_files = 1000

innodb_log_file_size

這個引數指定在一個日誌組中，每個log的大小。

innodb的logfile就是事務日誌，用來在mysql crash後的恢復。所以設定合理的大小對於mysql的效能非常重要，直接影響資料庫的寫入速度，事務大小，異常重啟後的恢復。

在mysql 5.5和5.5以前innodb的logfile最大設定為4GB,在5.6以後的版本中logfile最大的可以設為512GB。一般取256M可以兼顧效能和recovery的速度。

查詢：select @@innodb_log_file_size;
線上配置：
配置檔案：innodb_log_file_size=256M

innodb_log_buffer_size

事務在記憶體中的緩衝，也就是日誌緩衝區的大小，預設設定即可，具有大量事務的可以考慮設定為64-512MB。

一般來說，日誌檔案的全部大小，應該足夠容納伺服器一個小時的活動內容。

查詢：
線上配置：
配置檔案：innodb_log_buffer_size = 128M

innodb_flush_log_at_trx_commit

控制事務的提交方式,也就是控制log的重新整理到磁碟的方式，這個引數只有3個值（0，1，2）.預設為1。

當這個值為0時：日誌緩衝每秒一次地被寫到日誌檔案，並且對日誌檔案做到磁碟操作的重新整理，但是在一個事務提交不做任何操作。mysqld程序的崩潰會刪除崩潰前最後一秒的事務。

當這個值為1時：innodb 的事務LOG在每次提交後寫入日值檔案，並對日值做重新整理到磁碟。這個可以做到不丟任何一個事務。

當這個值為2時：在每個提交，日誌緩衝被寫到檔案，但不對日誌檔案做到磁碟操作的重新整理,在對日誌檔案的重新整理在值為2的情況也每秒發生一次。但需要注意的是，由於程序呼叫方面的問題，並不能保證每秒１００％的發生。從而在效能上是最快的。但作業系統崩潰或掉電才會刪除最後一秒的事務。

查詢：
線上配置：
配置檔案：innodb_flush_log_at_trx_commit = 1

innodb_flush_method

這個引數控制著innodb資料檔案及redo log的開啟、刷寫模式，有三個值：fdatasync(預設)，O_DSYNC，O_DIRECT。

fdatasync：呼叫fsync()去刷資料檔案與redo log的buffer

O_DSYNC時：innodb會使用O_SYNC方式開啟和刷寫redo log,使用fsync()刷寫資料檔案

O_DIRECT時：innodb使用O_DIRECT開啟資料檔案，使用fsync()刷寫資料檔案跟redo log。

在類unix作業系統中，檔案的開啟方式為O_DIRECT會最小化緩衝對io的影響，該檔案的io是直接在使用者空間的buffer上操作的，並且io操作是同步的，因此不管是read()系統呼叫還是write()系統呼叫，資料都保證是從磁碟上讀取的

查詢：
線上配置：
配置檔案：innodb_flush_method=O_DIRECT

innodb_data_home_dir

innodb引擎的共享表空間資料檔案根目錄。如果未指定，預設會在datadir目錄下建立ibdata1 作為innodb tablespace。

查詢：
線上配置：
配置檔案：innodb_data_home_dir = /Data/data

innodb_data_file_path

它不僅指定了所有InnoDB資料檔案的路徑，還指定了初始大小分配，最大分配以及超出起始分配界線時是否應當增加檔案的大小。

例如，假設希望建立一個數據檔案sales，初始大小為100MB，並希望在每次達到當前大小限制時，自動增加8MB（8MB是指定autoextend時的預設擴充套件大小).但是，不希望此檔案超過1GB，可以使用如下配置:
innodb_data_home_dir =
innodb_data_file_path = /data/sales:100M:autoextend:8M:max:1GB

如果此檔案增加到預定的1G的限制，可以再增加另外一個數據檔案,
innodb_data_file_path = /data/sales:100M:autoextend:8M: max:1GB;innodb_data_file_path = /data2/sales2:100M:autoextend:8M: max:2GB

要注意的是，在這些示例中，inndb_data_home_dir引數開始設定為空，因為最終資料檔案位於單獨的位置(/data/和/data2/）.如果希望所有 InnoDB資料檔案都位於相同的位置，就可以使用innodb_data_home_dir來指定共同位置，然後在通過 inndo_data_file_path來指定檔名即可。如果沒有定義這些值，將在datadir中建立一個sales。

查詢：
線上配置：
配置檔案：innodb_data_file_path = ibdata1:10M:autoextend

innodb_purge_threads

由於每次DML操作都會生成Undo頁，系統需要定期對這些undo頁進行清理，也就是所謂purge操作。在5.5之前這些都是在master執行緒中完成，但5.5及之後的版本可以通過innodb_purge_threads來控制是否使用獨立執行緒進行purge操作。

查詢：
線上配置：
配置檔案：innodb_purge_threads = 1

innodb_log_group_home_dir

此引數確定日誌檔案組中的檔案的位置，日誌組中檔案的個數由innodb_log_files_in_group確定，此位置設定預設為MySQL的datadir。

查詢：
線上配置：
配置檔案：innodb_log_group_home_dir = /Data/data

innodb_autoinc_lock_mode

參考

這個引數控制著在向有auto_increment 列的表插入資料時，相關鎖的行為。通過對它的設定可以達到效能與安全(主從的資料一致性)的平衡

insert大致上可以分成三類：
1、simple insert 如insert into t(name) values('test')
2、bulk insert 如load data | insert into ... select .... from ....
3、mixed insert 如insert into t(id,name) values(1,'a'),(null,'b'),(5,'c');

innodb_auto_lockmode有三個取值：
0 這個表示tradition 傳統
1 這個表示consecutive 連續
2 這個表示interleaved 交錯

tradition(innodb_autoinc_lock_mode=0) 模式:
1、它提供了一個向後相容的能力
2、在這一模式下，所有的insert語句("insert like") 都要在語句開始的時候得到一個表級的auto_inc鎖，在語句結束的時候才釋放這把鎖，注意呀，這裡說的是語句級而不是事務級的，一個事務可能包涵有一個或多個語句。
3、它能保證值分配的可預見性，與連續性，可重複性，這個也就保證了insert語句在複製到slave的時候還能生成和master那邊一樣的值(它保證了基於語句複製的安全)。
4、由於在這種模式下auto_inc鎖一直要保持到語句的結束，所以這個就影響到了併發的插入。

consecutive(innodb_autoinc_lock_mode=1) 模式:
1、這一模式下去simple insert 做了優化，由於simple insert一次性插入值的個數可以立馬得到確定，所以mysql可以一次生成幾個連續的值，用於這個insert語句；總的來說這個對複製也是安全的(它保證了基於語句複製的安全)
2、這一模式也是mysql的預設模式，這個模式的好處是auto_inc鎖不要一直保持到語句的結束，只要語句得到了相應的值後就可以提前釋放鎖

interleaved(innodb_autoinc_lock_mode=2) 模式：
1、由於這個模式下已經沒有了auto_inc鎖，所以這個模式下的效能是最好的；但是它也有一個問題，就是對於同一個語句來說它所得到的auto_incremant值可能不是連續的。

總結：
如果你的二進位制檔案格式是mixed | row 那麼這三個值中的任何一個對於你來說都是複製安全的。

由於現在mysql已經推薦把二進位制的格式設定成row，所以在binlog_format不是statement的情況下最好是innodb_autoinc_lock_mode=2 這樣可以得到更好的效能。

查詢：
線上配置：
配置檔案：innodb_autoinc_lock_mode = 2

innodb_buffer_pool_dump_at_shutdown

在之前的版本里，如果一臺高負荷的機器重啟後，記憶體中大量的熱資料被清空，此時就會重新從磁碟載入到Buffer_Pool緩衝池裡，這樣當高峰期間，效能就會變得很差，連線數就會很高。

在MySQL5.6裡，一個新特性避免的這種問題的出現。在關閉時把熱資料dump到本地磁碟。

查詢：
線上配置：
配置檔案：innodb_buffer_pool_dump_at_shutdown = 1

innodb_buffer_pool_load_at_startup

在啟動時把熱資料載入到記憶體。

查詢：
線上配置：
配置檔案：innodb_buffer_pool_load_at_startup = 1

innodb_file_per_table

可以修改InnoDB為獨立表空間模式，每個資料庫的每個表都會生成一個數據空間。

優點：
1．每個表都有自已獨立的表空間。
2．每個表的資料和索引都會存在自已的表空間中。
3．可以實現單表在不同的資料庫中移動。
4．空間可以回收（除drop table操作處，表空間不能自已回收）

缺點：
1．單表增加過大，如超過100個G。

結論：
共享表空間在Insert操作上少有優勢。其它都沒獨立表空間表現好。當啟用獨立表空間時，請合理調整一下：innodb_open_files 。

查詢：show variables like '%per_table%';
線上配置：
配置檔案：innodb_file_per_table=1

innodb_support_xa

設定為1，標誌支援分散式事物，主要保證binary log和其他引擎的主事務資料保持一致性，屬於同步操作；

如果你設定0，就是非同步操作，這樣就會一定程度上減少磁碟的重新整理次數和磁碟的競爭。

查詢：
線上配置：
配置檔案：innodb_support_xa = 0

innodb_status_file

開啟後，SHOW INNODB STATUS 的輸出每15秒鐘寫到一個狀態檔案。這個檔案的名字是innodb_status.pid，其中pid是伺服器程序ID。這個檔案在MySQL資料目錄裡建立。

正常關機之時，InnoDB刪除這個檔案。如果發生不正常的關機，這些狀態檔案的例項可能被展示，而且必須被手動刪除。在移除它們之前，你可能想要檢查它們來看它們是否包含有關不正常關機的原因的有用資訊。僅在配置選項innodb_status_file=1被設定之時，innodb_status.pid檔案被建立。

查詢：
線上配置：
配置檔案：innodb_status_file = 1

innodb_lock_wait_timeout

全域性等待事務鎖超時時間，在回滾(rooled back)之前，InnoDB事務將等待超時的時間(單位秒)

查詢：SHOW GLOBAL VARIABLES LIKE 'innodb_lock_wait_timeout';
線上配置：SET GLOBAL innodb_lock_wait_timeout=100;
配置檔案：innodb_lock_wait_timeout = 100

innodb_file_io_threads

此引數指定InnoDB表可用的檔案I／O執行緒數，MySQL開發人員建議在非Windows平臺中這個引數設定為4

查詢：
線上配置：
配置檔案：innodb_file_io_threads = 4

innodb_thread_concurrency

同一時刻能夠進入innodb層次併發執行的執行緒數(注意是併發不是並行)，如果超過CPU核數，某些執行緒可能處於就緒態而沒有獲得CPU時間輪片。

如果SERVER層的執行緒大於這個值，那多餘的執行緒將會被放到一個叫做wait queue的佇列中，而不能進入INNODB層次，進不到innodb層當然也就不能幹活了，談不上獲得CPU。

既然是一個佇列那麼它必然滿足先進入先出的原則。這也是前面說的長痛不如短痛，與其讓你不斷的進行上文切換還不如把你處於睡眠態放棄CPU使用權，預設這個值是0，代表不限制。

查詢：
線上配置：
配置檔案：innodb_thread_concurrency = 0

innodb_max_dirty_pages_pct

這個百分比是，最大髒頁的百分數，當系統中髒頁所佔百分比超過這個值，INNODB就會進行寫操作以把頁中的已更新資料寫入到磁碟檔案中。

這個髒頁百分比的閾值，在作業系統和其它資料庫中都有用到。主要是為了提高效率。比如當你的頁面中髒頁過多的時候，就呼叫磁碟IO把記憶體的“髒”資料寫回到磁碟。

髒頁小的話，無法將幾個改變一起flush到磁碟上去了。髒頁越大，可以拼湊在一起flush到磁碟上去。從而減少寫。

查詢：show variables like 'innodb_max_dirty_pages_pct';
線上配置：
配置檔案：innodb_max_dirty_pages_pct = 85

本文版權歸作者所有，歡迎轉載，請務必新增原文連結。