摘要：
繼上一篇的文章 初識 MySQL 5.5 新功能、參數 之后，現在MySQL5.6 針對 MySQL5.5 各個方面又提升了很多，特別在性能和一些新參數上面，現在看看大致提升了哪些方面（后續不定時更新）。
一：性能、功能上的提升。
① 在線DDL即 online DDL，日常的增刪字段和索引都不會出現問題，但還是有很多操作不支持完全的在線DDL，包括增加一個全文索引，修改列的數據類型，刪除一個主鍵，修改表的字符集等，其中主鍵可以通過自己指定的方式進行操作，操作方式有2種：algorithm=inplace|copy 。也可以看官方的例子
dba@192.168.200.59 : dchat_main 05:44:54>alter table messages_tt add primary key(m_id),algorithm=inplace; Query OK, 0 rows affected (26.59 sec) Records: 0 Duplicates: 0 Warnings: 0 dba@192.168.200.59 : dchat_main 05:45:53>alter table messages_tt drop primary key; Query OK, 684076 rows affected (16.46 sec) Records: 684076 Duplicates: 0 Warnings: 0 dba@192.168.200.59 : dchat_main 05:46:20>alter table messages_tt add primary key(m_id),algorithm=copy; Query OK, 684076 rows affected (17.54 sec) Records: 684076 Duplicates: 0 Warnings: 0 dba@192.168.200.59 : dchat_main 05:46:48>alter table messages_tt drop primary key; Query OK, 684076 rows affected (16.73 sec) Records: 684076 Duplicates: 0 Warnings: 0 dba@192.168.200.59 : dchat_main 05:48:19>alter table messages_tt add primary key(m_id);默認，和第一次inplace效果一樣 Query OK, 0 rows affected (26.31 sec) Records: 0 Duplicates: 0 Warnings: 0
下面是MySQL官方的測試例子：
mysql> CREATE TABLE add_pk_via_inplace (c1 INT, c2 VARCHAR(10), c3 DATETIME); Query OK, 0 rows affected (0.02 sec) mysql> INSERT INTO add_pk_via_inplace VALUES (1,'a','2014-11-03 11:01:37'),(NULL,NULL,NULL); Query OK, 2 rows affected (0.00 sec) Records: 2 Duplicates: 0 Warnings: 0 mysql> SELECT * FROM add_pk_via_inplace; +------+------+---------------------+ | c1 | c2 | c3 | +------+------+---------------------+ | 1 | a | 2014-11-03 11:01:37 | | NULL | NULL | NULL | +------+------+---------------------+ 2 rows in set (0.00 sec) mysql> SET sql_mode = ''; Query OK, 0 rows affected (0.00 sec) mysql> ALTER TABLE add_pk_via_inplace ADD PRIMARY KEY (c1,c2,c3), ALGORITHM=INPLACE; ERROR 1846 (0A000): ALGORITHM=INPLACE is not supported. Reason: cannot silently convert NULL values, as required in this SQL_MODE. Try ALGORITHM=COPY. mysql> SET sql_mode ='strict_trans_tables'; Query OK, 0 rows affected (0.00 sec) mysql> ALTER TABLE add_pk_via_inplace ADD PRIMARY KEY (c1,c2,c3), ALGORITHM=INPLACE; ERROR 1138 (22004): Invalid use of NULL value mysql> DELETE FROM add_pk_via_inplace WHERE c1 IS NULL OR c2 IS NULL OR c3 IS NULL; Query OK, 1 row affected (0.01 sec) mysql> SELECT * FROM add_pk_via_inplace; +------+------+---------------------+ | c1 | c2 | c3 | +------+------+---------------------+ | 1 | a | 2014-11-03 11:01:37 | +------+------+---------------------+ 1 row in set (0.00 sec) mysql> ALTER TABLE add_pk_via_inplace ADD PRIMARY KEY (c1,c2,c3), ALGORITHM=INPLACE; Query OK, 0 rows affected (0.09 sec) Records: 0 Duplicates: 0 Warnings: 0
從自己的例子看出，在處理主鍵時，沒有指定ALGORITHM子句，MySQL會自動選擇任意算法（如果都支持，則ALGORITHM=INPLACE優先）。所以在執行的時候可以不用顯性的加上"algorithm"。
在官方的例子看出，對於主鍵列為null時，alter table … add primary key 只在sql_mode 包含srict_trans_table 或strict_all_tables標志下才支持ALGORITHM=INPLACE，否則,強制指定ALGORITHM=INPLACE，會出現錯誤信息：
ERROR 1846 (0A000): ALGORITHM=INPLACE is not supported. Reason: cannot silently convert NULL values, as required in this SQL_MODE. Try ALGORITHM=COPY.
若不指ALGORITHM=INPLACE，會復制表，並且把null 改成not null。
當主鍵列為not null的時候則一切正常。
注意：采用algorithm=inplace新建主鍵，雖然避免表的復制，但數據需要重新進行重組的。ALGORITHM=copy則把表拷貝到臨時表，然后把臨時表的數據插入到新表。
對於alter table … drop primary key 只能采用ALGORITHM=copy，如果強制采用ALGORITHM=inplace會出現錯誤。
總之，在DDL發起和完成之前（altering table 階段），允許在這期間DML、查詢的並發。但DDL在完成時，還是需要獲取表的元數據鎖(MDL)。因為online DDL在 preparing for alter table和committing alter table to storage engine這兩個階段需要獲取表的排斥鎖（時間比較短）。
原理，5.6是通過怎么樣的方法來做到online ddl 的呢？在5.6之前我們進行online ddl是需要通過percona tool創建的觸發器實現。這里有個參數：
innodb_online_alter_log_max_size：
該參數是MySQL5.6.6新加入的一個參數，用以指定對InnoDB表做在線DDL操作時所使用的臨時日志文件的最大大小（以字節為單位，默認128M）。在創建索引或者ALTER表時會使用該臨時文件。該日志文件記錄了DDL操作期間插入、更新、刪除的數據。每次擴展innodb_sort_buffer_size的大小直至達到innodb_online_alter_log_max_size指定的最大值。若日志的大小超出此上限則ALTER表的操作會失敗，當前所有未提交的DML操作會回滾。但如果日志文件太大會可能會導致DDL操作最后鎖定表(Waiting for table metadata lock)的時間更長（鎖定表，應用日志到表上）。
② Purge Thread：回收UNDO。
通過參數innodb_purge_threads來開啟，5.5之后的參數，從Master Thread獨立出來，回收無用的UNDO頁。在MySQL 5.5之前是在Master Thread中完成的。5.5之后，獨立到了單獨的線程中完成，減輕了Master Thread線程的工作。提升CPU的使用率和存儲引擎的性能。在5.5中只能也只有1可以設置。5.6可以設置大於1。另一個參數：innodb_purge_batch_size 來控制每次回收UNDO頁的數量，在5.5之前默認是20（寫死），5.5之后可以根據情況調整該參數，默認300。
③ Page Clean Thread：刷寫臟頁。
臟頁的刷寫線程。5.6里開始支持從Master Thread里面獨立出來。減輕了Master Thread 的工作，和對用戶查詢的阻塞。進一步提高Innodb 存儲引擎的性能和並發。5.7可以設置多個線程來刷寫臟頁。
④ 插入緩沖（Insert Buffer/Change Buffer）：提升插入性能。
InnoDB為了避免更新數據時更新索引損失太多性能，使用了這種稱為Insert Buffer的方法來緩沖索引更新。關於插入緩沖的概念可以查找資料，也可以看這里。原先插入緩沖最大使用空間為1/2的緩沖池大小，5.6之后可以控制插入緩沖的大小了，通過參數：innodb_change_buffer_max_size，默認是BP的1/4。
⑤ 刷新鄰接頁：刷寫一個臟頁時，會檢測該頁所在的區（extent：64頁，1M）的其他頁是否也有臟頁，有則一起刷寫。5.6通過參數：innodb_flush_neighbors 參數控制。機械磁盤建議開啟，固態硬盤建議設置為0，即關閉。
⑥ 復制方面的提升：包括GTID、binlog的記錄(基於行的復制)、延遲復制、多線程復制、遠程備份binlog等。
⑦ 數據庫預熱的提升：從之前讀表的預熱升級到buffer pool的預熱。
⑧ 優化器的增強：包括ICP、MRR、BAK等。
⑨ InnoDB全文檢索的支持：InnoDB對fulltext的支持，提高了MySQL的並發性。
⑩ 死鎖檢測增強：5.6 中引入參數innodb_print_all_deadlocks,這個參數是全局設置的, 可以把所有的死鎖狀況打印到error日志中。
⑪ Undo Log 從系統表空間分離。innodb_undo_directory、innodb_undo_tablespaces、inodb_undo_logs。
⑫ Explain的增強。可以對insert、update、delete 進行explain。
⑬ 優化器跟蹤。set optimizer_trace='enabled=on'開后，執行sql，再通過select * from information_schema.optimizer_trace\G; 查看。
⑭ Innodb_page_size的增強。可以自行的修改頁大小，在數據庫創建的時候就先設置好。
⑮ infomation_schema的增強。在information_schema中增加了一些統計表。
⑯ thread pool的增強。降低了數據庫連接的不必要開銷，提高了並發處理能力。
⑰ ...
寫這篇博文主要就是為了針對參數的說明和設置，現在我們來看看MySQL server 參數和Inndob參數的介紹。
二，新參數說明和設置，這里說下5.6比較重要的參數，以及5.5到5.6默認值有過變化的參數。
MySQL Server參數：
1，optimizer_switch：優化器選項。
Variable_name: optimizer_switch Value: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,engine_condition_pushdown=on,index_condition_pushdown=on,mrr=on,mrr_cost_based=on,block_nested_loop=on,batched_key_access=off,materialization=on,semijoin=on,loosescan=on,firstmatch=on,subquery_materialization_cost_based=on,use_index_extensions=on
關於優化器的改進可以參考下面這些文章：
ICP ：http://blog.itpub.net/22664653/viewspace-1678779/
MRR：http://blog.itpub.net/22664653/viewspace-1673682/
BKA：http://blog.itpub.net/22664653/viewspace-1715511/
BNL：http://blog.itpub.net/22664653/viewspace-1692317/
2，thread_handling(Thread pool)：線程調度方式相關參數，默認one-thread-per-connection。詳細說明可以看percona的官方文檔。
MySQL常用（目前線上使用）的線程調度方式是one-thread-per-connection（每連接一個線程），server為每一個連接創建一個線程來服務，連接斷開后，這個線程進入thread_cache或者直接退出（取決於thread_cache設置及系統當前已經cache的線程數目）。比較適合活躍的長連接的應用場景，而在大量短連接或者高並發情況下，one-thread-per-connection需要創建/調度大量的線程，產生較高的的context-switch代價，從而使得系統性能下降。Threadpool是提供一種線程代理的模型執行每個連接的語句。而MySQL內部維護一個可能接受的線程總數，減少線程太多在CPU切換等方面的壓力和開銷。通過thread_handling=pool-of-threads開啟thread pool功能：threadpool中worker線程處理單位為一個sql，而不是one-thread-per-connection對應的一個連接；當worker線程處理完A連接發送來的一個sql后，A連接沒有立刻發送第二條sql，worker線程會去服務其它連接發送來的sql，因此worker線程工作效率更高，系統需要的線程數也更少。啟用Thread Pool后，想要終止某個查詢的話，要這么寫KILL QUERY connection_id，而不是寫成 KILL connection_id，否則就會導致整個連接被KILL。
threadpool相關參數 root@(none) 05:33:27>show global variables like '%thread_pool%'; +-------------------------------+--------------+ | Variable_name | Value | +-------------------------------+--------------+ | thread_pool_high_prio_mode | transactions | | thread_pool_high_prio_tickets | 4294967295 | | thread_pool_idle_timeout | 60 | | thread_pool_max_threads | 100000 | | thread_pool_oversubscribe | 3 | | thread_pool_size | 24 | | thread_pool_stall_limit | 500 | +-------------------------------+--------------+ 7 rows in set (0.00 sec) thread_pool_high_prio_mode 有三個取值：transactions / statements / none transactions(default): 使用優先隊列和普通隊列，對於事務已經開啟的statement，放到優先隊列中，否則放到普通隊列中 statements：只使用優先隊列 none: 只是用普通隊列，本質上和statements相同，都是只是用一個隊列 thread_pool_high_prio_tickets 取值0~4294967295，當開啟了優先隊列模式后（thread_pool_high_prio_mode=transactions），每個連接最多允許thread_pool_high_prio_tickets次被放到優先隊列中，之后放到普通隊列中，默認為4294967295 thread_pool_idle_timeout worker線程最大空閑時間，單位為秒，超過限制后會退出，默認60 thread_pool_max_threads threadpool中最大線程數目，所有group中worker線程總數超過該限制后不能繼續創建更多線程，默認100000 thread_pool_oversubscribe 一個group中線程數過載限制，當一個group中線程數超過次限制后，繼續創建worker線程會被延遲，默認3 thread_pool_size threadpool中group數量，默認為cpu核心數，server啟動時自動計算 thread_pool_stall_limit timer線程檢測間隔，單位為毫秒，默認500
關於具體的信息可以參考下面的文章：
http://www.mysqlsupport.cn/percona-thread-pool/
http://www.gpfeng.com/?p=540&utm_source=tuicool&utm_medium=referral
http://imysql.cn/2014/07/02/percona-thread-pool-benchmark-testing.shtml
3，...
InnoDB 參數：
1，binlog_checksum：全局動態變量。5.6.2引入，5.6.5之前默認是NONE，5.6.6之后默認是CRC32。
開啟該參數，這個變量將導致主為每個二進制日志的事件進行寫校驗，提高了安全性。關閉該參數的時候，是通過二進制日志事件的長度來驗證的。需要注意的是：因為5.6.2之前沒有這個參數，要是主從版本不一致（M(5.6.6)，S(5.5.x)）會導致復制出錯，需要顯性的在高版本上添加：binlog_checksum=NONE；或則執行：set global binlog_checksum = none。
2，innodb_autoextend_increment：全局動態變量。5.6.6之后默認大小是64M，之前是8M。
該參數是在當共享表空間滿了的時候自動擴展的一個大小，如果表是獨享表空間（innodb_file_per_table），該變量不會影響其創建大小。
3，innodb_buffer_pool_instances：全局變量。 5.6.6之后默認改成了8，之前是1。
該參數來增加InnoDB_Buffer_Pool實例的個數（BP>1G），並使用哈希函數將讀取緩存的數據頁隨機分配到一個緩沖池里面。每個緩沖區實例分別管理着自己的free list、flush list和LRU。提升了buffer pool的利用率。要是單個InnoDB_Buffer_Pool緩沖池實例，當達到好幾十GB時，如果某個線程正在更新緩沖池，將會造成其他線程必須等待的瓶頸。
4，innodb_concurrency_tickets：全局動態變量。5.6.6之后默認5000，之前是500。
該參數意義是同一時刻，能訪問InnoDB引擎數據的線程數，當訪問InnoDB引擎數據的線程數達到設置的上線，線程將會被放到隊列中，等待其他線程釋放ticket。
5，innodb_old_blocks_time：全局動態變量。5.6.6之后默認是1000，之前是0。單位是毫秒。
該參數表示等到該時間后，再讀取該頁則會進入到new端，有效的避免了對於上述SQL對BP的污染。默認是0，單位是毫秒。如設置為1000則表示：讀到該頁到midpoint的位置，要再等1秒之后讀取該頁才能進入new列表。而0則表示讀取到該頁則會直接被放入到new列表。具體的可以看這里。和innodb_old_blocks_pct配合使用，該參數默認是37（3/8），即BP的3/8處。
6，innodb_stats_on_metadata:全局動態變量。5.6.6之后默認是OFF，之前是ON。
該參數的作用是查詢 information_schema 元數據庫里的表時，Innodb 還會隨機提取其他數據庫每個表索引頁的部分數據。當你的表很大,並且數量很多時,耗費的時間就會很長,很多不訪問的數據也會進入到Innodb_Buffer_Pool 緩沖池里,那么就會把緩沖池所污染。並且 ANALYZE TABLE和 SHOW TABLE STATUS 語句也會造成 Innodb 隨機提取數據。可以動態關閉 innodb_stats_on_metadata,默認是開啟的，建議關閉
7，innodb_adaptive_flushing_lwm:全局動態變量。5.6.6支持，默認值得10。
該參數表示redo log（ib_logfile）的一個最低容量限制百分比，默認為10，范圍是[0,70]。當沒有達到這個值時，page cleaner線程不會根據redo來判斷是否刷臟頁，超過則通過參數innodb_adaptive_flushing來刷寫。
8，innodb_buffer_pool_dump_at_shutdown：全局動態變量，默認關閉。
該參數表示當數據庫關閉時，是否把BP里的數據導出到文件里，建議開啟。如果一台高負荷的機器重啟后，buffer pool中的熱數據被丟失，此時就會重新從磁盤加載到Buffer_Pool緩沖池里，這樣當高峰期間，性能就會變得很差，連接數就會很高，應用的性能也受到影響
9，innodb_buffer_pool_dump_now：全局動態變量，默認關閉。
該參數表示采用手工方式把熱數據dump到本地磁盤文件。可以在數據庫運行時執行。
10，innodb_buffer_pool_filename：全局變量，默認：ib_buffer_pool
該參數控制BP導出的文件名。
11，innodb_buffer_pool_load_abort：全局動態變量，默認OFF。
該參數表示中止緩沖池加載操作。
12，innodb_buffer_pool_load_at_startup：全局變量，默認OFF。
該參數表示在數據庫啟動時，把dump出來的數據加載到內存，建議開啟。
13，innodb_buffer_pool_load_now：全局變量，默認OFF。
該參數表示在數據庫運行時，把dump出來的數據加載到內存。
14，innodb_change_buffer_max_size：全局動態變量，默認是25，單位百分比。
該參數表示InnoDB為了避免更新數據時更新索引損失太多性能，使用了這種稱為Insert Buffer的方法來緩沖索引更新。關於插入緩沖的概念可以查找資料，也可以看這里。原先插入緩沖最大使用空間為1/2的緩沖池大小，5.6之后可以控制插入緩沖的大小了，默認是BP的1/4。
15，innodb_disable_sort_file_cache：全局動態變量，默認OFF。
該參數開啟表示操作系統不對merge-sort的臨時文件cache，使用O_DIRECT。
16，innodb_flush_log_at_timeout：全局動態變量，默認1，范圍是1～2700。
該參數表示自定義刷新日志時間，每隔這么多秒刷一次日志，只有在innodb_flush_log_at_trx_commit=2時才生效。大致的原因是：
1.INNODB REDO日志：InnoDB為了保證日志的刷寫的高效，使用了內存的log buffer。 由於InnoDB大部分情況下使用的是文件系統，（linux文件系統本身也是有buffer的）而不是直接使用物理塊設備，這樣的話就有兩種丟失日志的可能性：日志保存在log_buffer中，機器掛了，對應的事務數據就丟失了；日志從log buffer刷到了linux文件系統的buffer，機器掛掉了，對應的事務數據就丟失了。 2.InnoDB有一個參數用於設置這兩個緩存的刷新： innodb_flush_log_at_trx_commit。而 innodb_flush_log_at_trx_commit 有三個值：0/1/2，默認是1。而innodb_flush_log_at_timeout 定義了每次日志刷新的時間，與 innodb_flush_log_at_trx_commit 配合使用： innodb_flush_log_at_trx_commit=1，表示在每次事務提交的時候，都把log buffer刷到文件系統中(os buffer)去，並且調用文件系統的“flush”操作將緩存刷新到磁盤上去。 innodb_flush_log_at_trx_commit=0，表示每隔一秒把log buffer刷到文件系統中(os buffer)去，並且調用文件系統的“flush”操作將緩存刷新到磁盤上去。 innodb_flush_log_at_trx_commit=2，表示在每次事務提交的時候會把log buffer刷到文件系統中(os buffer)去，但是每隔一秒調用文件系統(os buffer)的“flush”操作將緩存刷新到磁盤上去。如果只是MySQL數據庫掛掉了，由於文件系統沒有問題，那么對應的事務數據並沒有丟失。只有在數據庫所在的主機操作系統損壞或者突然掉電的情況下，數據庫的事務數據可能丟失1秒之類的事務數據。這樣的好處，減少了事務數據丟失的概率，而對底層硬件的IO要求也沒有那么高(log buffer寫到文件系統中，一般只是從log buffer的內存轉移的文件系統的內存緩存中，對底層IO沒有壓力)。MySQL 5.6.6以后，這個“1秒”的刷新還可以用innodb_flush_log_at_timeout來控制刷新間隔。
17，innodb_flush_log_at_trx_commit：動態變量，默認是1。
該參數表示的是日志刷寫機制，可選值有0，1，2。具體意思見16。
18，innodb_flush_method：全局變量。默認為NULL。
該參數表示刷寫的模式，在5.6.7之后多了一個值：O_DIRECT_NO_FSYNC，具體說明見這里。
19，innodb_flush_neighbors：全局動態變量，默認是1。
該參數表示刷新鄰接頁，當刷寫一個臟頁時，會檢測該頁在BP里所在的區（extent：64頁，1M）的其他頁是否也有臟頁，有則一起刷寫。5.6通過參數：innodb_flush_neighbors 參數控制。機械磁盤建議開啟，固態硬盤建議設置為0，即關閉。要不是隨機IO多則建議開啟，充分利用順序IO去寫數據。
20，innodb_flushing_avg_loops：全局動態變量，默認是30，范圍是1-1000。
該參數表示控制adaptive flush對工作負載變化的響應速度。在這么多次loop內，innodb會保持上次的刷新狀態快照不變，增加這個值有助於刷新操作更加平穩，而減小這個值有助於對工作負載的變化更快的調整adaptive flush，不過，如果設置的過小的話，在突然增大/減小的工作的負載中，容易引起性能尖峰。
21，innodb_force_load_corrupted：全局變量。默認關閉
該參數表示當innodb表損壞時開啟數據庫導入表，排查故障，修復數據時不可能訪問， 當故障排除后，關閉此設置回關閉並重新啟動服務器。可以和innodb_force_recovery關聯。
22，Innodb FullText：關於InnoDB的全文索引的說明見官方文檔，使用方法見：之前介紹的文章。
23，innodb_large_prefix：全局動態變量，默認關閉。
該參數表示當innodb為字段創建索引時，限制的字節長度。關閉時，字節長度大於767則會報warnings。開啟時，則會報錯，創建不成功。
zjy@192.168.200.59 : test 11:39:29>create table ttt(id int,name varchar(1024)) default charset utf8; Query OK, 0 rows affected (0.00 sec) zjy@192.168.200.59 : test 11:39:46>alter table ttt add index idx_name(name); Query OK, 0 rows affected, 1 warning (0.00 sec) Records: 0 Duplicates: 0 Warnings: 1 zjy@192.168.200.59 : test 11:39:58>show warnings; +---------+------+---------------------------------------------------------+ | Level | Code | Message | +---------+------+---------------------------------------------------------+ | Warning | 1071 | Specified key was too long; max key length is 767 bytes | +---------+------+---------------------------------------------------------+ 1 row in set (0.01 sec) zjy@192.168.200.59 : test 11:40:00>show create table ttt\G; *************************** 1. row *************************** Table: ttt Create Table: CREATE TABLE `ttt` ( `id` int(11) DEFAULT NULL, `name` varchar(1024) DEFAULT NULL, KEY `idx_name` (`name`(255)) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 1 row in set (0.01 sec) zjy@192.168.200.59 : test 11:40:26>alter table ttt add address varchar(1024); Query OK, 0 rows affected (0.01 sec) Records: 0 Duplicates: 0 Warnings: 0 dba@192.168.200.59 : test 11:39:03>set global innodb_large_prefix = 1; Query OK, 0 rows affected (0.00 sec) zjy@192.168.200.59 : test 11:40:33>alter table ttt add index idx_address(address); ERROR 1709 (HY000): Index column size too large. The maximum column size is 767 bytes. dba@192.168.200.59 : test 11:41:10>set global innodb_large_prefix = 0; Query OK, 0 rows affected (0.01 sec) zjy@192.168.200.59 : test 11:40:57>alter table ttt add index idx_address(address); Query OK, 0 rows affected, 1 warning (0.01 sec) Records: 0 Duplicates: 0 Warnings: 1
24，innodb_locks_unsafe_for_binlog：全局變量，默認OFF。
該參數表示innodb鎖和二進制的安全問題，當ON的時候可以避免gap lock的問題，但是會引起binlog寫入順序出問題，導致主從數據不一致。建議關閉。
25，innodb_max_purge_lag：全局變量，默認0。
該參數表示是當purge操作滯后是否要延遲insert、delete、update的操作，延遲操作時間有innodb_max_purge_lag_delay控制，單位毫秒。默認不延遲，建議不延遲。
26，innodb_monitor_*相關參數：innodb_monitor_disable、innodb_monitor_enable、innodb_monitor_reset、innodb_monitor_reset_all。
這些參數表示InnoDB計數器的統計，這些都記錄在INFORMATION_SCHEMA.INNODB_METRICS中體現，后面會另起一篇文章介紹這些參數。
27，innodb_online_alter_log_max_size：全局動態變量，默認128M。
該參數具體的說明和使用上面已經說明。
28，innodb_optimize_fulltext_only：全局動態變量，默認關閉。
該參數表示改變OPTIMIZE TABLE語句操作Innodb表的方法，對含有全文索引的innodb表的維護操作期間，臨時啟用該變量。默認情況， OPTIMIZE TABLE 會對有聚集索引表進行重新整理數據。當啟用這選項，OPTIMIZE TABLE跳過表數據重新整理，僅對有全文索引的新增、更新和刪除的數據進行處理。
29，innodb_page_size：全局變量，默認16K。
該參數表示InnoDB頁的大小，默認16K，可以設置的值有4K、8K、16K。在數據庫創建的時候就先設置好，后續不能修改。
30，innodb_print_all_deadlocks：全局動態變量，默認OFF。
該參數表示死鎖檢測，開啟可以把所有的死鎖狀況打印到error日志中。否則，使用 SHOW ENGINE INNODB STATUS命令，只能看到最后一條死鎖信息。InnoDB死鎖會自動回滾一個小事務，可以使用這個選項來排除為什么發生死鎖。
31，innodb_purge_threads：全局變量，默認是1。5.6之前最大也只能設置1，5.6.5之后可以設置大於1。
該參數表示回收UNDO，5.5之后的參數，從Master Thread獨立出來，回收無用的UNDO頁。在MySQL 5.5之前是在Master Thread中完成的。5.5之后，獨立到了單獨的線程中完成，減輕了Master Thread線程的工作，提升CPU的使用率和存儲引擎的性能。和參數innodb_purge_batch_size配合使用，該參數控制每次回收UNDO頁的數量，在5.5之前默認是20（寫死），5.5之后可以根據情況調整該參數，默認300。
32，innodb_read_ahead_threshold：全局變量，默認56，最大64。單位是頁。
該參數控制InnoDB預讀的靈敏度（闕值），如果Innodb至少從一個extent（64頁）順序讀取innodb_read_ahead_threshold頁，則innodb將會異步的將下一個extent讀取到buffer pool中。可以監控這些預讀的情況：
在監控innodb的預讀時候，我們可以通過show innodb status中的 Pages read ahead和evicted without access 兩個值來觀察預讀的情況： Pages read ahead 1.00/s, evicted without access 9.99/s. 得到的值表示每秒讀入和讀出的pages 或者通過兩個狀態值： Innodb_buffer_pool_read_ahead和Innodb_buffer_pool_read_ahead_evicted. Innodb_buffer_pool_read_ahead：表示通過預讀請求到buffer pool的pages； Innodb_buffer_pool_read_ahead_evicted：表示由於請求到buffer pool中沒有被訪問，而驅逐出buffer pool的pages； > show global status like '%read_ahead%'; +---------------------------------------+-------+ | Variable_name | Value | +---------------------------------------+-------+ | Innodb_buffer_pool_read_ahead_rnd | 0 | | Innodb_buffer_pool_read_ahead | 18497 | | Innodb_buffer_pool_read_ahead_evicted | 0 | +---------------------------------------+-------+
具體的說明見：http://hidba.org/?p=398
33，innodb_read_only：全局變量，5.6.7開始支持，默認OFF。
該參數表示以只讀模式啟動服務。用於分發數據庫應用或數據設置為只讀的。也可以用於數據倉庫，多個實例之間共享同一數據目錄，具體可以查看官網說明。
34，innodb_replication_delay：全局動態變量，默認0，單位毫秒。
該參數表示當到達innodb_thread_concurrency限制，在一個從服務延遲復制線程（毫秒），一般為了提高並發和cpu的利用率innodb_thread_concurrency設置為0，不做限制，所以該參數沒什么意義。
35，innodb_rollback_on_timeout：全局變量，默認OFF。
該參數表示當發生超時的時候，關閉參數時InnoDB僅回滾超時事務的最后一條語句，如果開啟則一個事務超時引起Innodb中止和回滾整個事務。可以看這個例子。
36，innodb_sort_buffer_size：全局變量，5.6.4進入，默認1M，可選范圍是64K到64M。
該參數表示在InnoDB索引創造期間排序數據，僅用於在創建索引期間合並排序,而不是用於后續索引維護操作。在ALTER TABLE或CREATE TABLE 創建一個索引期間，分配3個緩沖區。每個緩沖區的大小都使用該選項。這些緩沖區在創建索引完成時將其收回。這個選項的也控制online ddl臨時日志文件擴展大小，該日志文件記錄在線DDL期間並發DML操作的數據。
37，innodb_stats_on_metadata：全局動態變量，默認OFF。
該參數表示查詢 information_schema 元數據庫里的表時,Innodb 還會隨機提取其他數據庫每個表索引頁的部分數據,當你的表很大,並且數量很多時,耗費的時間就會很長,很多不訪問的數據也會進入到Innodb_Buffer_Pool 緩沖池里,那么就會把緩沖池所污染。並且 ANALYZE TABLE和 SHOW TABLE STATUS 語句也會造成 Innodb 隨機提取數據。5.6.6之后默認是OFF，之前默認是ON，建議關閉。
38，innodb_undo_directory：全局變量，5.6.3開始支持。把undo log分離到獨立的表空間，並放到單獨的文件目錄下，這給我們部署不同IO類型的文件位置帶來便利，對於並發寫入型負載，我們可以把undo文件部署到單獨的高速存儲設備上。具體可以查看這篇文章。
該參數表示當開啟獨立undo表空間，指定undo文件存放的目錄。即InnoDB為undo日志創建單獨的表空間文件的相對或絕對路徑。將日志存儲在不同的存儲設備。結合innodb_undo_logs 和 innodb_undo_tablespaces 一起使用。這個變量決定在系統表空間之外的undo日志的存儲布局。默認.表示和其他日志在同一個目錄。
39，innodb_undo_logs：全局動態變量，默認128
該參數表示回滾段的個數（早期版本的命名為innodb_rollback_segments ），該變量可以動態調整，但是物理上的回滾段不會減少，只是會控制用到的回滾段的個數。
40，innodb_undo_tablespaces：全局變量，默認0
該參數表示用於設定創建的undo表空間的個數，在Install db時初始化后，就再也不能被改動了。默認值為0，表示不獨立設置undo的tablespace，默認記錄到ibdata中；否則，則在undo目錄下創建這么多個undo文件，例如假定設置該值為16，那么就會創建命名為undo001~undo016的undo tablespace文件，每個文件的默認大小為10M。
41，innodb_lru_scan_depth：全局動態變量，默認1024
該參數會影響page cleaner線程每次刷臟頁的數量，這是一個每1秒 loop一次的線程。當系統的IO比較空閑的時候，可以適當將這個參數設大，當IO吃緊時，需要適當減小。IO能力強的可以適當調大具體，可以查看這篇文章。
42，table_open_cache_instances：全局動態變量，默認1
對table cache進行划分，減少table cache的鎖競爭。
43，metadata_locks_hash_instances:全局動態變量，默認8
對server層的metalock hash進行划分。
44， metadata_locks_cache_size:全局動態變量，默認1024
metadata lock cache的大小，這是總的大小，可以適當調大來提升並發度。
45，log_throttle_queries_not_using_indexes：全局動態變量，默認0
當打開log_queries_not_using_indexes 時，該變量用於限制每分鍾寫入slow log的日志條數。
46，default_tmp_storage_engine:動態變量，默認InnoDB
用於控制在創建臨時表時使用的存儲引擎，默認為innodb。
47，explicit_defaults_for_timestamp:默認0
影響timestamp類型column的行為，具體見文檔中的參數說明或則上一篇文章說明。
48，ignore_db_dirs:
用於控制是否忽略DATA目錄下的db目錄，多個用多行分開，如：
ignore_db_dir = undolog ignore_db_dir = tokudb_data ignore_db_dir = tokudb_log
dba@192.168.121.58 : (none) 02:06:52>show variables like 'ignore_db_dirs'; +----------------+--------------------------------+ | Variable_name | Value | +----------------+--------------------------------+ | ignore_db_dirs | undolog,tokudb_data,tokudb_log | +----------------+--------------------------------+
49，eq_range_index_dive_limit:動態變量，默認10
用於優化in()，以確認是否直接使用索引統計，在where條件中列的等值條件個數小於這個值時，使用index dive來估算行數，否則使用index statistics來估算；設置為0則禁用index statistics，index dive更准確但效率低，具體說明見 文檔或則文章說明。
50，復制相關的參數：
slave_parallel_workers #備庫復制worker線程數
slave_checkpoint_group #在並發復制時總共執行這么多次事務后做一次checkpoint，更新show slave status的數據
slave_checkpoint_period #在復制執行這么長時間后做一次checkpoint
slave_pending_jobs_size_max #在多線程復制時，在隊列中Pending的事件所占用的最大內存，默認為16M，如果內存富余，或者延遲較大時，可以適當調大;注意這個值要比主庫的max_allowed_packet大
slave_allow_batching #備庫是否允許批量更新，只用於ndb cluster
slave_sql_verify_checksum #備庫SQL線程是否檢查binlog的checksum
binlog_checksum #默認為CRC32，表示使用該算法記錄binlog checksum，設置為NONE，則關閉checksum
binlog_max_flush_queue_time #表示在做group commit之前多長時間從刷新隊列讀取事務。默認值為0，表示沒有超時，直到隊列為空為止。控制在Flush stage中的等待時間,讓Flush隊列在此階段多等待一些時間來增加這一組事務隊列的數量使 該隊列到Sync階段可以一次fysnc()更多的事務
binlog_order_commits #開啟該選項時，事務提交順序和binlog記錄順序是相同的，默認打開；設置為關閉時，事務提交順序可能是並行的；關閉可能提升性能
binlog_row_image #row模式下，binlog記錄格式。根據選項記錄相應的列：full：默認行為，記錄所有的列，和MySQL5.6之前的版本一樣；minimal：記錄被修改的列，其他未修改的列不記錄；noblob ：記錄所有的列，除text、blob列外。
binlog_rows_query_log_events #行模式下，是否記錄原始的query語句，可以直接不需要-vv，直接用mysqlbinlog查看。
log_bin_use_v1_row_events #默認關閉，表示使用v2版本的binlog格式，打開的話，則使用之前版本的binlog格式
51，
...
相關文章：
http://www.tuicool.com/articles/z2uAza