[client]
#socket方式運行時的sock文件位置
socket=/自定義/mysql.sock
[mysqld_safe]
#錯誤日誌位置
log-error=/自定義/mysqld.log
#進程id文件
pid-file=/自定義/mysqld.pid
[mysql]
#以socket方式運行的sock文件位置
socket=/自定義/mysql.sock
[mysqld]
##########################常規配置###############################
#以什麼用戶運行
user = root
#端口
port = 3306
#數據存儲目錄
datadir = /自定義
#時區配置,例如東八區
default-time-zone = '+8:00'
#是否支持符號鏈接，即數據庫或表可以存儲在my.cnf中指定datadir之外的分區或目錄，爲0不開啓
symbolic-links=0
#mysql唯一標識,主從必用且唯一
server-id = 自定義,我一般使用ip地址最後的一段
#mysql監聽的ip地址，如果是127.0.0.1，表示僅本機訪問
bind_address = 192.168.0.60
#數據修改是否自動提交，爲0不自動提交
autocommit = 1
#服務器使用的字符集
character_set_server=utf8mb4
#禁用DNS主機名查找，用內網地址查找
skip_name_resolve = 1
#mysql最大連接數
max_connections = 800
#錯誤鏈接次數,默認10,超過以後被屏蔽,可以防止dos攻擊
max_connect_errors = 1000
#事務隔離級別默認爲可重複讀,Oracle是讀已提交
#1. READ-UNCOMMITTED(讀未提交)
#2. READ-COMMITTED(讀已提交)
#3. REPEATABLE-READ(可重複讀)
#4. SERIERLIZED(可串行化)
transaction_isolation = READ-COMMITTED
#不爲1的話TIMESTAMP類型和其他的類型不一樣,沒仔細研究
explicit_defaults_for_timestamp = 1
#FULL JOIN 就是explain中ALL,index,rang或者Index_merge的時候使用的buffer
join_buffer_size = 128M
#規定了內部內存臨時表的最大值，每個線程都要分配。實際起限制作用的是tmp_table_size和max_heap_table_size的最小值
#如果內存臨時表超出了限制，MySQL就會自動地把它轉化爲基於磁盤的MyISAM表，存儲在指定的tmpdir目錄下
tmp_table_size = 128M
#保存臨時文件的目錄
tmpdir = /自定義
#mysql最大接受的數據包大小,sql長度很大可以調大點,比如批量插入的values
max_allowed_packet = 16M
#sql_mode 模式，定義了sql語法，對數據的校驗等等，限制一些不合法的操作
sql_mode = "STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER"
#服務器關閉交互式連接前等待活動的秒數。交互式客戶端定義爲在mysql_real_connect()中使用CLIENT_INTERACTIVE選項的客戶端
interactive_timeout = 60
#服務器關閉非交互連接之前等待活動的秒數，在線程啓動時，根據全局wait_timeout值或全局interactive_timeout值初始化會話wait_timeout值，取決於客戶端類型(由mysql_real_connect()的連接選項CLIENT_INTERACTIVE定義)
wait_timeout = 60
#讀入緩衝區的大小，將對錶進行順序掃描的請求將分配一個讀入緩衝區，MySQL會爲它分配一段內存緩衝區
read_buffer_size = 16M
#隨機讀緩衝區大小，當按任意順序讀取行時（列如按照排序順序）將分配一個隨機讀取緩衝區，進行排序查詢時，MySQL會首先掃描一遍該緩衝，以避免磁盤搜索，提高查詢速度
read_rnd_buffer_size = 32M
#是一個connection級參數，在每個connection第一次需要使用這個buffer的時候，一次性分配設置的內存
sort_buffer_size = 32M
##########################日誌配置###############################
#錯誤日誌位置
log_error = 自定義
#是否開啓慢查詢日誌收集
slow_query_log = 1
#慢查詢日誌位置
slow_query_log_file = 自定義
#是否記錄未使用索引的語句
log_queries_not_using_indexes = 1
#慢查詢也記錄那些慢的optimize table，analyze table和alter table語句
log_slow_admin_statements = 1
#記錄由Slave所產生的慢查詢
log_slow_slave_statements = 1
#設定每分鐘記錄到日誌的未使用索引的語句數目，超過這個數目後只記錄語句數量和花費的總時間
log_throttle_queries_not_using_indexes = 10
#日誌自動過期清理天數
expire_logs_days = 90
#設置記錄慢查詢超時時間
long_query_time = 1
#查詢檢查返回少於該參數指定行的SQL不被記錄到慢查詢日誌
min_examined_row_limit = 100
##########################同步相關###############################
#slave保存master節點信息方式，設成file時 會生成master.info 和 relay-log.info2個文件，設成table，信息就會存在mysql.master_slave_info表中。不管是設置的哪種值，都不要移動或者編輯相關的文件和表
master_info_repository = TABLE
#用於保存slave讀取relay log的位置信息，可選值爲“FILE”、“TABLE”，以便crash重啓後繼續恢復
relay_log_info_repository = TABLE
#binlog的保存位置，只能指定前綴名,如mysql-bin,不要寫mysql-bin.log,因爲後綴mysql會自動添加
log_bin = /自定義/mysql-bin
#這個參數是對於MySQL系統來說是至關重要的，他不僅影響到Binlog對MySQL所帶來的性能損耗，而且還影響到MySQL中數據的完整性。對於“sync_binlog”參數的各種設置的說明如下：
#sync_binlog=0，當事務提交之後，MySQL不做fsync之類的磁盤同步指令刷新binlog_cache中的信息到磁盤，而讓Filesystem自行決定什麼時候來做同步，或者cache滿了之後才同步到磁盤。
#sync_binlog=n，當每進行n次事務提交之後，MySQL將進行一次fsync之類的磁盤同步指令來將binlog_cache中的數據強制寫入磁盤。
#在MySQL中系統默認的設置是sync_binlog=0，也就是不做任何強制性的磁盤刷新指令，這時候的性能是最好的，但是風險也是最大的。
#因爲一旦系統Crash，在binlog_cache中的所有binlog信息都會被丟失。而當設置爲“1”的時候，是最安全但是性能損耗最大的設置。因爲當設置爲1的時候，即使系統Crash，也最多丟失binlog_cache中未完成的一個事務，對實際數據沒有任何實質性影響。從以往經驗和相關測試來看，對於高併發事務的系統來說，“sync_binlog”設置爲0和設置爲1的系統寫入性能差距可能高達5倍甚至更多。
sync_binlog = 4
#啓用gtid類型，否則就是普通的複製架構
gtid_mode = on
#強制GTID的一致性
enforce_gtid_consistency = 1
#slave更新是否記入日誌，在做雙主架構時異常重要，影響到雙主架構是否能互相同步
log_slave_updates
#binlog日誌格式，可選值“MIXED”、“ROW”、“STATEMENT”，在5.6版本之前默認爲“STATEMENT”，5.6之後默認爲“MIXED”；因爲“STATEMENT”方式在處理一些“不確定”性的方法時會造成數據不一致問題，我們建議使用“MIXED”或者“ROW”
binlog_format = row
#slave保存同步中繼日誌的位置
relay_log = /data/local/mysql-5.7.19/log/mysql-relay.log
#當slave從庫宕機後，假如relay-log損壞了，導致一部分中繼日誌沒有處理，則自動放棄所有未執行的relay-log，並且重新從master上獲取日誌，這樣就保證了relay-log的完整性
relay_log_recovery = 1
#這個參數控制了當mysql啓動或重啓時，mysql在搜尋GTIDs時是如何迭代使用binlog文件的。 這個選項設置爲真，會提升mysql執行恢復的性能。因爲這樣mysql-server啓動和binlog日誌清理更快
binlog_gtid_simple_recovery = 1
#跳過指定error no類型的錯誤，設成all 跳過所有錯誤
slave_skip_errors = ddl_exist_errors
##########################InnoDB存儲引擎相關###############################
#innodb每個數據頁大小，這個參數在一開始初始化時就要加入my.cnf裏，如果已經創建了表，再修改，啓動MySQL會報錯
innodb_page_size = 16K
#緩存innodb表的索引，數據，插入數據時的緩衝，專用mysql服務器設置的大小： 操作系統內存的70%-80%最佳
innodb_buffer_pool_size = 4G
#可以開啓多個內存緩衝池，把需要緩衝的數據hash到不同的緩衝池中，這樣可以並行的內存讀寫
innodb_buffer_pool_instances = 8
#默認爲關閉OFF。如果開啓該參數，啓動MySQL服務時，MySQL將本地熱數據加載到InnoDB緩衝池中
innodb_buffer_pool_load_at_startup = 1
#默認爲關閉OFF。如果開啓該參數，停止MySQL服務時，InnoDB將InnoDB緩衝池中的熱數據保存到本地硬盤
innodb_buffer_pool_dump_at_shutdown = 1
#根據 官方文檔 描述，它會影響page cleaner線程每次刷髒頁的數量， 這是一個每1秒 loop一次的線程
innodb_lru_scan_depth = 2000
#事務等待獲取資源等待的最長時間，超過這個時間還未分配到資源則會返回應用失敗；參數的時間單位是秒
innodb_lock_wait_timeout = 5
#這兩個設置會影響InnoDB每秒在後臺執行多少操作. 大多數寫IO(除了寫InnoDB日誌)是後臺操作的. 如果你深度瞭解硬件性能(如每秒可以執行多少次IO操作),則使用這些功能是很可取的,而不是讓它閒着
innodb_io_capacity = 4000
innodb_io_capacity_max = 8000
#默認值爲 fdatasync. 如果使用 硬件RAID磁盤控制器, 可能需要設置爲 O_DIRECT. 這在讀取InnoDB緩衝池時可防止“雙緩衝(double buffering)”效應,否則會在文件系統緩存與InnoDB緩存間形成2個副本(copy). 如果不使用硬件RAID控制器,或者使用SAN存儲時, O_DIRECT 可能會導致性能下降
innodb_flush_method = O_DIRECT
#innodb重做日誌保存目錄
innodb_log_group_home_dir = 自定義
#innodb回滾日誌保存目錄
innodb_undo_directory = 自定義
#undo回滾段的數量， 至少大於等於35，默認128
innodb_undo_logs = 128
#用於設定創建的undo表空間的個數，在mysql_install_db時初始化後，就再也不能被改動了；默認值爲0，表示不獨立設置undo的tablespace，默認記錄到ibdata中；否則，則在undo目錄下創建這麼多個undo文件，例如假定設置該值爲4，那麼就會創建命名爲undo001~undo004的undo tablespace文件，每個文件的默認大小爲10M。修改該值會導致Innodb無法完成初始化，數據庫無法啓動，但是另兩個參數可以修改
innodb_undo_tablespaces = 0
#InnoDB存儲引擎在刷新一個髒頁時，會檢測該頁所在區(extent)的所有頁，如果是髒頁，那麼一起刷新。這樣做的好處是通過AIO可以將多個IO寫操作合併爲一個IO操作。對於傳統機械硬盤建議使用，而對於固態硬盤可以關閉。
innodb_flush_neighbors = 1
#這個值定義了日誌文件的大小，innodb日誌文件的作用是用來保存redo日誌。一個事務對於數據或索引的修改往往對應到表空間中的隨機的位置，因此當刷新這些修改到磁盤中就會引起隨機的I/O，而隨機的I/O往往比順序的I/O更加昂貴的開銷，因爲隨機的I/O需要更多的開銷來定位到指定的位置。innodb使用日誌來將隨機的I/O轉爲順序的I/O，只要日誌文件是安全的，那麼事務就是永久的，儘管這些改變還沒有寫到數據文件中，如果出現了當機或服務器斷電的情況，那麼innodb也可以通過日誌文件來恢復以及提交的事務。但是日誌文件是有一定的大小的，所以必須要把日誌文件記錄的改變寫到數據文件中，innodb對於日誌文件的操作是循環的，即當日志文件寫滿後，會將指針重新移動到文件開始的地方重新寫，但是它不會覆蓋那些還沒有寫到數據文件中的日誌，因爲這是唯一記錄了事務持久化的記錄
#如果對 Innodb 數據表有大量的寫入操作，那麼選擇合適的 innodb_log_file_size 值對提升MySQL性能很重要。然而設置太大了，就會增加恢復的時間，因此在MySQL崩潰或者突然斷電等情況會令MySQL服務器花很長時間來恢復
innodb_log_file_size = 4G
#事務在內存中的緩衝。 分配原 則：控制在2-8M.這個值不用太多的。他裏面的內存一般一秒鐘寫到磁盤一次
innodb_log_buffer_size = 16M
#控制是否使用，使用幾個獨立purge線程（清除二進制日誌）
innodb_purge_threads = 4
#mysql在5.6之前一直都是單列索引限制767，起因是256×3-1。這個3是字符最大佔用空間（utf8）。但是在5.6以後，開始支持4個字節的uutf8。255×4>767, 於是增加了這個參數。這個參數默認值是OFF。當改爲ON時，允許列索引最大達到3072
innodb_large_prefix = 1
#InnoDB kernel併發最大的線程數。 1) 最少設置爲(num_disks+num_cpus)*2。 2) 可以通過設置成1000來禁止這個限制
innodb_thread_concurrency = 64
#是否將死鎖相關信息保存到MySQL 錯誤日誌中
innodb_print_all_deadlocks = 1
#開啓InnoDB嚴格檢查模式，尤其採用了頁數據壓縮功能後，最好是開啓該功能。開啓此功能後，當創建表（CREATE TABLE）、更改表（ALTER TABLE）和創建索引（CREATE INDEX）語句時，如果寫法有錯誤，不會有警告信息，而是直接拋出錯誤，這樣就可直接將問題扼殺在搖籃裏
innodb_strict_mode = 1
#ORDER BY 或者GROUP BY 操作的buffer緩存大小
innodb_sort_buffer_size = 64M
##########################插件相關###############################
#指定mysql的插件目錄
plugin_dir=/data/local/mysql-5.7.19/lib/plugin
#指定載入哪些插件
plugin_load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"
#控制主庫上是否開啓semisync
loose_rpl_semi_sync_master_enabled = 1
#控制備庫是否開啓semisync
loose_rpl_semi_sync_slave_enabled = 1
#單位毫秒，防止半同步複製在沒有收到確認的情況下，發送堵塞。master在超時之前沒有收到確認，將恢復到異步複製，繼續執行半同步沒有進行的操作
loose_rpl_semi_sync_master_timeout = 5000
##########################mysql5.7專屬###############################
#表示轉儲每個bp instance LRU上最熱的page的百分比。通過設置該參數可以減少轉儲的page數
innodb_buffer_pool_dump_pct = 40
#爲了提升擴展性和刷髒效率，在5.7.4版本里引入了多個page cleaner線程。從而達到並行刷髒的效果
#在該版本中，Page cleaner並未和buffer pool綁定，其模型爲一個協調線程 + 多個工作線程，協調線程本身也是工作線程。因此如果innodb_page_cleaners設置爲8，那麼就是一個協調線程，加7個工作線程
innodb_page_cleaners = 4
#是否開啓在線回收（收縮）undo log日誌文件，支持動態設置
innodb_undo_log_truncate = 1
#當超過這個閥值（默認是1G），會觸發truncate回收（收縮）動作，truncate後空間縮小到10M
innodb_max_undo_log_size = 2G
#控制回收（收縮）undo log的頻率。undo log空間在它的回滾段沒有得到釋放之前不會收縮， 想要增加釋放回滾區間的頻率，就得降低設定值
innodb_purge_rseg_truncate_frequency = 128
#這個參數控制了當mysql啓動或重啓時，mysql在搜尋GTIDs時是如何迭代使用binlog文件的。 這個選項設置爲真，會提升mysql執行恢復的性能。因爲這樣mysql-server啓動和binlog日誌清理更快。該參數爲真時，mysql-server只需打開最老的和最新的這2個binlog文件
binlog_gtid_simple_recovery=1
#在MySQL 5.7.2 新增了 log_timestamps 這個參數，該參數主要是控制 error log、genera log，等等記錄日誌的顯示時間參數。 在 5.7.2 之後改參數爲默認 UTC 這樣會導致日誌中記錄的時間比中國這邊的慢，導致查看日誌不方便。修改爲 SYSTEM 就能解決問題
log_timestamps=system
#這個神奇的參數5.7.6版本引入，用於定義一個記錄事務的算法，這個算法使用hash標識來記錄事務。如果使用MGR，那麼這個hash值需要用於分佈式衝突檢測何處理，在64位的系統，官網建議設置該參數使用 XXHASH64 算法。如果線上並沒有使用該功能，應該設爲off
transaction_write_set_extraction=MURMUR32
#從mysql5.7.6開始information_schema.global_status已經開始被捨棄，爲了兼容性，此時需要打開 show_compatibility_56
show_compatibility_56=on