MySQL最優配置模板( 5.6&5.7)
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接受的資料包大小。有時候大的插入和更新會受此引數限制,導致大資料寫入或者更新失敗
max_long_data_size = 67108864 //設定可以由mysql_stmt_send_long_data()這個C API函式所傳送的引數值的最大長度,如果沒有在mysqld啟動時設定,其預設為max_allowed_packet變數的值
event_scheduler = 1 //事件排程器的總開關
default_password_lifetime = 0 //設定密碼自動失效的時間,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伺服器關閉互動式連線前等待的秒數
wait_timeout = 1800 //MySQL伺服器關閉非互動連線之前等待的秒數
lock_wait_timeout = 1800
skip_name_resolve = 1
max_connections = 1024 //針對所有使用者連線限制
max_user_connections = 256 //針對同一使用者的連線限制
max_connect_errors = 1000000 //當錯誤連線數超過設定的值後,將無法正常連線
# table cache performance settings #
table_open_cache = 4096 //指定表快取記憶體的大小。每當MySQL訪問一個表時,如果在表緩衝區中還有空間,該表就被開啟並放入其中,這樣可以更快地訪問表內容
table_definition_cache = 4096 //表定義資訊快取
table_open_cache_instances = 64 //指的是 MySQL 快取 table 控制代碼的分割槽的個數,而每一個cache_instance可以包含不超過table_open_cache/table_open_cache_instances 的table_cache_element
# session memory settings #
read_buffer_size = 16M //MySQL讀入緩衝區的大小,將對錶進行順序掃描的請求將分配一個讀入緩衝區,MySQL會為它分配一段記憶體緩衝區,read_buffer_size變數控制這一緩衝區的大小,如果對錶的順序掃描非常頻繁,並你認為頻繁掃描進行的太慢,可以通過增加該變數值以及記憶體緩衝區大小提高其效能,read_buffer_size變數控制這一提高表的順序掃描的效率 資料檔案順序
read_rnd_buffer_size = 32M //
sort_buffer_size = 32M //是MySQL的隨機讀緩衝區大小,當按任意順序讀取行時(列如按照排序順序)將分配一個隨機讀取緩衝區,進行排序查詢時,MySQL會首先掃描一遍該緩衝,以避免磁碟搜尋,提高查詢速度,如果需要大量資料可適當的調整該值,但MySQL會為每個客戶連線分配該緩衝區所以儘量適當設定該值,以免記憶體開銷過大。表的隨機的順序緩衝 提高讀取的效率
tmp_table_size = 64M //它規定了內部記憶體臨時表的最大值,每個執行緒都要分配。(實際起限制作用的是tmp_table_size和max_heap_table_size的最小值。)如果記憶體臨時表超出了限制,MySQL就會自動地把它轉化為基於磁碟的MyISAM表,儲存在指定的tmpdir目錄下。優化查詢語句的時候,要避免使用臨時表,如果實在避免不了的話,要保證這些臨時表是存在記憶體中的。如果需要的話並且你有很多group by語句,並且你有很多記憶體,增大tmp_table_size(和max_heap_table_size)的值。這個變數不適用與使用者建立的記憶體表(memory table).
你可以比較內部基於磁碟的臨時表的總數和建立在記憶體中的臨時表的總數(Created_tmp_disk_tables和Created_tmp_tables),一般的比例關係是:
Created_tmp_disk_tables/Created_tmp_tables<5%。max_heap_table_size這個變數定義了使用者可以建立的記憶體表(memory table)的大小.這個值用來計算記憶體表的最大行數值。這個變數支援動態改變,即set @max_heap_table_size=#
,但是對於已經存在的記憶體表就沒有什麼用了,除非這個表被重新建立(create table)或者修改(alter table)或者truncate table。服務重啟也會設定已經存在的記憶體表為全域性max_heap_table_size的值。
這個變數和tmp_table_size一起限制了內部記憶體表的大小。
join_buffer_size = 128M //用於表間關聯快取的大小
thread_cache_size = 64 //伺服器執行緒快取這個值表示可以重新利用儲存在快取中執行緒的數量,當斷開連線時如果快取中還有空間,那麼客戶端的執行緒將被放到快取中,如果執行緒重新被請求,那麼請求將從快取中讀取,如果快取中是空的或者是新的請求,那麼這個執行緒將被重新建立,如果有很多新的執行緒,增加這個值可以改善系統性能.通過比較 Connections 和 Threads_created 狀態的變數,可以看到這個變數的作用.
# 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 //記錄執行緩慢的管理SQL
log_slow_slave_statements = 1 //記錄從庫上執行的慢查詢語句
log_throttle_queries_not_using_indexes = 10 //每分鐘允許記錄到slowlog的且未使用索引的SQL語句次數
expire_logs_days = 30
long_query_time = 2
min_examined_row_limit = 100 //查詢語句的執行行數檢查返回少於該引數指定行的SQL不被記錄到慢查詢日誌
binlog-rows-query-log-events = 1 //當binlog_fromat=row的時候記錄的是event,如果想要在row模式的情況下也記錄SQL語句
log-bin-trust-function-creators = 1 //此引數僅在啟用二進位制日誌時有效,用於控制建立儲存函式時如果會導致不安全的事件記錄二進位制日誌條件下是否禁止建立儲存函式。預設值為0,表示除非使用者除了CREATE ROUTING或ALTER ROUTINE許可權外還有SUPER許可權,否則將禁止建立或修改儲存函式,同時,還要求在建立函式時必需為之使用DETERMINISTIC屬性,再不然就是附帶READS SQL DATA或NO SQL屬性。設定其值為1時則不啟用這些限制。作用範圍為全域性級別,可用於配置檔案,屬動態變數。
log-slave-updates = 1 //一般情況下slave不會把從master接收到的binlog記錄寫入自己的binlog,這個引數會使slave通過SQL執行緒把從master接受到的binlog寫進自己的binlog,但是前提是slave一定要開啟自己的binlog,此引數一般用於級聯複製,例如需要A複製到B,B複製到C,那麼B就要開啟此引數。
# innodb settings #
innodb_page_size = 16384 //引數innodb_page_size可以設定Innodb資料頁為8K,4K,預設為16K。這個引數在一開始初始化時就要加入my.cnf裡,如果已經建立了表,再修改,啟動MySQL會報錯。
innodb_buffer_pool_size = 160G //引數表示緩衝池位元組大小,InnoDB快取表和索引資料的記憶體區域
innodb_buffer_pool_instances = 16 //預設值是1,表示InnoDB快取池被劃分到一個區域。適當地增加該引數(例如將該引數值設定為2),此時InnoDB被劃分成為兩個區域,可以提升InnoDB的併發效能。如果InnoDB快取池被劃分成多個區域,建議每個區域不小於1GB的空間
innodb_buffer_pool_load_at_startup = 1 //在啟動時把熱資料載入到記憶體
innodb_buffer_pool_dump_at_shutdown = 1 //在關閉時把熱資料dump到本地磁碟
innodb_lru_scan_depth = 4096 //控制LRU列表中可用頁的數量,預設值為1024
innodb_lock_wait_timeout = 5 //鎖等待超時時間
innodb_io_capacity = 10000 //引數可以動態調整重新整理髒頁的數量,這在一定程度上解決了這一問題。innodb_io_capacity引數預設是200,單位是頁。該引數設定的大小取決於硬碟的IOPS,即每秒的輸入輸出量
innodb_io_capacity_max = 20000 //該引數限制了每秒重新整理的髒頁上限,調大該值可以增加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引擎開始引入多種格式的行儲存機制,目前支援:Antelope、Barracuda兩種。其中Barracuda相容Antelope格式。
另外,Innodb plugin還支援行資料壓縮特性,不過前提是採用Barracuda行儲存格式。
表空間啟用壓縮的前提是innodb表空間檔案儲存格式修改成:Barracuda,需要修改2個選項:
innodb_file_format= "Barracuda"
innodb_file_format_max = "Barracuda"
innodb_undo_logs = 128 //定義在一個事務中innodb使用的系統表空間中回滾段的個數。如果觀察到同回滾日誌有關的互斥爭用,可以調整這個引數以優化效能。早期版本的命名為innodb_rollback_segments,該變數可以動態調整,但是物理上的回滾段不會減少,只是會控制用到的回滾段的個數;預設為128個回滾段
innodb_undo_tablespaces = 3 //用於設定建立的undo表空間的個數,在mysql_install_db時初始化後,就再也不能被改動了;預設值為0,表示不獨立設定undo的tablespace,預設記錄到ibdata中;否則,則在undo目錄下建立這麼多個undo檔案,例如假定設定該值為4,那麼就會建立命名為undo001~undo004的undo tablespace檔案,每個檔案的預設大小為10M。修改該值會導致Innodb無法完成初始化,資料庫無法啟動,但是另兩個引數可以修改
innodb_flush_neighbors = 0 //預設值為 1. 在SSD儲存上應設定為0(禁用) ,因為使用順序IO沒有任何效能收益. 在使用RAID的某些硬體上也應該禁用此設定,因為邏輯上連續的塊在物理磁碟上並不能保證也是連續的
innodb_log_file_size = 200M //日誌組的大小,預設為5M;如果對 Innodb 資料表有大量的寫入操作,那麼選擇合適的innodb_log_file_size值對提升MySQL效能很重要。然而設定太大了,就會增加恢復的時間,因此在MySQL崩潰或者突然斷電等情況會令MySQL伺服器花很長時間來恢復
innodb_log_files_in_group = 2 //日誌組的數量,預設為2
innodb_log_buffer_size = 16M //日誌緩衝池的大小
innodb_purge_threads = 4 //在innodb 1.2版本開始 innodb支援多個purge thread 這樣做的目的是為了進一步加快undo頁的回收這樣也能更進一步利用磁碟的隨機讀取效能 使用者可以設定4個purge thread
innodb_large_prefix = 1 //大家應該知道InnoDB單列索引長度不能超過767bytes,聯合索引還有一個限制是長度不能超過3072。innodb_large_prefix 這個引數預設值是OFF,當改為ON時,允許列索引最大達到3072
innodb_thread_concurrency = 64 //參考:http://www.cnblogs.com/xinysu/p/6439715.html
innodb_print_all_deadlocks = 1 //這樣死鎖相關資訊會儲存到MySQL 錯誤日誌中
innodb_strict_mode = 1 //開啟強制檢查模式,忽略警告資訊,直接丟擲錯誤資訊
innodb_sort_buffer_size = 67108864 //加速ORDER BY 或者GROUP BY 操作
innodb_write_io_threads = 16
innodb_read_io_threads = 16 //假如CPU是2顆8核的,那麼可以設定:innodb_read_io_threads = 8,innodb_write_io_threads = 8。如果資料庫的讀操作比寫操作多,那麼可以設定:innodb_read_io_threads = 10,innodb_write_io_threads = 6
innodb_file_per_table = 1 //獨立表空間模式,每個資料庫的每個表都會生成一個數據空間
innodb_stats_persistent_sample_pages = 64 //控制收集統計資訊時取樣的page數量,預設是20。收集的page數量越多,每次收集統計資訊的實際則越長,但是統計資訊也相對比較準確
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能開啟的表的資料。
分配原則:這個值預設是300。如果庫裡的表特別多的情況,可以適當增大為1000。innodb_open_files的大小對InnoDB效率的影響比較小。但是在InnoDBcrash的情況下,innodb_open_files設定過小會影響recovery的效率。所以用InnoDB的時候還是把innodb_open_files放大一些比較合適。
innodb_flush_log_at_trx_commit = 1 //如果innodb_flush_log_at_trx_commit設定為0,log buffer將每秒一次地寫入log file中,並且log file的flush(刷到磁碟)操作同時進行.該模式下,在事務提交的時候,不會主動觸發寫入磁碟的操作。
如果innodb_flush_log_at_trx_commit設定為1,每次事務提交時MySQL都會把log buffer的資料寫入log file,並且flush(刷到磁碟)中去.
如果innodb_flush_log_at_trx_commit設定為2,每次事務提交時MySQL都會把log buffer的資料寫入log file.但是flush(刷到磁碟)操作並不會同時進行。該模式下,MySQL會每秒執行一次 flush(刷到磁碟)操作
innodb_support_xa = 1 //作用是分兩類:第一,支援多例項分散式事務(外部xa事務),這個一般在分散式資料庫環境中用得較多。第二,支援內部xa事務,說白了也就是說支援binlog與innodb redo log之間資料一致性
# replication settings #
master_info_repository = TABLE
relay_log_info_repository = TABLE //在MySQL 5.6.2之前,slave記錄的master資訊以及slave應用binlog的資訊存放在檔案中,即master.info與relay-log.info。在5.6.2版本之後,允許記錄到table中,引數設定如下:master-info-repository = TABLE,relay-log-info-repository = TABLE,對應的表分別為mysql.slave_master_info與mysql.slave_relay_log_info,且這兩個表均為innodb引擎表。
sync_binlog = 1 //是MySQL 的二進位制日誌(binary log)同步到磁碟的頻率。取值:0-N,sync_binlog=0,當事務提交之後,MySQL不做fsync之類的磁碟同步指令重新整理binlog_cache中的資訊到磁碟,而讓Filesystem自行決定什麼時候來做同步,或者cache滿了之後才同步到磁碟。這個是效能最好的。sync_binlog=1,當每進行1次事務提交之後,MySQL將進行一次fsync之類的磁碟同步指令來將binlog_cache中的資料強制寫入磁碟。sync_binlog=n,當每進行n次事務提交之後,MySQL將進行一次fsync之類的磁碟同步指令來將binlog_cache中的資料強制寫入磁碟。
gtid_mode = on //是否開啟GTID功能
enforce_gtid_consistency = 1 //enforce_gtid_consistency強制GTID一致性, 啟用後,create table ... select ...命令無法再使用
log_slave_updates
binlog_format = ROW
binlog_rows_query_log_events = 1 //只作用於RBR格式,預設不啟用 如果啟用,會把使用者寫直的原生態DML操作記錄到binlog中
relay_log = relay.log
relay_log_purge = 1
relay_log_recovery = 1 //當slave從庫宕機後,假如relay-log損壞了,導致一部分中繼日誌沒有處理,則自動放棄所有未執行的relay-log,並且重新從master上獲取日誌,這樣就保證了relay-log的完整性。預設情況下該功能是關閉的,將relay_log_recovery的值設定為 1時,可在slave從庫上開啟該功能,建議開啟
report-port = 3306
report-host = 10.106.144.11
slave_skip_errors = ddl_exist_errors
slave-rows-search-algorithms = 'INDEX_SCAN,HASH_SCAN' //可以部分解決無主鍵表導致的複製延遲問題
# 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 //控制在主庫是否開啟了非同步複製模式,可以設定為ON,OFF ,預設是off
rpl_semi_sync_master_timeout = 3000 //控制主庫等待備庫反饋已提交事務在備庫落地的時間,以毫秒為單位預設是10s
rpl_semi_sync_slave_enabled = 1 //控制在從庫是否開啟了非同步複製模式,可以設定為ON,OFF ,預設是off
# password plugin #
validate_password_policy=STRONG //密碼安全策略LOW, MEDIUM,STRONG ,其中LOW表示只限制長度;MEDIUM 則為長度,字元,數字,大小寫,特殊字元;STRONG則在之前的基礎上增加字典目錄
validate-password=FORCE_PLUS_PERMANENT //該引數是為了防止外掛在mysql執行時的時候被解除安裝
# 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 //簡單來說 MDL Lock 是 MySQL Server 層中的表鎖,主要是為了控制 Server 層 DDL & DML 的併發而設計的, 但是 5.5 的設計中只有一把大鎖,所以到5.6中添加了引數 metadata_locks_hash_instances 來控制分割槽的數量,進而實現大鎖的拆分,雖然鎖的拆分提高了併發的效能,但是仍然存在著不少的效能問題,所以在 5.7.4 中 MDL Lock 的實現方式採用了 lock free 演算法,徹底的解決了 Server 層表鎖的效能問題,而引數 metadata_locks_hash_instances 也將會在之後的某個版本中被刪除掉
[mysqld-5.7]
# new innodb settings #
loose_innodb_numa_interleave = 1 //緩衝池記憶體的分配策略採用interleave的方式
innodb_buffer_pool_dump_pct = 40 //預設為關閉OFF。如果開啟該引數,停止MySQL服務時,InnoDB將InnoDB緩衝池中的熱資料的百分比儲存到本地硬碟,5.7.6以前是100,5.7.7開始是25,也就是儲存快取中的25%熱資料
innodb_page_cleaners = 16 //為了提升擴充套件性和刷髒效率,在5.7.4版本里引入了多個page cleaner執行緒。從而達到並行刷髒的效果。在該版本中,Page cleaner並未和buffer pool繫結,其模型為一個協調執行緒 + 多個工作執行緒,協調執行緒本身也是工作執行緒。因此如果innodb_page_cleaners設定為8,那麼就是一個協調執行緒,加7個工作執行緒
innodb_undo_log_truncate = 1 //設定為ON即可開啟undo表空間的自動truncate
innodb_max_undo_log_size = 2G //undo表空間檔案超過此值即標記為可收縮,預設1G,可線上修改
innodb_purge_rseg_truncate_frequency = 128 //指定purge操作被喚起多少次之後才釋放rollback segments。當undo表空間裡面的rollback segments被釋放時,undo表空間才會被truncate。由此可見,該引數越小,undo表空間被嘗試truncate的頻率越高。
# new replication settings #
slave-parallel-type = LOGICAL_CLOCK //可以有兩個值:DATABASE 預設值,基於庫的並行複製方式;LOGICAL_CLOCK:基於組提交的並行複製方式
slave-parallel-workers = 16 //在MySQL 5.7中,引入了基於組提交的並行複製(Enhanced Multi-threaded Slaves),設定引數slave_parallel_workers>0並且slave_parallel_type=‘LOGICAL_CLOCK’,即可支援一個schema下,slave_parallel_workers個的worker執行緒併發執行relay log中主庫提交的事務。其核心思想:一個組提交的事務都是可以並行回放(配合binary log group commit)
slave_preserve_commit_order = 1 //mysql 5.7 後的MTS可以實現更小粒度的並行複製,但需要將slave_parallel_type設定為LOGICAL_CLOCK,但僅僅設定為LOGICAL_CLOCK也會存在問題,因為此時在slave上應用事務的順序是無序的,和relay log中記錄的事務順序不一樣,這樣資料一致性是無法保證的,為了保證事務是按照relay log中記錄的順序來回放,就需要開啟引數slave_preserve_commit_order
slave_transaction_retries = 128 //如果SQL執行緒在執行事務時發生InnoDB死鎖且等待超時後,slave重試的次數,預設為10,如果超過此次數,slave將會丟擲error且終止replication;此值在“slave_parallel_workers”開啟時無效,即為0,不重試。
# other change settings #
binlog_gtid_simple_recovery = 1 //MySQL5.7.7之後預設on,這個引數控制了當mysql啟動或重啟時,mysql在搜尋GTIDs時是如何迭代使用binlog檔案。該引數為真時,mysql-server只需開啟最老的和最新的這2個binlog檔案,gtid_purged引數的值和gtid_executed引數的值可以根據這些檔案中的Previous_gtids_log_event或者Gtid_log_event計算得出。這確保了當mysql-server重啟或清理binlog時,只需開啟2個binlog檔案。當這個引數設定為off,在mysql恢復期間,為了初始化gtid_executed,所有以最新檔案開始的binlog都要被檢查。並且為了初始化gtid_purged,所有的binlog都要被檢查。這可能需要非常長的時間,建議開啟。注意:MySQL5.6中,預設為off,調整這個選項設定也同樣會提升效能,但是在一些特殊場景下,計算gtids值可能會出錯。而保持這個選項值為off,能確保計算總是正確
log_timestamps = system //該引數主要是控制 error log、genera log,等等記錄日誌的顯示時間引數。在 5.7.2 之後改引數為預設 UTC 這樣會導致日誌中記錄的時間比中國這邊的慢,導致檢視日誌不方便。修改為 SYSTEM 就能解決問題
show_compatibility_56 = on //版本高的mysql中show_compatibility_56的預設值為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為每個事務收集write set並用XXHASH64哈唏演算法編碼這個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連線、建立的group的名稱
loose_group_replication_compression_threshold = 100 //將其設定為100表示對傳送的網路訊息(writeset)大於100位元組的進行壓縮,從而提升效能
loose_group_replication_flow_control_mode = 0
loose_group_replication_single_primary_mode = 0 //表示啟動了Single-Primary模式,那麼修改為OFF就意味著要啟動Multi-Primary模式
loose_group_replication_enforce_update_everywhere_checks = 1 //該引數設定為ON,則禁用了在多主模式下一些可能產生未知資料衝突的操作
loose_group_replication_transaction_size_limit = 10485760
loose_group_replication_unreachable_majority_timeout = 120
loose_group_replication_start_on_boot = 0 //是否隨著服務啟動叢集
[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接受的資料包大小。有時候大的插入和更新會受此引數限制,導致大資料寫入或者更新失敗 max_long_data_size = 67108864 //設定可以由mysql_stmt_send_long_data()這個C API函式所傳送的引數值的最大長度,如果沒有在mysqld啟動時設定,其預設為max_allowed_packet變數的值 event_scheduler = 1 //事件排程器的總開關 default_password_lifetime = 0 //設定密碼自動失效的時間,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伺服器關閉互動式連線前等待的秒數 wait_timeout = 1800 //MySQL伺服器關閉非互動連線之前等待的秒數 lock_wait_timeout = 1800 skip_name_resolve = 1 max_connections = 1024 //針對所有使用者連線限制 max_user_connections = 256 //針對同一使用者的連線限制 max_connect_errors = 1000000 //當錯誤連線數超過設定的值後,將無法正常連線 # table cache performance settings # table_open_cache = 4096 //指定表快取記憶體的大小。每當MySQL訪問一個表時,如果在表緩衝區中還有空間,該表就被開啟並放入其中,這樣可以更快地訪問表內容 table_definition_cache = 4096 //表定義資訊快取 table_open_cache_instances = 64 //指的是 MySQL 快取 table 控制代碼的分割槽的個數,而每一個 cache_instance 可以包含不超過table_open_cache/table_open_cache_instances 的table_cache_element # session memory settings # read_buffer_size = 16M //MySQL讀入緩衝區的大小,將對錶進行順序掃描的請求將分配一個讀入緩衝區,MySQL會為它分配一段記憶體緩衝區,read_buffer_size變數控制這一緩衝區的大小,如果對錶的順序掃描非常頻繁,並你認為頻繁掃描進行的太慢,可以通過增加該變數值以及記憶體緩衝區大小提高其效能,read_buffer_size變數控制這一提高表的順序掃描的效率 資料檔案順序 read_rnd_buffer_size = 32M // sort_buffer_size = 32M //是MySQL的隨機讀緩衝區大小,當按任意順序讀取行時(列如按照排序順序)將分配一個隨機讀取緩衝區,進行排序查詢時,MySQL會首先掃描一遍該緩衝,以避免磁碟搜尋,提高查詢速度,如果需要大量資料可適當的調整該值,但MySQL會為每個客戶連線分配該緩衝區所以儘量適當設定該值,以免記憶體開銷過大。表的隨機的順序緩衝 提高讀取的效率 tmp_table_size = 64M //它規定了內部記憶體臨時表的最大值,每個執行緒都要分配。(實際起限制作用的是tmp_table_size和max_heap_table_size的最小值。)如果記憶體臨時表超出了限制,MySQL就會自動地把它轉化為基於磁碟的MyISAM表,儲存在指定的tmpdir目錄下。優化查詢語句的時候,要避免使用臨時表,如果實在避免不了的話,要保證這些臨時表是存在記憶體中的。如果需要的話並且你有很多group by語句,並且你有很多記憶體,增大tmp_table_size(和max_heap_table_size)的值。這個變數不適用與使用者建立的記憶體表(memory table). 你可以比較內部基於磁碟的臨時表的總數和建立在記憶體中的臨時表的總數(Created_tmp_disk_tables和Created_tmp_tables),一般的比例關係是: Created_tmp_disk_tables/Created_tmp_tables<5%。max_heap_table_size這個變數定義了使用者可以建立的記憶體表(memory table)的大小.這個值用來計算記憶體表的最大行數值。這個變數支援動態改變,即set @max_heap_table_size=# ,但是對於已經存在的記憶體表就沒有什麼用了,除非這個表被重新建立(create table)或者修改(alter table)或者truncate table。服務重啟也會設定已經存在的記憶體表為全域性max_heap_table_size的值。 這個變數和tmp_table_size一起限制了內部記憶體表的大小。 join_buffer_size = 128M //用於表間關聯快取的大小 thread_cache_size = 64 //伺服器執行緒快取這個值表示可以重新利用儲存在快取中執行緒的數量,當斷開連線時如果快取中還有空間,那麼客戶端的執行緒將被放到快取中,如果執行緒重新被請求,那麼請求將從快取中讀取,如果快取中是空的或者是新的請求,那麼這個執行緒將被重新建立,如果有很多新的執行緒,增加這個值可以改善系統性能.通過比較 Connections 和 Threads_created 狀態的變數,可以看到這個變數的作用. # 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 //記錄執行緩慢的管理SQL log_slow_slave_statements = 1 //記錄從庫上執行的慢查詢語句 log_throttle_queries_not_using_indexes = 10 //每分鐘允許記錄到slow log的且未使用索引的SQL語句次數 expire_logs_days = 30 long_query_time = 2 min_examined_row_limit = 100 //查詢語句的執行行數檢查返回少於該引數指定行的SQL不被記錄到慢查詢日誌 binlog-rows-query-log-events = 1 //當binlog_fromat=row的時候記錄的是event,如果想要在row模式的情況下也記錄SQL語句 log-bin-trust-function-creators = 1 //此引數僅在啟用二進位制日誌時有效,用於控制建立儲存函式時如果會導致不安全的事件記錄二進位制日誌條件下是否禁止建立儲存函式。預設值為0,表示除非使用者除了CREATE ROUTING或ALTER ROUTINE許可權外還有SUPER許可權,否則將禁止建立或修改儲存函式,同時,還要求在建立函式時必需為之使用DETERMINISTIC屬性,再不然就是附帶READS SQL DATA或NO SQL屬性。設定其值為1時則不啟用這些限制。作用範圍為全域性級別,可用於配置檔案,屬動態變數。 log-slave-updates = 1 //一般情況下slave不會把從master接收到的binlog記錄寫入自己的binlog,這個引數會使slave通過SQL執行緒把從master接受到的binlog寫進自己的binlog,但是前提是slave一定要開啟自己的binlog,此引數一般用於級聯複製,例如需要A複製到B,B複製到C,那麼B就要開啟此引數。 # innodb settings # innodb_page_size = 16384 //引數innodb_page_size可以設定Innodb資料頁為8K,4K,預設為16K。這個引數在一開始初始化時就要加入my.cnf裡,如果已經建立了表,再修改,啟動MySQL會報錯。 innodb_buffer_pool_size = 160G //引數表示緩衝池位元組大小,InnoDB快取表和索引資料的記憶體區域 innodb_buffer_pool_instances = 16 //預設值是1,表示InnoDB快取池被劃分到一個區域。適當地增加該引數(例如將該引數值設定為2),此時InnoDB被劃分成為兩個區域,可以提升InnoDB的併發效能。如果InnoDB快取池被劃分成多個區域,建議每個區域不小於1GB的空間 innodb_buffer_pool_load_at_startup = 1 //在啟動時把熱資料載入到記憶體 innodb_buffer_pool_dump_at_shutdown = 1 //在關閉時把熱資料dump到本地磁碟 innodb_lru_scan_depth = 4096 //控制LRU列表中可用頁的數量,預設值為1024 innodb_lock_wait_timeout = 5 //鎖等待超時時間 innodb_io_capacity = 10000 //引數可以動態調整重新整理髒頁的數量,這在一定程度上解決了這一問題。innodb_io_capacity引數預設是200,單位是頁。該引數設定的大小取決於硬碟的IOPS,即每秒的輸入輸出量 innodb_io_capacity_max = 20000 //該引數限制了每秒重新整理的髒頁上限,調大該值可以增加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引擎開始引入多種格式的行儲存機制,目前支援:Antelope、Barracuda兩種。其中Barracuda相容Antelope格式。 另外,Innodb plugin還支援行資料壓縮特性,不過前提是採用Barracuda行儲存格式。 表空間啟用壓縮的前提是innodb表空間檔案儲存格式修改成:Barracuda,需要修改2個選項: innodb_file_format = "Barracuda" innodb_file_format_max = "Barracuda" innodb_undo_logs = 128 //定義在一個事務中innodb使用的系統表空間中回滾段的個數。如果觀察到同回滾日誌有關的互斥爭用,可以調整這個引數以優化效能。早期版本的命名為 innodb_rollback_segments,該變數可以動態調整,但是物理上的回滾段不會減少,只是會控制用到的回滾段的個數;預設為128個回滾段 innodb_undo_tablespaces = 3 //用於設定建立的undo表空間的個數,在mysql_install_db時初始化後,就再也不能被改動了;預設值為0,表示不獨立設定undo的tablespace,預設記錄到ibdata中;否則,則在undo目錄下建立這麼多個undo檔案,例如假定設定該值為4,那麼就會建立命名為undo001~undo004的undo tablespace檔案,每個檔案的預設大小為10M。修改該值會導致Innodb無法完成初始化,資料庫無法啟動,但是另兩個引數可以修改 innodb_flush_neighbors = 0 //預設值為 1. 在SSD儲存上應設定為0(禁用) ,因為使用順序IO沒有任何效能收益. 在使用RAID的某些硬體上也應該禁用此設定,因為邏輯上連續的塊在物理磁碟上並不能保證也是連續的 innodb_log_file_size = 200M //日誌組的大小,預設為5M;如果對 Innodb 資料表有大量的寫入操作,那麼選擇合適的 innodb_log_file_size值對提升MySQL效能很重要。然而設定太大了,就會增加恢復的時間,因此在MySQL崩潰或者突然斷電等情況會令MySQL伺服器花很長時間來恢復 innodb_log_files_in_group = 2 //日誌組的數量,預設為2 innodb_log_buffer_size = 16M //日誌緩衝池的大小 innodb_purge_threads = 4 //在innodb 1.2版本開始 innodb支援多個purge thread 這樣做的目的是為了進一步加快undo頁的回收這樣也能更進一步利用磁碟的隨機讀取效能 使用者可以設定4個purge thread innodb_large_prefix = 1 //大家應該知道InnoDB單列索引長度不能超過767bytes,聯合索引還有一個限制是長度不能超過3072。innodb_large_prefix 這個引數預設值是OFF,當改為ON時,允許列索引最大達到3072 innodb_thread_concurrency = 64 //參考:http://www.cnblogs.com/xinysu/p/6439715.html innodb_print_all_deadlocks = 1 //這樣死鎖相關資訊會儲存到MySQL 錯誤日誌中 innodb_strict_mode = 1 //開啟強制檢查模式,忽略警告資訊,直接丟擲錯誤資訊 innodb_sort_buffer_size = 67108864 //加速ORDER BY 或者GROUP BY 操作 innodb_write_io_threads = 16 innodb_read_io_threads = 16 //假如CPU是2顆8核的,那麼可以設定:innodb_read_io_threads = 8,innodb_write_io_threads = 8。如果資料庫的讀操作比寫操作多,那麼可以設定:innodb_read_io_threads = 10,innodb_write_io_threads = 6 innodb_file_per_table = 1 //獨立表空間模式,每個資料庫的每個表都會生成一個數據空間 innodb_stats_persistent_sample_pages = 64 //控制收集統計資訊時取樣的page數量,預設是20。收集的page數量越多,每次收集統計資訊的實際則越長,但是統計資訊也相對比較準確 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能開啟的表的資料。 分配原則:這個值預設是300。如果庫裡的表特別多的情況,可以適當增大為1000。innodb_open_files的大小對InnoDB效率的影響比較小。但是在InnoDBcrash的情況下,innodb_open_files設定過小會影響recovery的效率。所以用InnoDB的時候還是把innodb_open_files放大一些比較合適。 innodb_flush_log_at_trx_commit = 1 //如果innodb_flush_log_at_trx_commit設定為0,log buffer將每秒一次地寫入log file中,並且log file的flush(刷到磁碟)操作同時進行.該模式下,在事務提交的時候,不會主動觸發寫入磁碟的操作。 如果innodb_flush_log_at_trx_commit設定為1,每次事務提交時MySQL都會把log buffer的資料寫入log file,並且flush(刷到磁碟)中去. 如果innodb_flush_log_at_trx_commit設定為2,每次事務提交時MySQL都會把log buffer的資料寫入log file.但是flush(刷到磁碟)操作並不會同時進行。該模式下,MySQL會每秒執行一次 flush(刷到磁碟)操作 innodb_support_xa = 1 //作用是分兩類:第一,支援多例項分散式事務(外部xa事務),這個一般在分散式資料庫環境中用得較多。第二,支援內部xa事務,說白了也就是說支援binlog與innodb redo log之間資料一致性 # replication settings # master_info_repository = TABLE relay_log_info_repository = TABLE //在MySQL 5.6.2之前,slave記錄的master資訊以及slave應用binlog的資訊存放在檔案中,即master.info與relay-log.info。在5.6.2版本之後,允許記錄到table中,引數設定如下:master-info-repository = TABLE,relay-log-info-repository = TABLE,對應的表分別為mysql.slave_master_info與mysql.slave_relay_log_info,且這兩個表均為innodb引擎表。 sync_binlog = 1 //是MySQL 的二進位制日誌(binary log)同步到磁碟的頻率。取值:0-N,sync_binlog=0,當事務提交之後,MySQL不做fsync之類的磁碟同步指令重新整理binlog_cache中的資訊到磁碟,而讓Filesystem自行決定什麼時候來做同步,或者cache滿了之後才同步到磁碟。這個是效能最好的。sync_binlog=1,當每進行1次事務提交之後,MySQL將進行一次fsync之類的磁碟同步指令來將binlog_cache中的資料強制寫入磁碟。sync_binlog=n,當每進行n次事務提交之後,MySQL將進行一次fsync之類的磁碟同步指令來將binlog_cache中的資料強制寫入磁碟。 gtid_mode = on //是否開啟GTID功能 enforce_gtid_consistency = 1 //enforce_gtid_consistency 強制GTID一致性, 啟用後,create table ... select ...命令無法再使用 log_slave_updates binlog_format = ROW binlog_rows_query_log_events = 1 //只作用於RBR格式,預設不啟用 如果啟用,會把使用者寫直的原生態DML操作記錄到binlog中 relay_log = relay.log relay_log_purge = 1 relay_log_recovery = 1 //當slave從庫宕機後,假如relay-log損壞了,導致一部分中繼日誌沒有處理,則自動放棄所有未執行的relay-log,並且重新從master上獲取日誌,這樣就保證了relay-log的完整性。預設情況下該功能是關閉的,將relay_log_recovery的值設定為 1時,可在slave從庫上開啟該功能,建議開啟 report-port = 3306 report-host = 10.106.144.11 slave_skip_errors = ddl_exist_errors slave-rows-search-algorithms = 'INDEX_SCAN,HASH_SCAN' //可以部分解決無主鍵表導致的複製延遲問題 # 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 //控制在主庫是否開啟了非同步複製模式,可以設定為ON,OFF ,預設是off rpl_semi_sync_master_timeout = 3000 //控制主庫等待備庫反饋已提交事務在備庫落地的時間,以毫秒為單位預設是10s rpl_semi_sync_slave_enabled = 1 //控制在從庫是否開啟了非同步複製模式,可以設定為ON,OFF ,預設是off # password plugin # validate_password_policy=STRONG //密碼安全策略LOW, MEDIUM,STRONG ,其中LOW表示只限制長度;MEDIUM 則為長度,字元,數字,大小寫,特殊字元;STRONG則在之前的基礎上增加字典目錄 validate-password=FORCE_PLUS_PERMANENT //該引數是為了防止外掛在mysql執行時的時候被解除安裝 # 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 //簡單來說 MDL Lock 是 MySQL Server 層中的表鎖,主要是為了控制 Server 層 DDL & DML 的併發而設計的, 但是 5.5 的設計中只有一把大鎖,所以到5.6中添加了引數 metadata_locks_hash_instances 來控制分割槽的數量,進而實現大鎖的拆分,雖然鎖的拆分提高了併發的效能,但是仍然存在著不少的效能問題,所以在 5.7.4 中 MDL Lock 的實現方式採用了 lock free 演算法,徹底的解決了 Server 層表鎖的效能問題,而引數 metadata_locks_hash_instances 也將會在之後的某個版本中被刪除掉 [mysqld-5.7] # new innodb settings # loose_innodb_numa_interleave = 1 //緩衝池記憶體的分配策略採用interleave的方式 innodb_buffer_pool_dump_pct = 40 //預設為關閉OFF。如果開啟該引數,停止MySQL服務時,InnoDB將InnoDB緩衝池中的熱資料的百分比儲存到本地硬碟,5.7.6以前是100,5.7.7開始是25,也就是儲存快取中的25%熱資料 innodb_page_cleaners = 16 //為了提升擴充套件性和刷髒效率,在5.7.4版本里引入了多個page cleaner執行緒。從而達到並行刷髒的效果。在該版本中,Page cleaner並未和buffer pool繫結,其模型為一個協調執行緒 + 多個工作執行緒,協調執行緒本身也是工作執行緒。因此如果innodb_page_cleaners設定為8,那麼就是一個協調執行緒,加7個工作執行緒 innodb_undo_log_truncate = 1 //設定為ON即可開啟undo表空間的自動truncate innodb_max_undo_log_size = 2G //undo表空間檔案超過此值即標記為可收縮,預設1G,可線上修改 innodb_purge_rseg_truncate_frequency = 128 //指定purge操作被喚起多少次之後才釋放rollback segments。當undo表空間裡面的rollback segments被釋放時,undo表空間才會被truncate。由此可見,該引數越小,undo表空間被嘗試truncate的頻率越高。 # new replication settings # slave-parallel-type = LOGICAL_CLOCK //可以有兩個值:DATABASE 預設值,基於庫的並行複製方式;LOGICAL_CLOCK:基於組提交的並行複製方式 slave-parallel-workers = 16 //在MySQL 5.7中,引入了基於組提交的並行複製(Enhanced Multi-threaded Slaves),設定引數slave_parallel_workers>0並且slave_parallel_type=‘LOGICAL_CLOCK’,即可支援一個schema下,slave_parallel_workers個的worker執行緒併發執行relay log中主庫提交的事務。其核心思想:一個組提交的事務都是可以並行回放(配合binary log group commit) slave_preserve_commit_order = 1 //mysql 5.7 後的MTS可以實現更小粒度的並行複製,但需要將slave_parallel_type設定為LOGICAL_CLOCK,但僅僅設定為LOGICAL_CLOCK也會存在問題,因為此時在slave上應用事務的順序是無序的,和relay log中記錄的事務順序不一樣,這樣資料一致性是無法保證的,為了保證事務是按照relay log中記錄的順序來回放,就需要開啟引數slave_preserve_commit_order slave_transaction_retries = 128 //如果SQL執行緒在執行事務時發生InnoDB死鎖且等待超時後,slave重試的次數,預設為10,如果超過此次數,slave將會丟擲error且終止replication;此值在“slave_parallel_workers”開啟時無效,即為0,不重試。 # other change settings # binlog_gtid_simple_recovery = 1 //MySQL5.7.7之後預設on,這個引數控制了當mysql啟動或重啟時,mysql在搜尋GTIDs時是如何迭代使用binlog檔案。該引數為真時,mysql-server只需開啟最老的和最新的這2個binlog檔案,gtid_purged引數的值和gtid_executed引數的值可以根據這些檔案中的Previous_gtids_log_event或者Gtid_log_event計算得出。這確保了當mysql-server重啟或清理binlog時,只需開啟2個binlog檔案。當這個引數設定為off,在mysql恢復期間,為了初始化gtid_executed,所有以最新檔案開始的binlog都要被檢查。並且為了初始化gtid_purged,所有的binlog都要被檢查。這可能需要非常長的時間,建議開啟。注意:MySQL5.6中,預設為off,調整這個選項設定也同樣會提升效能,但是在一些特殊場景下,計算gtids值可能會出錯。而保持這個選項值為off,能確保計算總是正確 log_timestamps = system //該引數主要是控制 error log、genera log,等等記錄日誌的顯示時間引數。在 5.7.2 之後改引數為預設 UTC 這樣會導致日誌中記錄的時間比中國這邊的慢,導致檢視日誌不方便。修改為 SYSTEM 就能解決問題 show_compatibility_56 = on //版本高的mysql中show_compatibility_56的預設值為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為每個事務收集write set並用XXHASH64哈唏演算法編碼這個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連線、建立的group的名稱 loose_group_replication_compression_threshold = 100 //將其設定為100表示對傳送的網路訊息(writeset)大於100位元組的進行壓縮,從而提升效能 loose_group_replication_flow_control_mode = 0 loose_group_replication_single_primary_mode = 0 //表示啟動了Single-Primary模式,那麼修改為OFF就意味著要啟動Multi-Primary模式 loose_group_replication_enforce_update_everywhere_checks = 1 //該引數設定為ON,則禁用了在多主模式下一些可能產生未知資料衝突的操作 loose_group_replication_transaction_size_limit = 10485760 loose_group_replication_unreachable_majority_timeout = 120 loose_group_replication_start_on_boot = 0 //是否隨著服務啟動叢集
不積跬步,無以至千里!