I assume the MySQL Server as followings. You should tune the variables according to your server.

32 CPU core

256G Memory

SSD storage with 20000 IOPS in 16K page size

[mysql]

default-character-set=utf8mb4

user = root

password = 123456

port = 3306

socket = /tmp/mysqld.sock

prompt="\u@\h \d>"

[mysqld]

# basic settings #

user = mysql

bind-address = 0.0.0.0

socket = /tmp/mysqld.sock

character_set_server = utf8mb4

transaction_isolation = READ-COMMITTED

explicit_defaults_for_timestamp = 1

max_allowed_packet = 67108864 ? ?//限制Server接受的數(shù)據(jù)包大小狈茉。有時(shí)候大的插入和更新會(huì)受此參數(shù)限制，導(dǎo)致大數(shù)據(jù)寫入或者更新失敗

max_long_data_size = 67108864 ? ?//設(shè)定可以由mysql_stmt_send_long_data()這個(gè)C API函數(shù)所傳送的參數(shù)值的最大長(zhǎng)度稚失，如果沒有在mysqld啟動(dòng)時(shí)設(shè)定，其默認(rèn)為max_allowed_packet變量的值

event_scheduler = 1 ? ?//事件調(diào)度器的總開關(guān)

default_password_lifetime = 0 ? ?//設(shè)置密碼自動(dòng)失效的時(shí)間庶骄，0為永不失效

autocommit = 1

server-id = 1

sql_mode = "STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER"

# connection #

interactive_timeout = 1800 ? ?//MySQL服務(wù)器關(guān)閉交互式連接前等待的秒數(shù)

wait_timeout = 1800 ? ?//MySQL服務(wù)器關(guān)閉非交互連接之前等待的秒數(shù)

lock_wait_timeout = 1800

skip_name_resolve = 1

max_connections = 1024 ? ?//針對(duì)所有用戶連接限制

max_user_connections = 256 ? ?//針對(duì)同一用戶的連接限制

max_connect_errors = 1000000 ? ?//當(dāng)錯(cuò)誤連接數(shù)超過設(shè)定的值后,將無法正常連接

# table cache performance settings #

table_open_cache = 4096 ? ?//指定表高速緩存的大小澳眷。每當(dāng)MySQL訪問一個(gè)表時(shí)习柠，如果在表緩沖區(qū)中還有空間，該表就被打開并放入其中倒信，這樣可以更快地訪問表內(nèi)容

table_definition_cache = 4096 ? ?//表定義信息緩存

table_open_cache_instances = 64 ? ?//指的是 MySQL 緩存 table 句柄的分區(qū)的個(gè)數(shù)科贬，而每一個(gè)?cache_instance?可以包含不超過table_open_cache/table_open_cache_instances 的table_cache_element

# session memory settings #

read_buffer_size = 16M ? ?//MySQL讀入緩沖區(qū)的大小，將對(duì)表進(jìn)行順序掃描的請(qǐng)求將分配一個(gè)讀入緩沖區(qū)鳖悠，MySQL會(huì)為它分配一段內(nèi)存緩沖區(qū)唆迁，read_buffer_size變量控制這一緩沖區(qū)的大小，如果對(duì)表的順序掃描非常頻繁竞穷，并你認(rèn)為頻繁掃描進(jìn)行的太慢唐责，可以通過增加該變量值以及內(nèi)存緩沖區(qū)大小提高其性能，read_buffer_size變量控制這一提高表的順序掃描的效率 數(shù)據(jù)文件順序

read_rnd_buffer_size = 32M? ? //

sort_buffer_size = 32M? ? //是MySQL的隨機(jī)讀緩沖區(qū)大小瘾带，當(dāng)按任意順序讀取行時(shí)（列如按照排序順序）將分配一個(gè)隨機(jī)讀取緩沖區(qū)鼠哥，進(jìn)行排序查詢時(shí)，MySQL會(huì)首先掃描一遍該緩沖，以避免磁盤搜索朴恳，提高查詢速度抄罕，如果需要大量數(shù)據(jù)可適當(dāng)?shù)恼{(diào)整該值，但MySQL會(huì)為每個(gè)客戶連接分配該緩沖區(qū)所以盡量適當(dāng)設(shè)置該值于颖，以免內(nèi)存開銷過大呆贿。表的隨機(jī)的順序緩沖 提高讀取的效率

tmp_table_size = 64M? ? //它規(guī)定了內(nèi)部?jī)?nèi)存臨時(shí)表的最大值，每個(gè)線程都要分配森渐。（實(shí)際起限制作用的是tmp_table_size和max_heap_table_size的最小值做入。）如果內(nèi)存臨時(shí)表超出了限制，MySQL就會(huì)自動(dòng)地把它轉(zhuǎn)化為基于磁盤的MyISAM表同衣，存儲(chǔ)在指定的tmpdir目錄下竟块。優(yōu)化查詢語(yǔ)句的時(shí)候，要避免使用臨時(shí)表耐齐，如果實(shí)在避免不了的話浪秘，要保證這些臨時(shí)表是存在內(nèi)存中的。如果需要的話并且你有很多group by語(yǔ)句埠况，并且你有很多內(nèi)存耸携，增大tmp_table_size(和max_heap_table_size)的值。這個(gè)變量不適用與用戶創(chuàng)建的內(nèi)存表(memory table).

你可以比較內(nèi)部基于磁盤的臨時(shí)表的總數(shù)和創(chuàng)建在內(nèi)存中的臨時(shí)表的總數(shù)（Created_tmp_disk_tables和Created_tmp_tables）辕翰，一般的比例關(guān)系是:

Created_tmp_disk_tables/Created_tmp_tables<5%夺衍。max_heap_table_size這個(gè)變量定義了用戶可以創(chuàng)建的內(nèi)存表(memory table)的大小.這個(gè)值用來計(jì)算內(nèi)存表的最大行數(shù)值。這個(gè)變量支持動(dòng)態(tài)改變金蜀，即set @max_heap_table_size=#

,但是對(duì)于已經(jīng)存在的內(nèi)存表就沒有什么用了刷后，除非這個(gè)表被重新創(chuàng)建(create table)或者修改(alter table)或者truncate table的畴。服務(wù)重啟也會(huì)設(shè)置已經(jīng)存在的內(nèi)存表為全局max_heap_table_size的值渊抄。

這個(gè)變量和tmp_table_size一起限制了內(nèi)部?jī)?nèi)存表的大小。

join_buffer_size = 128M? ? //用于表間關(guān)聯(lián)緩存的大小

thread_cache_size = 64? ? //服務(wù)器線程緩存這個(gè)值表示可以重新利用保存在緩存中線程的數(shù)量,當(dāng)斷開連接時(shí)如果緩存中還有空間,那么客戶端的線程將被放到緩存中,如果線程重新被請(qǐng)求丧裁，那么請(qǐng)求將從緩存中讀取,如果緩存中是空的或者是新的請(qǐng)求护桦，那么這個(gè)線程將被重新創(chuàng)建,如果有很多新的線程，增加這個(gè)值可以改善系統(tǒng)性能.通過比較 Connections 和 Threads_created 狀態(tài)的變量煎娇，可以看到這個(gè)變量的作用.

# log settings #

log_error = error.log

log-bin = mysql-bin

slow_query_log = 1

slow_query_log_file = slow.log

log_queries_not_using_indexes = 1

log_slow_admin_statements = 1? ? //記錄執(zhí)行緩慢的管理SQL

log_slow_slave_statements = 1? ? //記錄從庫(kù)上執(zhí)行的慢查詢語(yǔ)句?

log_throttle_queries_not_using_indexes = 10? ? //每分鐘允許記錄到slow?log的且未使用索引的SQL語(yǔ)句次數(shù)

expire_logs_days = 30

long_query_time = 2

min_examined_row_limit = 100? ? //查詢語(yǔ)句的執(zhí)行行數(shù)檢查返回少于該參數(shù)指定行的SQL不被記錄到慢查詢?nèi)罩?/p>

binlog-rows-query-log-events = 1? ? //當(dāng)binlog_fromat=row的時(shí)候記錄的是event二庵，如果想要在row模式的情況下也記錄SQL語(yǔ)句

log-bin-trust-function-creators = 1? ? //此參數(shù)僅在啟用二進(jìn)制日志時(shí)有效，用于控制創(chuàng)建存儲(chǔ)函數(shù)時(shí)如果會(huì)導(dǎo)致不安全的事件記錄二進(jìn)制日志條件下是否禁止創(chuàng)建存儲(chǔ)函數(shù)缓呛。默認(rèn)值為0催享，表示除非用戶除了CREATE ROUTING或ALTER ROUTINE權(quán)限外還有SUPER權(quán)限，否則將禁止創(chuàng)建或修改存儲(chǔ)函數(shù)哟绊，同時(shí)因妙，還要求在創(chuàng)建函數(shù)時(shí)必需為之使用DETERMINISTIC屬性，再不然就是附帶READS SQL DATA或NO SQL屬性。設(shè)置其值為1時(shí)則不啟用這些限制攀涵。作用范圍為全局級(jí)別铣耘，可用于配置文件，屬動(dòng)態(tài)變量。

log-slave-updates = 1? ? //一般情況下slave不會(huì)把從master接收到的binlog記錄寫入自己的binlog，這個(gè)參數(shù)會(huì)使slave通過SQL線程把從master接受到的binlog寫進(jìn)自己的binlog米者，但是前提是slave一定要開啟自己的binlog蛤高，此參數(shù)一般用于級(jí)聯(lián)復(fù)制，例如需要A復(fù)制到B特纤，B復(fù)制到C，那么B就要開啟此參數(shù)。

# innodb settings #

innodb_page_size = 16384? ? //參數(shù)innodb_page_size可以設(shè)置Innodb數(shù)據(jù)頁(yè)為8K,4K橱野，默認(rèn)為16K。這個(gè)參數(shù)在一開始初始化時(shí)就要加入my.cnf里善玫，如果已經(jīng)創(chuàng)建了表水援，再修改，啟動(dòng)MySQL會(huì)報(bào)錯(cuò)茅郎。

innodb_buffer_pool_size = 160G? ? //參數(shù)表示緩沖池字節(jié)大小蜗元，InnoDB緩存表和索引數(shù)據(jù)的內(nèi)存區(qū)域

innodb_buffer_pool_instances = 16? ? //默認(rèn)值是1，表示InnoDB緩存池被劃分到一個(gè)區(qū)域系冗。適當(dāng)?shù)卦黾釉搮?shù)（例如將該參數(shù)值設(shè)置為2）奕扣，此時(shí)InnoDB被劃分成為兩個(gè)區(qū)域，可以提升InnoDB的并發(fā)性能掌敬。如果InnoDB緩存池被劃分成多個(gè)區(qū)域惯豆，建議每個(gè)區(qū)域不小于1GB的空間

innodb_buffer_pool_load_at_startup = 1? ? //在啟動(dòng)時(shí)把熱數(shù)據(jù)加載到內(nèi)存

innodb_buffer_pool_dump_at_shutdown = 1? ? //在關(guān)閉時(shí)把熱數(shù)據(jù)dump到本地磁盤

innodb_lru_scan_depth = 4096? ? //控制LRU列表中可用頁(yè)的數(shù)量,默認(rèn)值為1024

innodb_lock_wait_timeout = 5? ? //鎖等待超時(shí)時(shí)間

innodb_io_capacity = 10000? ? //參數(shù)可以動(dòng)態(tài)調(diào)整刷新臟頁(yè)的數(shù)量，這在一定程度上解決了這一問題奔害。innodb_io_capacity參數(shù)默認(rèn)是200楷兽，單位是頁(yè)。該參數(shù)設(shè)置的大小取決于硬盤的IOPS华临，即每秒的輸入輸出量

innodb_io_capacity_max = 20000? ? //該參數(shù)限制了每秒刷新的臟頁(yè)上限芯杀，調(diào)大該值可以增加Page cleaner線程每秒的工作量

innodb_flush_method = O_DIRECT? ? //參考鏈接：http://www.cnblogs.com/simplelogic/p/5004786.html

innodb_file_format = Barracuda

innodb_file_format_max = Barracuda? ? //Innodb Plugin引擎開始引入多種格式的行存儲(chǔ)機(jī)制，目前支持：Antelope雅潭、Barracuda兩種揭厚。其中Barracuda兼容Antelope格式。

另外扶供，Innodb plugin還支持行數(shù)據(jù)壓縮特性筛圆，不過前提是采用Barracuda行存儲(chǔ)格式。

表空間啟用壓縮的前提是innodb表空間文件存儲(chǔ)格式修改成：Barracuda椿浓，需要修改2個(gè)選項(xiàng)：

innodb_file_format?= "Barracuda"

innodb_file_format_max = "Barracuda"

innodb_undo_logs = 128? ? //定義在一個(gè)事務(wù)中innodb使用的系統(tǒng)表空間中回滾段的個(gè)數(shù)太援。如果觀察到同回滾日志有關(guān)的互斥爭(zhēng)用漾岳，可以調(diào)整這個(gè)參數(shù)以優(yōu)化性能。早期版本的命名為?innodb_rollback_segments粉寞，該變量可以動(dòng)態(tài)調(diào)整尼荆，但是物理上的回滾段不會(huì)減少，只是會(huì)控制用到的回滾段的個(gè)數(shù);默認(rèn)為128個(gè)回滾段

innodb_undo_tablespaces = 3? ? //用于設(shè)定創(chuàng)建的undo表空間的個(gè)數(shù)唧垦，在mysql_install_db時(shí)初始化后捅儒，就再也不能被改動(dòng)了；默認(rèn)值為0振亮，表示不獨(dú)立設(shè)置undo的tablespace巧还，默認(rèn)記錄到ibdata中；否則坊秸，則在undo目錄下創(chuàng)建這么多個(gè)undo文件麸祷，例如假定設(shè)置該值為4，那么就會(huì)創(chuàng)建命名為undo001~undo004的undo tablespace文件褒搔，每個(gè)文件的默認(rèn)大小為10M阶牍。修改該值會(huì)導(dǎo)致Innodb無法完成初始化，數(shù)據(jù)庫(kù)無法啟動(dòng)星瘾，但是另兩個(gè)參數(shù)可以修改

innodb_flush_neighbors = 0? ? //默認(rèn)值為 1. 在SSD存儲(chǔ)上應(yīng)設(shè)置為0(禁用) ,因?yàn)槭褂庙樞騃O沒有任何性能收益. 在使用RAID的某些硬件上也應(yīng)該禁用此設(shè)置,因?yàn)檫壿嬌线B續(xù)的塊在物理磁盤上并不能保證也是連續(xù)的

innodb_log_file_size = 200M? ? //日志組的大小,默認(rèn)為5M走孽；如果對(duì) Innodb 數(shù)據(jù)表有大量的寫入操作，那么選擇合適的?innodb_log_file_size值對(duì)提升MySQL性能很重要琳状。然而設(shè)置太大了磕瓷，就會(huì)增加恢復(fù)的時(shí)間，因此在MySQL崩潰或者突然斷電等情況會(huì)令MySQL服務(wù)器花很長(zhǎng)時(shí)間來恢復(fù)

innodb_log_files_in_group = 2? ? //日志組的數(shù)量念逞，默認(rèn)為2

innodb_log_buffer_size = 16M? ? //日志緩沖池的大小

innodb_purge_threads = 4? ? //在innodb 1.2版本開始 innodb支持多個(gè)purge thread 這樣做的目的是為了進(jìn)一步加快undo頁(yè)的回收這樣也能更進(jìn)一步利用磁盤的隨機(jī)讀取性能 用戶可以設(shè)置4個(gè)purge thread

innodb_large_prefix = 1? ? //大家應(yīng)該知道InnoDB單列索引長(zhǎng)度不能超過767bytes困食，聯(lián)合索引還有一個(gè)限制是長(zhǎng)度不能超過3072。innodb_large_prefix 這個(gè)參數(shù)默認(rèn)值是OFF翎承，當(dāng)改為ON時(shí)硕盹，允許列索引最大達(dá)到3072

innodb_thread_concurrency = 64? ? //參考：http://www.cnblogs.com/xinysu/p/6439715.html

innodb_print_all_deadlocks = 1? ? //這樣死鎖相關(guān)信息會(huì)保存到MySQL 錯(cuò)誤日志中

innodb_strict_mode = 1? ? //開啟強(qiáng)制檢查模式，忽略警告信息审洞，直接拋出錯(cuò)誤信息

innodb_sort_buffer_size = 67108864? ? //加速ORDER BY 或者GROUP BY 操作

innodb_write_io_threads = 16

innodb_read_io_threads = 16? ? //假如CPU是2顆8核的莱睁，那么可以設(shè)置：innodb_read_io_threads = 8待讳，innodb_write_io_threads = 8芒澜。如果數(shù)據(jù)庫(kù)的讀操作比寫操作多，那么可以設(shè)置：innodb_read_io_threads = 10创淡，innodb_write_io_threads = 6

innodb_file_per_table = 1? ? //獨(dú)立表空間模式,每個(gè)數(shù)據(jù)庫(kù)的每個(gè)表都會(huì)生成一個(gè)數(shù)據(jù)空間

innodb_stats_persistent_sample_pages = 64? ? //控制收集統(tǒng)計(jì)信息時(shí)采樣的page數(shù)量痴晦，默認(rèn)是20。收集的page數(shù)量越多琳彩，每次收集統(tǒng)計(jì)信息的實(shí)際則越長(zhǎng)誊酌，但是統(tǒng)計(jì)信息也相對(duì)比較準(zhǔn)確

innodb_autoinc_lock_mode = 2? ? //參考：http://blog.itpub.net/15498/viewspace-2141640/

innodb_online_alter_log_max_size = 1G? ? //參考：http://blog.itpub.net/29773961/viewspace-2140971/

innodb_open_files = 4096? ? //作用：限制Innodb能打開的表的數(shù)據(jù)部凑。

分配原則：這個(gè)值默認(rèn)是300。如果庫(kù)里的表特別多的情況碧浊，可以適當(dāng)增大為1000涂邀。innodb_open_files的大小對(duì)InnoDB效率的影響比較小。但是在InnoDBcrash的情況下箱锐，innodb_open_files設(shè)置過小會(huì)影響recovery的效率比勉。所以用InnoDB的時(shí)候還是把innodb_open_files放大一些比較合適。

innodb_flush_log_at_trx_commit = 1? ? //如果innodb_flush_log_at_trx_commit設(shè)置為0驹止，log buffer將每秒一次地寫入log file中浩聋，并且log file的flush(刷到磁盤)操作同時(shí)進(jìn)行.該模式下，在事務(wù)提交的時(shí)候臊恋，不會(huì)主動(dòng)觸發(fā)寫入磁盤的操作衣洁。

如果innodb_flush_log_at_trx_commit設(shè)置為1，每次事務(wù)提交時(shí)MySQL都會(huì)把log buffer的數(shù)據(jù)寫入log file抖仅，并且flush(刷到磁盤)中去.

如果innodb_flush_log_at_trx_commit設(shè)置為2坊夫，每次事務(wù)提交時(shí)MySQL都會(huì)把log buffer的數(shù)據(jù)寫入log file.但是flush(刷到磁盤)操作并不會(huì)同時(shí)進(jìn)行。該模式下,MySQL會(huì)每秒執(zhí)行一次 flush(刷到磁盤)操作

innodb_support_xa = 1? ? //作用是分兩類：第一撤卢，支持多實(shí)例分布式事務(wù)（外部xa事務(wù)）践樱，這個(gè)一般在分布式數(shù)據(jù)庫(kù)環(huán)境中用得較多。第二凸丸，支持內(nèi)部xa事務(wù)拷邢，說白了也就是說支持binlog與innodb redo log之間數(shù)據(jù)一致性

# replication settings #

master_info_repository = TABLE

relay_log_info_repository = TABLE? ? //在MySQL 5.6.2之前，slave記錄的master信息以及slave應(yīng)用binlog的信息存放在文件中屎慢，即master.info與relay-log.info瞭稼。在5.6.2版本之后，允許記錄到table中腻惠，參數(shù)設(shè)置如下：master-info-repository ?= TABLE环肘，relay-log-info-repository = TABLE，對(duì)應(yīng)的表分別為mysql.slave_master_info與mysql.slave_relay_log_info集灌，且這兩個(gè)表均為innodb引擎表悔雹。

sync_binlog = 1? ? //是MySQL 的二進(jìn)制日志（binary log）同步到磁盤的頻率。取值：0-N欣喧，sync_binlog=0腌零，當(dāng)事務(wù)提交之后，MySQL不做fsync之類的磁盤同步指令刷新binlog_cache中的信息到磁盤唆阿，而讓Filesystem自行決定什么時(shí)候來做同步益涧，或者cache滿了之后才同步到磁盤。這個(gè)是性能最好的驯鳖。sync_binlog=1闲询，當(dāng)每進(jìn)行1次事務(wù)提交之后久免，MySQL將進(jìn)行一次fsync之類的磁盤同步指令來將binlog_cache中的數(shù)據(jù)強(qiáng)制寫入磁盤。sync_binlog=n扭弧，當(dāng)每進(jìn)行n次事務(wù)提交之后阎姥，MySQL將進(jìn)行一次fsync之類的磁盤同步指令來將binlog_cache中的數(shù)據(jù)強(qiáng)制寫入磁盤。

gtid_mode = on? ? //是否開啟GTID功能

enforce_gtid_consistency = 1? ? //enforce_gtid_consistency?強(qiáng)制GTID一致性, 啟用后鸽捻，create table ... select ...命令無法再使用

log_slave_updates

binlog_format = ROW

binlog_rows_query_log_events = 1? ? //只作用于RBR格式,默認(rèn)不啟用 如果啟用,會(huì)把用戶寫直的原生態(tài)DML操作記錄到binlog中

relay_log = relay.log

relay_log_purge = 1

relay_log_recovery = 1? ? //當(dāng)slave從庫(kù)宕機(jī)后丁寄，假如relay-log損壞了，導(dǎo)致一部分中繼日志沒有處理泊愧，則自動(dòng)放棄所有未執(zhí)行的relay-log伊磺，并且重新從master上獲取日志，這樣就保證了relay-log的完整性删咱。默認(rèn)情況下該功能是關(guān)閉的屑埋，將relay_log_recovery的值設(shè)置為 1時(shí)，可在slave從庫(kù)上開啟該功能痰滋，建議開啟

report-port = 3306

report-host = 10.106.144.11

slave_skip_errors = ddl_exist_errors

slave-rows-search-algorithms = 'INDEX_SCAN,HASH_SCAN'? ? //可以部分解決無主鍵表導(dǎo)致的復(fù)制延遲問題

# semi sync replication settings #

plugin_load = "validate_password.so;rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"

rpl_semi_sync_master_enabled = 1? ? //控制在主庫(kù)是否開啟了異步復(fù)制模式摘能，可以設(shè)置為ON,OFF ,默認(rèn)是off?

rpl_semi_sync_master_timeout = 3000? ? //控制主庫(kù)等待備庫(kù)反饋已提交事務(wù)在備庫(kù)落地的時(shí)間，以毫秒為單位默認(rèn)是10s?

rpl_semi_sync_slave_enabled = 1? ? //控制在從庫(kù)是否開啟了異步復(fù)制模式敲街，可以設(shè)置為ON,OFF ,默認(rèn)是off

# password plugin #

validate_password_policy=STRONG? ? //密碼安全策略LOW团搞， MEDIUM，STRONG 多艇，其中LOW表示只限制長(zhǎng)度逻恐；MEDIUM 則為長(zhǎng)度，字符峻黍，數(shù)字复隆，大小寫，特殊字符姆涩；STRONG則在之前的基礎(chǔ)上增加字典目錄

validate-password=FORCE_PLUS_PERMANENT? ? //該參數(shù)是為了防止插件在mysql運(yùn)行時(shí)的時(shí)候被卸載

# perforamnce_schema settings

performance-schema-instrument='memory/%=COUNTED'

performance_schema_digests_size = 40000

performance_schema_max_table_instances = 40000

performance_schema_max_sql_text_length = 4096

performance_schema_max_digest_length = 4096

[mysqld-5.6]

# metalock performance settings

metadata_locks_hash_instances = 64? ? //簡(jiǎn)單來說 MDL Lock 是 MySQL Server 層中的表鎖挽拂，主要是為了控制 Server 層 DDL & DML 的并發(fā)而設(shè)計(jì)的， 但是 5.5 的設(shè)計(jì)中只有一把大鎖骨饿，所以到5.6中添加了參數(shù) metadata_locks_hash_instances 來控制分區(qū)的數(shù)量亏栈，進(jìn)而實(shí)現(xiàn)大鎖的拆分，雖然鎖的拆分提高了并發(fā)的性能宏赘，但是仍然存在著不少的性能問題绒北，所以在 5.7.4 中 MDL Lock 的實(shí)現(xiàn)方式采用了 lock free 算法，徹底的解決了 Server 層表鎖的性能問題置鼻，而參數(shù) metadata_locks_hash_instances 也將會(huì)在之后的某個(gè)版本中被刪除掉

[mysqld-5.7]

# new innodb settings #

loose_innodb_numa_interleave = 1? ? //緩沖池內(nèi)存的分配策略采用interleave的方式

innodb_buffer_pool_dump_pct = 40? ? //默認(rèn)為關(guān)閉OFF镇饮。如果開啟該參數(shù)蜓竹，停止MySQL服務(wù)時(shí)箕母，InnoDB將InnoDB緩沖池中的熱數(shù)據(jù)的百分比保存到本地硬盤,5.7.6以前是100,5.7.7開始是25,也就是保存緩存中的25%熱數(shù)據(jù)

innodb_page_cleaners = 16? ? //為了提升擴(kuò)展性和刷臟效率储藐，在5.7.4版本里引入了多個(gè)page cleaner線程。從而達(dá)到并行刷臟的效果嘶是。在該版本中钙勃，Page cleaner并未和buffer pool綁定，其模型為一個(gè)協(xié)調(diào)線程 + 多個(gè)工作線程聂喇，協(xié)調(diào)線程本身也是工作線程辖源。因此如果innodb_page_cleaners設(shè)置為8，那么就是一個(gè)協(xié)調(diào)線程希太，加7個(gè)工作線程

innodb_undo_log_truncate = 1? ? //設(shè)置為ON即可開啟undo表空間的自動(dòng)truncate

innodb_max_undo_log_size = 2G? ? //undo表空間文件超過此值即標(biāo)記為可收縮克饶，默認(rèn)1G，可在線修改

innodb_purge_rseg_truncate_frequency = 128? ? //指定purge操作被喚起多少次之后才釋放rollback segments誊辉。當(dāng)undo表空間里面的rollback segments被釋放時(shí)矾湃，undo表空間才會(huì)被truncate。由此可見堕澄，該參數(shù)越小邀跃，undo表空間被嘗試truncate的頻率越高。

# new replication settings #

slave-parallel-type = LOGICAL_CLOCK? ? //可以有兩個(gè)值：DATABASE 默認(rèn)值蛙紫，基于庫(kù)的并行復(fù)制方式拍屑；LOGICAL_CLOCK：基于組提交的并行復(fù)制方式

slave-parallel-workers = 16? ? //在MySQL 5.7中，引入了基于組提交的并行復(fù)制（Enhanced Multi-threaded Slaves）坑傅，設(shè)置參數(shù)slave_parallel_workers>0并且slave_parallel_type＝‘LOGICAL_CLOCK’僵驰，即可支持一個(gè)schema下，slave_parallel_workers個(gè)的worker線程并發(fā)執(zhí)行relay log中主庫(kù)提交的事務(wù)唁毒。其核心思想：一個(gè)組提交的事務(wù)都是可以并行回放（配合binary log group commit）

slave_preserve_commit_order = 1? ? //mysql 5.7 后的MTS可以實(shí)現(xiàn)更小粒度的并行復(fù)制矢渊，但需要將slave_parallel_type設(shè)置為L(zhǎng)OGICAL_CLOCK,但僅僅設(shè)置為L(zhǎng)OGICAL_CLOCK也會(huì)存在問題，因?yàn)榇藭r(shí)在slave上應(yīng)用事務(wù)的順序是無序的枉证，和relay log中記錄的事務(wù)順序不一樣矮男，這樣數(shù)據(jù)一致性是無法保證的，為了保證事務(wù)是按照relay log中記錄的順序來回放室谚，就需要開啟參數(shù)slave_preserve_commit_order

slave_transaction_retries = 128? ? //如果SQL線程在執(zhí)行事務(wù)時(shí)發(fā)生InnoDB死鎖且等待超時(shí)后毡鉴，slave重試的次數(shù)，默認(rèn)為10秒赤，如果超過此次數(shù)猪瞬，slave將會(huì)拋出error且終止replication；此值在“slave_parallel_workers”開啟時(shí)無效入篮，即為0陈瘦，不重試。

# other change settings #

binlog_gtid_simple_recovery = 1? ? //MySQL5.7.7之后默認(rèn)on潮售，這個(gè)參數(shù)控制了當(dāng)mysql啟動(dòng)或重啟時(shí)痊项，mysql在搜尋GTIDs時(shí)是如何迭代使用binlog文件锅风。該參數(shù)為真時(shí)，mysql-server只需打開最老的和最新的這2個(gè)binlog文件鞍泉，gtid_purged參數(shù)的值和gtid_executed參數(shù)的值可以根據(jù)這些文件中的Previous_gtids_log_event或者Gtid_log_event計(jì)算得出皱埠。這確保了當(dāng)mysql-server重啟或清理binlog時(shí)，只需打開2個(gè)binlog文件咖驮。當(dāng)這個(gè)參數(shù)設(shè)置為off边器，在mysql恢復(fù)期間，為了初始化gtid_executed托修，所有以最新文件開始的binlog都要被檢查忘巧。并且為了初始化gtid_purged，所有的binlog都要被檢查睦刃。這可能需要非常長(zhǎng)的時(shí)間袋坑，建議開啟。注意：MySQL5.6中眯勾，默認(rèn)為off枣宫，調(diào)整這個(gè)選項(xiàng)設(shè)置也同樣會(huì)提升性能，但是在一些特殊場(chǎng)景下吃环，計(jì)算gtids值可能會(huì)出錯(cuò)也颤。而保持這個(gè)選項(xiàng)值為off，能確保計(jì)算總是正確

log_timestamps = system? ? //該參數(shù)主要是控制 error log郁轻、genera log翅娶，等等記錄日志的顯示時(shí)間參數(shù)。在 5.7.2 之后改參數(shù)為默認(rèn) UTC 這樣會(huì)導(dǎo)致日志中記錄的時(shí)間比中國(guó)這邊的慢好唯，導(dǎo)致查看日志不方便竭沫。修改為 SYSTEM 就能解決問題

show_compatibility_56 = on? ? //版本高的mysql中show_compatibility_56的默認(rèn)值為OFF，不讓用戶訪問GLOBAL_STATUS或者GLOBAL_VARIABLES等

# group replication settings

plugin-load = "group_replication.so;validate_password.so;semisync_master.so;semisync_slave.so"

transaction-write-set-extraction = XXHASH64? ? //server為每個(gè)事務(wù)收集write set并用XXHASH64哈唏算法編碼這個(gè)set

# report_host = 127.0.0.1 # optional for group replication

# binlog_checksum = NONE # only for group replication

loose_group_replication = FORCE_PLUS_PERMANENT

loose_group_replication_group_name = "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"? ? //表示plugin連接骑篙、創(chuàng)建的group的名稱

loose_group_replication_compression_threshold = 100? ? //將其設(shè)置為100表示對(duì)發(fā)送的網(wǎng)絡(luò)消息（writeset）大于100字節(jié)的進(jìn)行壓縮蜕提，從而提升性能

loose_group_replication_flow_control_mode = 0

loose_group_replication_single_primary_mode = 0? ? //表示啟動(dòng)了Single-Primary模式，那么修改為OFF就意味著要啟動(dòng)Multi-Primary模式

loose_group_replication_enforce_update_everywhere_checks = 1? ? //該參數(shù)設(shè)置為ON靶端，則禁用了在多主模式下一些可能產(chǎn)生未知數(shù)據(jù)沖突的操作

loose_group_replication_transaction_size_limit = 10485760

loose_group_replication_unreachable_majority_timeout = 120

loose_group_replication_start_on_boot = 0? ? //是否隨著服務(wù)啟動(dòng)集群