MySQL 5.7數據庫參數優化

鏈接相關參數

max_connections：容許客戶端併發鏈接的最大數量，默認值是151，通常將該參數設置爲500-2000

max_connect_errors：若是客戶端嘗試鏈接的錯誤數量超過這個參數設置的值，則服務器再也不接受新的客戶端鏈接。能夠經過清空主機的緩存來解除服務器的這種阻止新鏈接的狀態，經過FLUSH HOSTS或mysqladmin flush-hosts命令來清空緩存。這個參數的默認值是100，通常將該參數設置爲100000。

interactive_timeout：Mysql關閉交互鏈接前的等待時間，單位是秒，默認是8小時，建議不要將該參數設置超過24小時，即86400

wait_timeout：Mysql關閉非交互鏈接前的等待時間，單位是秒，默認是8小時，建議不要將該參數設置超過24小時，即86400

max_allowed_packet = 4M

接受的數據包大小；增長該變量的值十分安全，這是由於僅當須要時纔會分配額外內存。例如，僅當你發出長查詢或MySQLd必須返回大的結果行時MySQLd纔會分配更多內存。該變量之因此取較小默認值是一種預防措施，以捕獲客戶端和服務器之間的錯誤信息包，並確保不會因偶然使用大的信息包而致使內存溢出。

max_allowed_packet：網絡傳輸時單個數據包的大小。默認值是4MB。包信息緩存的初始值是net_buffer_length指定的，可是包可能會增加到max_allowed_packet參數設置的值。若是要使用BLOB字段或長字符串，須要增長這個參數的值。這個參數的值須要設置成和最大的BLOB字段同樣的大小。max_allowed_packet參數的協議限制是1GB。這個參數應該是1024整數倍。

max_heap_table_size = 8M
定義了用戶能夠建立的內存表(memory table)的大小。這個值用來計算內存表的最大行數值。這個變量支持動態改變

max_heap_table_size：這個參數設置用戶建立的MEMORY表容許增加的最大容量，這個參數用來MEMORY表的MAX_ROWS值。設置這個參數對已有的MEMORY表沒有影響，除非表重建或執行ALTER TABLE、TRUNCATE TABLE語句

tmp_table_size = 16M
MySQL的heap（堆積）表緩衝大小。全部聯合在一個DML指令內完成，而且大多數聯合甚至能夠不用臨時表便可以完成。大多數臨時表是基於內存的(HEAP)表。具備大的記錄長度的臨時表 (全部列的長度的和)或包含BLOB列的表存儲在硬盤上。
若是某個內部heap（堆積）表大小超過tmp_table_size，MySQL能夠根據須要自動將內存中的heap表改成基於硬盤的MyISAM表。還能夠經過設置tmp_table_size選項來增長臨時表的大小。也就是說，若是調高該值，MySQL同時將增長heap表的大小，可達到提升聯接查詢速度的效果。

skip-external-locking：當外部鎖定（external-locking）起做用時，每一個進程若要訪問數據表，則必須等待以前的進程完成操做並解除鎖定。因爲服務器訪問數據表時常常須要等待解鎖，所以在單服務器環境下external locking會讓MySQL性能降低。因此在不少Linux發行版的源中，MySQL配置文件中默認使用了skip-external-locking來避免external locking。當使用了skip-external-locking後，爲了使用MyISAMChk檢查數據庫或者修復、優化表，你必須保證在此過程當中MySQL服務器沒有使用須要操做的表。若是沒有中止服務器，也至少須要先運行

若是是多服務器環境，但願打開external locking特徵，則註釋掉這一行便可

# skip-external-locking    

若是是單服務器環境，則將其禁用便可，使用以下語句

skip-external-locking    

skip_name_resolve：若是這個參數設爲OFF，則MySQL服務在檢查客戶端鏈接的時候會解析主機名；若是這個參數設爲ON，則MySQL服務只會使用IP，在這種狀況下，受權表中的Host字段必須是IP地址或localhost。這個參數默認是關閉的

back_log：MySQL服務器鏈接請求隊列所能處理的最大鏈接請求數，若是隊列放滿了，後續的鏈接纔會拒絕。當主要的MySQL線程在很短期內獲取大量鏈接請求時，這個參數會生效。接下來，MySQL主線程會花費很短的時間去檢查鏈接，而後開啓新的線程。這個參數指定了MySQL的TCP/IP監聽隊列的大小。若是MySQL服務器在短期內有大量的鏈接，能夠增長這個參數。
文件相關參數sync_binlog：控制二進制日誌被同步到磁盤前二進制日誌提交組的數量。當這個參數爲0的時候，二進制日誌不會被同步到磁盤；當這個參數設爲0以上的數值時，就會有設置該數值的二進制提交組按期同步日誌到磁盤。當這個參數設爲1的時候，全部事務在提交前會被同步到二進制日誌中，於是即便MySQL服務器發生意外重啓，任何二進制日誌中沒有的事務只會處於準備狀態，這會致使MySQL服務器自動恢復以回滾這些事務。這樣就會保證二進制日誌不會丟失事務，是最安全的選項；同時因爲增長了磁盤寫，這對性能有必定下降。將這個參數設爲1以上的數值會提升數據庫的性能，但同時會伴隨數據丟失的風險。建議將該參數設爲二、四、六、八、16。

expire_logs_days：二進制日誌自動刪掉的時間間隔。默認值爲0，表明不會自動刪除二進制日誌。想手動刪除二進制日誌，能夠執行 PURGE BINARY LOGS。

max_binlog_size：二進制日誌文件的最大容量，當寫入的二進制日誌超過這個值的時候，會完成當前二進制的寫入，向新的二進制日誌寫入日誌。這個參數最小值時4096字節；最大值和默認值時1GB。相同事務中的語句都會寫入同一個二進制日誌，當一個事務很大時，二進制日誌實際的大小會超過max_binlog_size參數設置的值。若是max_relay_log_size參數設爲0，則max_relay_log_size參數會使用和max_binlog_size參數一樣的大小。建議將此參數設爲512M。

local_infile：是否容許客戶端使用LOAD DATA INFILE語句。若是這個參數沒有開啓，客戶端不能在LOAD DATA語句中使用LOCAL參數。

open_files_limit：操做系統容許MySQL服務打開的文件數量。這個參數實際的值以系統啓動時設定的值、max_connections和table_open_cache爲基礎，使用下列的規則：

1. 10 + max_connections + (table_open_cache * 2)

2.  max_connections * 5

3. MySQL啓動時指定open_files_limit的值

緩存控制參數binlog_cache_size：在事務中二進制日誌使用的緩存大小。若是MySQL服務器支持全部的存儲引擎且啓用二進制日誌，每一個客戶端都會被分配一個二進制日誌緩存。若是數據庫中有不少大的事務，增大這個緩存能夠得到更好的性能。
Binlog_cache_use和Binlog_cache_disk_use這兩個參數對於binlog_cache_size參數的優化頗有用。binlog_cache_size參數只設置事務所使用的緩存，非事務SQL語句所使用的緩存由binlog_stmt_cache_size系統參數控制。建議不要將這個參數設爲超過64MB，以防止客戶端鏈接多而影響MySQL服務的性能。

max_binlog_cache_size：若是一個事務須要的內存超過這個參數，服務器會報錯"Multi-statement transaction required more than 'max_binlog_cache_size' bytes"。這個參數最大的推薦值是4GB，這是由於MySQL不能在二進制日誌設爲超過4GB的狀況下正常的工做。建議將該參數設爲binlog_cache_size*2。

binlog_stmt_cache_size：這個參數決定二進制日誌處理非事務性語句的緩存。若是MySQL服務支持任何事務性的存儲引擎且開啓了二進制日誌，每一個客戶端鏈接都會被分配二進制日誌事務和語句緩存。若是數據庫中常常運行大的事務，增長這個緩存能夠得到更好的性能。

table_open_cache：全部線程能打開的表的數量。
MySQL每打開一個表，都會讀入一些數據到table_open_cache緩存中，當MySQL在這個緩存中找不到相應信息時，纔會去磁盤上讀取。默認值64。假定系統有200個併發鏈接，則需將此參數設置爲200*N(N爲每一個鏈接所需的文件描述符數目)；當把table_open_cache設置爲很大時，若是系統處理不了那麼多文件描述符，那麼就會出現客戶端失效，鏈接不上。

thread_cache_size：MySQL服務緩存以重用的線程數。當客戶端斷開鏈接的時候，若是線程緩存沒有使用滿，則客戶端的線程被放入緩存中。若是有客戶端斷開鏈接後再次鏈接到MySQL服務且線程在緩存中，則MySQL服務會優先使用緩存中的線程；若是線程緩存沒有這些線程，則MySQL服務器會建立新的線程。若是數據庫有不少的新鏈接，能夠增長這個參數來提高性能。若是MySQL服務器每秒有上百個鏈接，能夠增大thread_cache_size參數來使MySQL服務器使用緩存的線程。經過檢查Connections和Threads_created狀態參數，能夠判斷線程緩存是否足夠。這個參數默認的值是由下面的公式來決定的：8 + (max_connections / 100)

建議將此參數設置爲300~500。線程緩存的命中率計算公式爲(1-thread_created/connections)*100%，能夠經過這個公式來優化和調整thread_cache_size參數。
query_cache_size：爲查詢結果所分配的緩存。默認這個參數是沒有開啓的。這個參數的值應設爲整數的1024倍，若是設爲其餘值則會被自動調整爲接近此數值的1024倍。這個參數最小須要40KB。建議不要將此參數設爲大於256MB，以避免佔用太多的系統內存。

query_cache_min_res_unit：查詢緩存所分配的最小塊的大小。默認值是4096(4KB)。

query_cache_limit = 2M指定單個查詢可以使用的緩衝區大小，默認1M

query_cache_type：設置查詢緩存的類型。當這個參數爲0或OFF時，則MySQL服務器不會啓用查詢緩存；當這個參數爲1或ON時，則MySQL服務器會緩存全部查詢結果（除了帶有SELECT SQL_NO_CACHE的語句）；當這個參數爲2或DEMAND時，則MySQL服務器只會緩存帶有SELECT SQL_CACHE的語句。

sort_buffer_size：每一個會話執行排序操做所分配的內存大小。想要增大max_sort_length參數，須要增大sort_buffer_size參數。若是在SHOW GLOBAL STATUS輸出結果中看到每秒輸出的Sort_merge_passes狀態參數很大，能夠考慮增大sort_buffer_size這個值來提升ORDER BY 和 GROUP BY的處理速度。建議設置爲1~4MB。當個別會話須要執行大的排序操做時，在會話級別增大這個參數。

read_buffer_size：爲每一個線程對MyISAm表執行順序讀所分配的內存。若是數據庫有不少順序讀，能夠增長這個參數，默認值是131072字節。這個參數的值須要是4KB的整數倍。這個參數也用在下面場景中：

• 當執行ORDER BY操做時，緩存索引到臨時文件（不是臨時表）中；

• 執行批量插入到分區表中；

• 緩存嵌套查詢的執行結果。

read_rnd_buffer_size：這個參數用在MyISAM表和任何存儲引擎表隨機讀所使用的內存。當從MyISAM表中以鍵排序讀取數據的時候，掃描的行將使用這個緩存以免磁盤的掃描。將這個值設到一個較大的值能夠顯著提高ORDER BY的性能。而後，這個參數會應用到全部的客戶端鏈接，全部不該該將這個參數在全局級別設爲一個較大的值；在運行大查詢的會話中，在會話級別增大這個參數便可。

join_buffer_size：MySQL服務器用來做普通索引掃描、範圍索引掃描和不使用索引而執行全表掃描這些操做所用的緩存大小。一般，獲取最快鏈接的方法是增長索引。當不能增長索引的時候，使全鏈接變快的方法是增大join_buffer_size參數。對於執行全鏈接的兩張表，每張表都被分配一塊鏈接內存。對於沒有使用索引的多表複雜鏈接，須要多塊鏈接內存。一般來講，能夠將此參數在全局上設置一個較小的值，而在須要執行大鏈接的會話中在會話級別進行設置。默認值是256KB。

net_buffer_length：每一個客戶端線程和鏈接緩存和結果緩存交互，每一個緩存最初都被分配大小爲net_buffer_length的容量，並動態增加，直至達到max_allowed_packet參數的大小。當每條SQL語句執行完畢後，結果緩存會縮小到net_buffer_length大小。不建議更改這個參數，除非你的系統有不多的內存，能夠調整這個參數。若是語句須要的內存超過了這個參數的大小，則鏈接緩存會自動增大。net_buffer_length參數最大能夠設置到1MB。不能在會話級別設置這個參數。
thread_cache_size = 8
# 這個值（默認8）表示能夠從新利用保存在緩存中線程的數量，當斷開鏈接時若是緩存中還有空間，那麼客戶端的線程將被放到緩存中，
# 若是線程從新被請求，那麼請求將從緩存中讀取,若是緩存中是空的或者是新的請求，那麼這個線程將被從新建立,若是有不少新的線程，
# 增長這個值能夠改善系統性能.經過比較Connections和Threads_created狀態的變量，能夠看到這個變量的做用。(–>表示要調整的值)
# 根據物理內存設置規則以下：
# 1G  —> 8
# 2G  —> 16
# 3G  —> 32
# 大於3G  —> 64

bulk_insert_buffer_size：MyISAM表使用一種特殊的樹狀緩存來提升批量插入的速度，如INSERT ... SELECT,INSERT ... VALUES (...),(...), ...,對空表執行執行LOAD DATA INFILE。這個參數每一個線程的樹狀緩存大小。將這個參數設爲0會關閉這個參數。這個參數的默認值是8MB。


這個參數也和tmp_table_size參數一塊兒來如今內部in-memory表的大小。若是內存表使用頻繁，能夠增大這個參數的值。

tmp_table_size：內部內存臨時表的最大內存。這個參數不會應用到用戶建立的MEMORY表。若是內存臨時表的大小超過了這個參數的值，則MySQL會自動將超出的部分轉化爲磁盤上的臨時表。在MySQL 5.7.5版本，internal_tmp_disk_storage_engine存儲引擎將做爲磁盤臨時表的默認引擎。在MySQL 5.7.5以前的版本，會使用MyISAM存儲引擎。若是有不少的GROUP BY查詢且系統內存充裕，能夠考慮增大這個參數。

innodb_buffer_pool_dump_at_shutdown：指定在MySQL服務關閉時，是否記錄InnoDB緩存池中的緩存頁，以縮短下次重啓時的預熱過程。一般和innodb_buffer_pool_load_at_startup參數搭配使用。innodb_buffer_pool_dump_pct參數定義了保留的最近使用緩存頁的百分比。

innodb_buffer_pool_dump_now：馬上記錄InnoDB緩衝池中的緩存頁。一般和innodb_buffer_pool_load_now搭配使用。

innodb_buffer_pool_load_at_startup：指定MySQL服務在啓動時，InnoDB緩衝池經過加載以前的緩存頁數據來自動預熱。一般和innodb_buffer_pool_dump_at_shutdown參數搭配使用。

innodb_buffer_pool_load_now：馬上經過加載數據頁來預熱InnoDB緩衝池，無需重啓數據庫服務。能夠用來在性能測試時，將緩存改爲到一個已知的狀態；或在數據庫運行報表查詢或維護後，將數據庫改爲到一個正常的狀態。
MyISAM參數key_buffer_size：全部線程所共有的MyISAM表索引緩存，這塊緩存被索引塊使用。增大這個參數能夠增長索引的讀寫性能，在主要使用MyISAM存儲引擎的系統中，可設置這個參數爲機器總內存的25%。若是將這個參數設置很大，好比設爲機器總內存的50%以上，機器會開始page且變得異常緩慢。能夠經過SHOW STATUS 語句查看 Key_read_requests,Key_reads,Key_write_requests, and Key_writes這些狀態值。正常狀況下Key_reads/Key_read_requests 比率應該小於0.01。數據庫更新和刪除操做頻繁的時候，Key_writes/Key_write_requests 比率應該接近1。
key_buffer_size = 4M
#指定用於索引的緩衝區大小，增長它可獲得更好處理的索引(對全部讀和多重寫)，到你能負擔得起那樣多。若是你使它太大，
# 系統將開始換頁而且真的變慢了。對於內存在4GB左右的服務器該參數可設置爲384M或512M。經過檢查狀態值Key_read_requests和Key_reads，
# 能夠知道key_buffer_size設置是否合理。比例key_reads/key_read_requests應該儘量的低，
# 至少是1:100，1:1000更好(上述狀態值可使用SHOW STATUS LIKE 'key_read%'得到)。注意：該參數值設置的過大反而會是服務器總體效率下降

key_cache_block_size：key緩存的塊大小，默認值是1024字節。

myisam_sort_buffer_size：在REPAIR TABLE、CREATE INDEX 或 ALTER TABLE操做中，MyISAM索引排序使用的緩存大小。

myisam_max_sort_file_size：當重建MyISAM索引的時候，例如執行REPAIR TABLE、 ALTER TABLE、 或 LOAD DATA INFILE命令，MySQL容許使用的臨時文件的最大容量。若是MyISAM索引文件超過了這個值且磁盤還有充裕的空間，增大這個參數有助於提升性能。

myisam_repair_threads：若是這個參數的值大於1，則MyISAM表在執行Repair操做的排序過程當中，在建立索引的時候會啓用並行，默認值爲1。
InnoDB參數innodb_buffer_pool_size：InnDB存儲引擎緩存表和索引數據所使用的內存大小。默認值是128MB。在以InnDB存儲引擎爲主的系統中，能夠將這個參數設爲機器物理內存的80%。同時須要注意：

• 設置較大物理內存時是否會引擎頁的交換而致使性能降低；

• InnoDB存儲引擎會爲緩存和控制表結構信息使用部份內存，於是實際花費的內存會比設置的值大於10%；

• 這個參數設置的越大，初始化內存池的時間越長。在MySQL 5.7.5版本，能夠以chunk爲單位增長或減小內存池的大小。chunk的大小能夠經過innodb_buffer_pool_chunk_size參數設定，默認值是128MB。內存池的大小能夠等於或是innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances的整數倍。

innodb_buffer_pool_instances：InnoDB緩存池被分紅的區域數。對於1GB以上大的InnoDB緩存，將緩存分紅多個部分能夠提升MySQL服務的併發性，減小不一樣線程讀緩存頁的讀寫競爭。每一個緩存池有它單獨的空閒列表、刷新列表、LRU列表和其餘鏈接到內存池的數據結構，它們被mutex鎖保護。這個參數只有將innodb_buffer_pool_size參數設爲1GB或以上時才生效。建議將每一個分紅的內存區域設爲1GB大小。

innodb_max_dirty_pages_pct：當Innodb緩存池中髒頁所佔的百分比達到這個參數的值時，InnoDB會從緩存中向磁盤寫入數據。默認值是75。
innodb_thread_concurrency：InnoDB存儲引擎能夠併發使用的最大線程數。當InnoDB使用的線程超過這參數的值時，後面的線程會進入等待狀態，以先進先出的算法來處理。等待鎖的線程不計入這個參數的值。這個參數的範圍是0~1000。默認值是0。當這個參數爲0時，表明InnoDB線程的併發數沒有限制，這樣會致使MySQL建立它所須要的儘量多的線程。設置這個參數能夠參考下面規則：

• 若是用戶線程的併發數小於64，能夠將這個參數設爲0；

• 若是系統併發很嚴重，能夠先將這個參數設爲128，而後再逐漸將這個參數減少到96, 80, 64或其餘數值，直到找到性能較好的一個數值。

innodb_flush_method：指定刷新數據到InnoDB數據文件和日誌文件的方法，刷新方法會對I/O有影響。若是這個參數的值爲空，在類Unix系統上，這個參數的默認值爲fsync；在Windows系統上，這個參數的默認值爲async_unbuffered。在類Unix系統上，這個參數可設置的值以下：

• fsync:InnoDB使用fsync()系統函數來刷新數據和日誌文件，fsync是默認參數。

• O_DSYNC:InnoDB使用O_SYNC函數來打開和刷新日誌文件，使用fsync()函數刷新數據文件

• littlesync:這個選項用在內部性能的測試，目前MySQL尚不支持，使用這個參數又必定的風險

• nosync:這個選項用在內部性能的測試，目前MySQL尚不支持，使用這個參數又必定的風險

• O_DIRECT:InnoDB使用O_DIRECT（或者directio()在Solaris）函數打開數據文件，使用fsync()刷新數據文件和日誌文件

• O_DIRECT_NO_FSYNC:在刷新I/O時，InnoDB使用O_DIRECT方式。

在有RAID卡和寫緩存的系統中，O_DIRECT有助於避免InnoDB緩存池和操做系統緩存之間的雙重緩存。在InnoDB數據和日誌文件放在SAN存儲上面的系統，默認值或O_DSYNC方法會對以讀爲主的數據庫起到加速做用。
innodb_data_home_dir：InnoDB系統表空間所使用的數據文件的物理路徑，默認路徑是MySQL數據文件路徑。若是這個參數的值爲空，能夠在innodb_data_file_path參數裏使用絕對路徑

innodb_data_file_path：InnoDB數據文件的路徑和大小。

innodb_file_per_table：當這個參數啓用的時候，InnoDB會將新建表的數據和索引單獨存放在.ibd格式的文件中，而不是存放在系統表空間中。當這張表被刪除或TRUNCATE時，InnoDB表所佔用的存儲會被釋放。這個設定會開啓InnoDB的一些其餘特性，好比表的壓縮。當這個參數關閉的時候，InnoDB會將表和索引的數據存放到系統表空間的ibdata文件中，這會有一個問題，由於系統表空間不會縮小，這樣設置會致使空間沒法回放。

innodb_undo_directory：InnoDB undo日誌所在表空間的物理路徑。和innodb_undo_logs、innodb_undo_tablespaces參數配合，來設置undo日誌的路徑，默認路徑是數據文件路徑。

innodb_undo_logs：指定InnoDB使用的undo日誌的個數。在MySQL 5.7.2版本，32個undo日誌被臨時表預留使用，而且這些日誌存放在臨時表表空間(ibtmp1)中。若是undo日誌只存放在系統表空間中，想要額外分配供數據修改事務用的undo日誌，innodb_undo_logs參數必須設置爲32以上的整數。若是你配置了單獨的undo表空間，要將innodb_undo_logs參數設爲33以上來分配額外供數據修改事務使用的undo日誌。每一個undo日誌最多能夠支持1024個事務。若是這個參數沒有設置，則它會設爲默認值128。

innodb_undo_tablespaces：undo日誌的表空間文件數量。默認，全部的undo日誌都是系統表空間的一部分。由於在運行大的事務時，undo日誌會增大，將undo日誌設置在多個表空間中能夠減小一個表空間的大小。undo表空間文件建立在innodb_undo_directory參數指定的路徑下，以undoN格式命名，N是以0開頭的一系列整數。undo表空間的默認大小爲10M。須要在初始化InnoDB前設置innodb_undo_tablespaces這個參數。在MySQL 5.7.2版本，在128個undo日誌中，有32個undo日誌是爲臨時表所預留的，有95個undo日誌供undo表空間使用。

innodb_log_files_in_group：InnoDB日誌組包含的日誌個數。InnoDB以循環的方式寫入日誌。這個參數的默認值和推薦值均是2。日誌的路徑由innodb_log_group_home_dir參數設定。

innodb_log_group_home_dir：InnoDB重作日誌文件的物理路徑，重作日誌的數量由innodb_log_files_in_group參數指定。若是不指定任何InnoDB日誌參數，MySQL默認會在MySQL數據文件路徑下面建立兩個名爲ib_logfile0、ib_logfile1的兩個重作日誌文件，它們的大小由innodb_log_file_size參數設定。

innodb_log_file_size：日誌組中每一個日誌文件的字節大小。全部日誌文件的大小(innodb_log_file_size * innodb_log_files_in_group)不能超過512GB。

innodb_log_buffer_size：InnoDB寫入磁盤日誌文件所使用的緩存字節大小。若是innodb_page_size參數爲32K，則默認值是8MB；若是innodb_page_size參數爲64K，則默認值是16MB。若是日誌的緩存設置較大，則MySQL在處理大事務時，在提交事務前無需向磁盤寫入日誌文件。建議設置此參數爲4~8MB。

innodb_flush_log_at_trx_commit：當提交相關的I/O操做被批量從新排列時，這個參數控制提交操做的ACID一致性和高性能之間的平衡。能夠改變這個參數的默認值來提高數據庫的性能，可是在數據庫宕機的時候會丟失少許的事務。這個參數的默認值爲1，表明數據庫遵守完整的ACID模型，每當事務提交時，InnoDB日誌緩存中的內容均會被刷新到日誌文件，並寫入到磁盤。當這個參數爲0時，InnDB日誌緩存大概每秒刷新一第二天志文件到磁盤。當事務提交時，日誌緩存不會馬上寫入日誌文件，這樣的機制不會100%保證每秒都向日誌文件刷新日誌，當mysqld進程宕掉的時候可能會丟失持續時間爲1秒左右的事務數據。當這個參數爲2時，當事務提交後，InnoDB日誌緩存中的內容會寫入到日誌文件且日誌文件，日誌文件以大概每秒一次的頻率刷新到磁盤。在MySQL 5.6.6版本，InnoDB日誌刷新頻率由innodb_flush_log_at_timeout參數決定。一般將個參數設爲1。

innodb_flush_log_at_timeout：寫入或刷新日誌的時間間隔。這個參數是在MySQL 5.6.6版本引入的。在MySQL 5.6.6版本以前，刷新的頻率是每秒刷新一次。innodb_flush_log_at_timeout參數的默認值也是1秒刷新一次。

innodb_lock_wait_timeout：InnDB事務等待行鎖的時間長度。默認值是50秒。當一個事務鎖定了一行，這時另一個事務想訪問並修改這一行，當等待時間達到innodb_lock_wait_timeout參數設置的值時，MySQL會報錯"ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction"，同時會回滾語句（不是回滾整個事務）。若是想回滾整個事務，須要使用--innodb_rollback_on_timeout參數啓動MySQL。在高交互性的應用系統或OLTP系統上，能夠減少這個參數來快速顯示用戶的反饋或把更新放入隊列稍後處理。在數據倉庫中，爲了更好的處理運行時間長的操做，能夠增大這個參數。這個參數只應用在InnoDB行鎖上，這個參數對錶級鎖無效。這個參數不適用於死鎖，由於發生死鎖時，InnoDB會馬上檢測到死鎖並將發生死鎖的一個事務回退。

innodb_fast_shutdown：InnoDB關庫模式。若是這個參數爲0，InnoDB會作一個緩慢關機，在關機前會作完整的刷新操做，這個級別的關庫操做會持續數分鐘，當緩存中的數據量很大時，甚至會持續幾個小時；若是數據庫要執行版本升級或降級，須要執行這個級別的關庫操做，以保證全部的數據變動都寫入到數據文件。若是這個參數的值是1（默認值），爲了節省關庫時間，InnoDB會跳過新操做，而是在下一次開機的時候經過crash recovery方式執行刷新操做。若是這個參數的值是2，InnoDB會刷新日誌並以冷方式關庫，就像MySQL宕機同樣，沒有提交的事務會丟失，在下一次開啓數據庫時，crash recovery所須要的時間更長；在緊急或排錯情形下，須要馬上關閉數據庫時，會使用這種方式停庫。

本文出自http://www.cnblogs.com/erisen/p/6068265.html