MySQL配置文件

時間 2019-11-18

原文原文鏈接

MySQL的配置文件須要根據版本及實際狀況進行相應配置，本人使用的是Percona版本，主要是用到線程池等功能，因此選擇Percona版本，配置文件內容以下，大部分參數信息我參考了相關資料作了說明，若有不當之處歡迎你們來指正。mysql

[mysqld]

######################################################################################################################3
#file config
######################################################################################################################3
pid-file=/data/mysql/mysql3307/tmp/mysqld.pid
basedir=/usr/local/mysql
datadir=/data/mysql/mysql3307/data
socket=/data/mysql/mysql3307/tmp/mysql.sock
user=mysql
port=3306

#Disabling symbolic-links is recommended to prevent assorted security risks
symbolic-links=0
back_log = 500
######################################################################################################################
#back_log值指出在mysql暫時中止回答新請求以前的短期內多少個請求能夠被存在堆棧中。也就是說，若是MySql的鏈接數
#達到max_connections時，新來的請求將會被存在堆棧中，以等待某一鏈接釋放資源，該堆棧的數量即back_log，若是等待鏈接的數量
#超過back_log，將不被授予鏈接資源。將會報：unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login | NULL
#的待鏈接進程時.back_log值不能超過TCP/IP鏈接的偵聽隊列的大小。若超過則無效，查看當前系統的TCP/IP鏈接的偵聽隊列的大小
#命令：cat /proc/sys/net/ipv4/tcp_max_syn_backlog，目前系統爲1024。對於Linux系統推薦設置爲大於512的整數
#######################################################################################################################
server-id=394406
skip-name-resolve=1 # 跳過域名解析
character_set_server=utf8
max_connections = 1000
max_connect_errors = 100 ##max_connect_errors是一個MySQL中與安全有關的計數器值，它負責阻止過多嘗試失敗的客戶端以防止暴力破解密碼的狀況。max_connect_errors的值與性能並沒有太大關係
interactive_timeout=600 #服務器關閉交互式鏈接前等待活動的秒數,同時設置interactive_timeout和wait_timeout纔會生效
wait_timeout=600 # 服務器關閉非交互鏈接以前等待活動的秒數。
          #長時間的執行批量的MYSQL語句。最多見的就是採集或者新舊數據轉化
event_scheduler=1 #開啓事件調度器,0 off 1 on
explicit_defaults_for_timestamp #顯示指定默認值爲timestamp類型的字段 http://www.jb51.net/article/71105.htm
log_timestamps=SYSTEM ##5.7.2新增參數log_timestamps 參數默認使用 UTC 時區，這樣會使得日誌中記錄的時間比中國這邊的慢了 8 個小時，致使查看日誌不方便。修改成 SYSTEM 就能解決問題
sql_mode='' #sql_mode是個很容易被忽視的變量，默認值是空值，在這種設置下是能夠容許一些非法操做的，好比容許一些非法數據的插入。在生產環境必須將這個值設置爲嚴格模式，因此開發、測試環境的數據庫也必需要設置，這樣在開發測試階段就能夠發現問題
######################################################################################################################
#若是使用mysql，爲了繼續保留你們使用oracle的習慣，能夠對mysql的sql_mode設置以下：
#在my.cnf添加以下配置
#[mysqld]
#sql_mode='ONLY_FULL_GROUP_BY,NO_AUTO_VALUE_ON_ZERO,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,
#ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION,PIPES_AS_CONCAT,ANSI_QUOTES'
######################################################################################################################
default_storage_engine=innodb

slow_query_log=1;#經過使用--slow_query_log[={0|1}]選項來啓用慢查詢日誌。全部執行時間超過long_query_time秒(缺省值爲10s)的SQL語句都會被記錄到慢查詢日誌
long_query_time = 600 #slow_query_log 這句是開啓記錄慢查詢功能，slow_query_log=0關閉；slow_query_log=1開啓（這個1能夠不寫）
                      #long_query_time = 1 這句是記錄超過1秒的SQL執行語句
slow_query_log_file='/data/mysql/mysql3307/data/DBDWARE01-slow.log'
log_error_verbosity=1 #全局動態變量，默認3，範圍：1～3。表示錯誤日誌記錄的信息，1：只記錄error信息；2：記錄error和warnings信息；3：記錄error、warnings和普通的notes信息。
#slow_launch_time=2 #slow_launch_time的設定跟慢查詢日誌的查詢閥值設定不一樣，表示了thread create的一個閥值，若是thread create的時間超過了這個值，這變量slow_launch_time的值加1

myisam_repair_threads=2 # 若是該值大於1，在Repair by sorting過程當中並行建立MyISAM表索引(每一個索引在本身的線程內)
myisam_recover_options=FORCE #myisam_recover_options=force，那麼即便此時key cache不存在了也會進行強制修復，此時作的就是對比數據文件和索引文件，而後刪除數據文件中多餘的行，所以這樣可能會丟數據
                 #配置了參數myisam_recover_options=default，這個配置表示每次訪問MyISAM表以前都會先檢測表是否須要修復，若是須要則自動進行，這也就是前面看到信息last (automatic?) repair failed。而修復失敗是由於這個參數帶來的修復行爲默認是從key cache裏面找須要修復的數據，而我當時是shutdown實例，rsync到新環境中起實例，此時已沒有當時的現場(key cache環境)，加上default不會強制進行修復（強制修復表若是索引文件和數據文件數據不一致則自動進行刪除或者增長行），（若是是myisam_recover_options=force，那麼即便此時key cache不存在了也會進行強制修復，此時作的就是對比數據文件和索引文件，而後刪除數據文件中多餘的行，所以這樣可能會丟數據）

######################################################################################################################3
#memory config
######################################################################################################################3
table_open_cache = 10000 #MYSQL默認的table_open_cache爲64，這個數值是偏小的，若是max_connections較大，則容易引發性能問題。
           #表現：數據庫查詢效率慢，show processlist 發現比較多的查詢正在opening table。
max_allowed_packet = 16M #用來控制其通訊緩衝區的最大長度，解決執行一個SQL，但SQL語句過大或者語句中含有BLOB或者longblob字段。好比，圖片數據的處理
max_heap_table_size = 64M #這個變量定義了用戶能夠建立的內存表的大小，這個值用來計算內存表的最大行數值
tmp_table_size = 1073741824   #copy to tmp talbe 語句產生的緣由是查詢須要Order By 或者Group By等須要用到結果集時，
                                #參數中設置的臨時表的大小小於結果集的大小時，就會將該表放在磁盤上，這個時候在硬盤上的IO
               #要比內銷差不少。所耗費的時間也多不少。另外Mysql的另一個參數max_heap_table_size
               #比tmp_table_size小時，則系統會把max_heap_table_size的值做爲最大的內存臨時表的上限，
               #大於這個時，改寫硬盤
sort_buffer_size = 50M #你能夠考慮增長sort_buffer_size 來加速ORDER BY 或者GROUP BY 操做,不能經過查詢或者索引優化的。
                       #在任何狀況下, 設置它大於須要的全局會減慢不少的查詢。最後是做爲一個會話設置來增長,
                       #只有對須要大量的內存的會話, 在Linux上,有閥值爲256KB 和2MB ,大的值可能顯著的減慢內存分配
join_buffer_size = 50M #若是應用中，不多出現join語句，則能夠不用太在意join_buffer_size參數的設置大小。
                       #若是join語句不是不多的話，我的建議能夠適當增大join_buffer_size到1MB左右，若是內存充足能夠設置爲2MB
thread_cache_size = 8 #根據物理內存設置規則以下1G —> 8, 2G —> 16 ,3G —> 32 ,>3G —> 64

# thread_concurrency = 8
ft_min_word_len = 2 #中文分詞，ft_min_word_len設置爲2，調用'repair table your_table quick',修復索引。相比方案2，此方案較節省空間。對於主要使用中文的系統而言，此方案更佳
memlock #服務器是否鎖定在內存中
default-storage-engine = MyISAM
thread_stack = 192K   #每一個鏈接線程被建立時,MySQL給它分配的內存大小.當MySQL建立一個新的鏈接線程時,須要給它分配必定大小的
           #內存堆棧空間，以便存放客戶端的請求的Query及自身的各類狀態和處理信息。
transaction_isolation = REPEATABLE-READ ##事務隔離級別，全局默認是REPEATABLE-READ,其實MySQL原本默認也是這個級別

key_buffer_size = 1024M   #這個參數是用來設置索引塊(index blocks)緩存的大小,它被全部線程共享,嚴格說是它決定了數據庫索引處理的速度
                        #尤爲是索引讀的速度。那咱們怎麼才能知道key_buffer_size的設置是否合理呢，通常能夠
           #檢查狀態值Key_read_requests和Key_reads，比例key_reads / key_read_requests應該儘量的低，
           #好比1:100，1:1000 ，1:10000。其值能夠用以i下命令查得：mysql> show status like 'key_read%';
read_buffer_size = 2M   # MySQL讀入緩衝區大小。對錶進行順序掃描的請求將分配一個讀入緩衝區，MySQL會爲它分配一段內存緩衝區。read_buffer_size變量控制這一緩衝區的大小。
                        # 若是對錶的順序掃描請求很是頻繁，而且你認爲頻繁掃描進行得太慢，能夠經過增長該變量值以及內存緩衝區大小提升其性能
read_rnd_buffer_size = 16M #MySql的隨機讀（查詢操做）緩衝區大小.當按任意順序讀取行時(例如,按照排序順序),將分配一個隨機讀緩存區。
                           #進行排序查詢時，MySql會首先掃描一遍該緩衝，以免磁盤搜索，提升查詢速度，若是須要排序大量數據，
               #可適當調高該值。但MySql會爲每一個客戶鏈接發放該緩衝空間，因此應儘可能適當設置該值，以免內存開銷過大。
bulk_insert_buffer_size = 4294967296 #批量插入數據緩存大小，能夠有效提升插入效率，默認爲8M
myisam_sort_buffer_size = 128M #MyISAM表發生變化時從新排序所需的緩衝
myisam_max_sort_file_size = 10G   # MySQL重建索引時所容許的最大臨時文件的大小 (當 REPAIR, ALTER TABLE 或者 LOAD DATA INFILE).
                                # 若是文件大小比此值更大,索引會經過鍵值緩衝建立(更慢)
myisam_repair_threads = 1   # 若是一個表擁有超過一個索引, MyISAM 能夠經過並行排序使用超過一個線程去修復他們.
                                # 這對於擁有多個CPU以及大量內存狀況的用戶,是一個很好的選擇
#myisam_recover

######################################################################################################################3
#innodb config
######################################################################################################################3
innodb_buffer_pool_size = 40G   #這對Innodb表來講很是重要。Innodb相比MyISAM表對緩衝更爲敏感。MyISAM能夠在默認的 key_buffer_size 設置下運行的能夠，
#然而Innodb在默認的 innodb_buffer_pool_size 設置下卻跟蝸牛似的。因爲Innodb把數據和索引都緩存
               #起來，無需留給操做系統太多的內存，所以若是隻須要用Innodb的話則能夠設置它高達 70-80% 的可用內存。
               #一些應用於 key_buffer 的規則有 — 若是你的數據量不大，而且不會暴增，
               #那麼無需把 innodb_buffer_pool_size 設置的太大了
innodb_data_file_path = ibdata1:10M:autoextend    #數據文件配置,共享表空間地址及初始化大小，自動擴展屬性
innodb_read_io_threads=8
innodb_write_io_threads=8        # innodb_read_io_threads innodb_write_io_threads 多核cpu能夠經過這兩個參數更有效的利用cpu性能
innodb_thread_concurrency = 16   # 調節併發線程數的限制值
innodb_flush_log_at_trx_commit = 2
## innodb_flush_log_at_trx_commit ##
# 0：log buffer將每秒一次地寫入log file中，而且log file的flush(刷到磁盤)操做同時進行。該模式下在事務提交的時候，不會主動觸發寫入磁盤的操做。
#1：每次事務提交時MySQL都會把log buffer的數據寫入log file，而且flush(刷到磁盤)中去，該模式爲系統默認。
#2：每次事務提交時MySQL都會把log buffer的數據寫入log file，可是flush(刷到磁盤)操做並不會同時進行。該模式下，MySQL會每秒執行一次 flush(刷到磁盤)操做
innodb_log_buffer_size = 8M   # InnoDB的寫操做，將數據寫入到內存中的日誌緩存中，因爲InnoDB在事務提交前，並不將改變的日誌寫入到磁盤中，所以在大事務中，能夠減輕磁盤I/O的壓力。一般狀況下，若是不是寫入大量的超大二進制數據（a lot of huge blobs），4MB-8MB已經足夠了
innodb_max_dirty_pages_pct = 75 # 關於innodb_max_dirty_pages_pct值的爭議，若是值過大，內存也很大或者服務器壓力很大，那麼效率很下降，若是設置的值太小，那麼硬盤的壓力會增長，建議是在75-80.而且innodb plugin引進了innodb_adaptive_flushng(自適應的刷新)，該值影響每秒刷新髒頁的數量
innodb_flush_method = O_DIRECT
##innodb_flush_method這個參數控制着innodb數據文件及redo log的打開、刷寫模式，對於這個參數，文檔上是這樣描述的：
#有三個值：fdatasync(默認)，O_DSYNC，O_DIRECT
#默認是fdatasync，調用fsync()去刷數據文件與redo log的buffer
#爲O_DSYNC時，innodb會使用O_SYNC方式打開和刷寫redo log,使用fsync()刷寫數據文件
#爲O_DIRECT時，innodb使用O_DIRECT打開數據文件，使用fsync()刷寫數據文件跟redo log

innodb_lock_wait_timeout = 120 # innodb_lock_wait_timeout指的是事務等待獲取資源等待的最長時間，超過這個時間還未分配到資源則會返回應用失敗；參數的時間單位是秒，最小可設置爲1s(此時須要考慮應用端的頻繁異常處理會消耗性能，不能設置太小)，最大可設置1073741824秒以上
innodb_buffer_pool_instances=8 #當 innodb_buffer_pool_size 設置的大於 1GB 之後那麼此參數設置就尤其重要了,   MySQL 5.6.6開始此參數默認爲 8, 主要目的是爲了解決互斥鎖, 每一個緩衝池管理其本身的空閒列表,提升查詢併發性, 對於互斥鎖能夠自行補腦吧,若是innodb_buffer_pool_size大於1.3GB，則innodb_buffer_pool_instances的默認值爲innodb_buffer_pool_size/ 128MB   即大體爲 10 左右.每一個實例具備獨立的緩存區塊
innodb_page_cleaners=8 # 爲了提高擴展性和刷髒效率，在5.7.4版本里引入了多個page cleaner線程。從而達到並行刷髒的效果。
                        # 在該版本中，Page cleaner並未和buffer pool綁定，其模型爲一個協調線程 + 多個工做線程，協調線程自己也是工做線程。所以若是innodb_page_cleaners設置爲8，那麼就是一個協調線程，加7個工做線程
#innodb_force_recovery=1

######################################################################################################################3
#log file config
######################################################################################################################3
expire_logs_days=30
innodb_log_files_in_group=5
innodb_log_file_size=500m
binlog_format=row
log_bin=on
log_bin=/data/mysql/mysql3307/logs/mysql-bin
log_bin_index=/data/mysql/mysql3307/logs/mysql-bin.index

######################################################################################################################3
#replication config
######################################################################################################################3
#slave_parallel_type=LOGICAL_CLOCK
slave-parallel-workers=0   # MySQL 5.6版本也支持所謂的並行複製，可是其並行只是基於schema的，也就是基於庫的。若是用戶的MySQL數據庫實例中存在多個schema，對於從機複製的速度的確能夠有比較大的幫助
master_info_repository=table # 從機把主的信息存在主信息倉庫裏。主信息庫能夠是文件也能夠上表，具體由—master-info-repository參數值決定。—master-info-repository＝file時會生成master.info 和 relay-log.info2個文件，若是—master-info-repository＝table，信息就會存在mysql.master_slave_info表中。無論是設置的哪一種值，都不要移動或者編輯相關的文件和表。想要更改配置經過再次執行change master to …語句，變動會自動保存到相關的文件和表。這個配置對應的表或者文件裏的內容會覆蓋某些命令行或者my.cnf中的配置
relay_log_info_repository=table # 建議將其修改成TABLE，由於1.relay.info明文存儲不安全，把relay.info中的信息記錄在table中相對安全。
                                # 2.能夠避免relay.info更新不及時，SLAVE 重啓後致使的主從複製出錯
relay_log_recovery=on # 當slave從庫宕機後，假如relay-log損壞了，致使一部分中繼日誌沒有處理，則自動放棄全部未執行的relay-log，而且從新從master上獲取日誌，這樣就保證了relay-log的完整性。默認狀況下該功能是關閉的，將relay_log_recovery的值設置爲 1時，可在slave從庫上開啓該功能，建議開啓
relay_log_purge=on # 有時候，咱們但願將 MySQL 的 relay log 多保留一段時間，好比用於高可用切換後的數據補齊，因而就會設置 relay_log_purge=0，禁止 SQL 線程在執行完一個 relay log 後自動將其刪除，但會有風險
##### 風險
## 首先，爲了讓從庫是 crash safe 的，必須設置 relay_log_recovery=1，這個選項的做用是，在 MySQL 崩潰或人工重啓後，因爲 IO 線程沒法保證記錄的從主庫讀取的 binlog 位置的正確性，所以，就無論 master_info 中記錄的位置，而是根據 relay_log_info 中記錄的已執行的 binlog 位置從主庫下載，並讓 SQL 線程也從這個位置開始執行。MySQL 啓動時，至關於執行了 flush logs ，會新開一個 relay log 文件，新的 relay log 會記錄在新的文件中。若是默認狀況 relay_log_purge=1 時，SQL 線程就會自動將以前的 relay log 所有刪除。而當 relay_log_purge=0 時，舊的 relay log 則會被保留。雖然這並不會影響從庫複製自己，但仍是會有地雷：
##    因爲崩潰或中止 MySQL 時，SQL 線程可能沒有執行徹底部的 relay log，最後一個 relay log 中的一部分數據會被從新下載到新的文件中。也就是說，這部分數據重複了兩次。
##    若是 SQL 跟得很緊，則可能在 IO 線程寫入 relay log ，但尚未將同步到磁盤時，就已經讀取執行了。這時，就會形成新的文件和舊的文件中少了一段數據。
##   若是咱們讀取 relay log 來獲取數據，必須注意這一點，不然就會形成數據不一致。而保留 relay log 的目的也在於此。所以，在處理 relay log 時必須格外當心，經過其中 binlog 頭信息來確保正確性。
#####
slave_preserve_commit_order=1 # 對於多線程slaves，來保障事務在slave上執行的順序與relay log中的順序嚴格一致，只有當「slave_parallel_workers」開啓時有效；此時「log_bin」、「log_slave_updates」必須開啓，並且「slave_parallel_type」值必須爲「LOGICAL_CLOCK」（默認值爲DATABASE）。即當多線程開啓時，且根據relay log中事務的邏輯順序執行statements，是否須要嚴格保持順序，默認值爲0表示併發執行忽略順序

slave_skip_errors=1032,1062 ## 若有須要再添加，指跳過從庫部分錯誤，1032表明當delete數據是從庫不存在的報錯信息 1062爲重複

[mysqld_safe]
log-error=/data/mysql/mysql3307/logs/mysqld.log
pid-file=/data/mysql/mysql3307/tmp/mysqld.pid

[client]
socket = /data/mysql/mysql3307/tmp/mysql.sock

[mysql]
prompt=\\u@\\d \\r:\\m:\\s>sql

################################### 華麗的分割線 ############################################數據庫

下面奉上姜老師推薦的配置緩存

[client]
user=david
password=88888888

[mysqld]

########basic settings########

server-id = 11 
port = 3306
user = mysql
bind_address = 10.166.224.32 #根據實際狀況修改
autocommit = 0 #5.6.X安裝時，須要註釋掉，安裝完成後再打開
character_set_server=utf8mb4
skip_name_resolve = 1
max_connections = 800
max_connect_errors = 1000
datadir = /data/mysql_data #根據實際狀況修改,建議和程序分離存放
transaction_isolation = READ-COMMITTED
explicit_defaults_for_timestamp = 1
join_buffer_size = 134217728
tmp_table_size = 67108864
tmpdir = /tmp
max_allowed_packet = 16777216
sql_mode = "STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION,NO_ZERO_DATE,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER"
interactive_timeout = 1800
wait_timeout = 1800
read_buffer_size = 16777216
read_rnd_buffer_size = 33554432
sort_buffer_size = 33554432

########log settings########

log_error = error.log
slow_query_log = 1
slow_query_log_file = slow.log
log_queries_not_using_indexes = 1
log_slow_admin_statements = 1
log_slow_slave_statements = 1
log_throttle_queries_not_using_indexes = 10
expire_logs_days = 90
long_query_time = 2
min_examined_row_limit = 100

########replication settings########

master_info_repository = TABLE
relay_log_info_repository = TABLE
log_bin = bin.log
sync_binlog = 1
gtid_mode = on
enforce_gtid_consistency = 1
log_slave_updates
binlog_format = row 
relay_log = relay.log
relay_log_recovery = 1
binlog_gtid_simple_recovery = 1
slave_skip_errors = ddl_exist_errors

########innodb settings########

innodb_page_size = 8192
innodb_buffer_pool_size = 6G #根據實際狀況修改
innodb_buffer_pool_instances = 8
innodb_buffer_pool_load_at_startup = 1
innodb_buffer_pool_dump_at_shutdown = 1
innodb_lru_scan_depth = 2000
innodb_lock_wait_timeout = 5
innodb_io_capacity = 4000
innodb_io_capacity_max = 8000
innodb_flush_method = O_DIRECT
innodb_file_format = Barracuda
innodb_file_format_max = Barracuda
innodb_log_group_home_dir = /redolog/ #根據實際狀況修改
innodb_undo_directory = /undolog/ #根據實際狀況修改
innodb_undo_logs = 128
innodb_undo_tablespaces = 3
innodb_flush_neighbors = 1
innodb_log_file_size = 4G #根據實際狀況修改
innodb_log_buffer_size = 16777216
innodb_purge_threads = 4
innodb_large_prefix = 1
innodb_thread_concurrency = 64
innodb_print_all_deadlocks = 1
innodb_strict_mode = 1
innodb_sort_buffer_size = 67108864 

########semi sync replication settings########

plugin_dir=/usr/local/mysql/lib/plugin #根據實際狀況修改
plugin_load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"
loose_rpl_semi_sync_master_enabled = 1
loose_rpl_semi_sync_slave_enabled = 1
loose_rpl_semi_sync_master_timeout = 5000

[mysqld-5.7]
innodb_buffer_pool_dump_pct = 40
innodb_page_cleaners = 4
innodb_undo_log_truncate = 1
innodb_max_undo_log_size = 2G
innodb_purge_rseg_truncate_frequency = 128
binlog_gtid_simple_recovery=1
log_timestamps=system
transaction_write_set_extraction=MURMUR32
show_compatibility_56=on