【規范2】數據庫管理規范
一、安裝部署規范
單機+主從+集群(建議8.0版本用InnoDB Cluster) 后續完善
二、參數配置
#*** Client Options相關選項 ***#
#以下選項會被MySQL客戶端應用讀取，即MySQL附帶的客戶端應用程序可以讀取。
[client]
port=3306
socket=/data/mysql57/socket/mysql.sock
[mysql]
prompt="\\u@\\h :\\d \\R:\\m:\\s>" 設置命令行提示符
no-auto-rehash 確保數據庫服務啟動得比較快，數據庫有許多表,列有很多列.命令行mysql客戶端連接需要很長時間，除非使用-A
[mysqld]
user=mysql
port=3306
server-id=13306 數據庫唯一序號，建議ip最后一位+端口號
basedir=/usr/local/mysql57
datadir=/data/mysql57/data
tmpdir=/data/mysql57/tmp 此目錄被 MySQL用來保存臨時文件.例如,它被用來處理基於磁盤的大型排序,和內部排序一樣，以及簡單的臨時表。
socket=/data/mysql57/socket/mysql.sock
pid-file=hostname.pid
slave_load_tmpdir=/path/tmp 全局靜態參數，默認/tmp
。當slave執行load data infile 時用。
character-set-server=utf8mb4 全局會話級動態參數，5.7默認為latin1，8.0默認為utf8mb4。服務器的默認字符集。建議使用utf8mb4，為utf8的超集。
default_time_zone="+8:00" 設置默認服務器時區。此選項設置全局time_zone系統變量。如果未設置，則默認時區與系統時區相同（為system_time_zone系統變量的值）。如果MySQL數據庫主要運行在境外，請務必根據實際情況調整本參數。system_time_zone=CST，CST被視為美國、澳大利亞、古巴或中國的標准時間。GMT被視為世界時UT， 即格林尼治平太陽時間，指格林尼治所在地的標准時間。
open_files_limit=65535 全局靜態參數，默認值5000。用於mysqld可打開的文件描述符的數量。如果無法分配請求的文件描述符數量，mysqld將警告寫入錯誤日志，mysqld報錯Too many open files，應該嘗試增大該值。當open_files_limit沒有被配置的時候，比較max_connections*5和ulimit-n的值，哪個大用哪個，當open_file_limit被配置的時候，比較open_files_limit和max_connections*5的值，哪個大用哪個。最大值取決於系統配置，在Unix上，該值不能設置為大於ulimit -n。在/etc/security/limits.conf配置MySQL打開的文件數。
transaction_isolation=REPEATABLE-READ 全局會話級動態參數，默認為RR。設定默認的事務隔離級別.可用的級別如下:READ-UNCOMMITTED, READ-COMMITTED, REPEATABLE-READ,SERIALIZABLE.1.READ UNCOMMITTED-讀未提交 2.READ COMMITTE-讀已提交 3.REPEATABLE READ-可重復讀 4.SERIALIZABLE-串行。
lower_case_table_names=1 全局靜態參數，默認為2。設置為0，則按指定存儲表名，並且區分大小寫。設置為1，則表名以小寫形式存儲在磁盤上，並且不區分大小寫。設置為2，則表名按給定方式存儲，但以小寫形式進行比較。此選項也適用於數據庫名稱和表別名。
lower_case_file_system=ON 全局靜態參數。描述了數據目錄所在文件系統上文件名的大小寫敏感性。OFF表示文件名區分大小寫，ON表示它們不區分大小寫。該變量是只讀的，因為它反映了文件系統屬性，並且設置它不會對文件系統產生影響。為只讀參數，不允許修改。
#*** Skip Options相關選項 ***#
skip_name_resolve=on 全局靜態參數，默認值為OFF。該變量是根據 --skip-name-resolve選項的值設置的。如果是OFF，mysqld在檢查客戶端連接時解析主機名。如果是ON，mysqld只使用IP號碼；在這種情況下，Host授權表中的所有列值必須是IP地址或localhost。
skip-external-locking=on 全局靜態參數，默認為on。不使用系統鎖定，要使用 myisamchk,必須關閉服務器 ,避免 MySQL的外部鎖定，減少出錯幾率增強穩定性。
skip-networking=off 全局靜態參數。開啟該選項可以徹底關閉 MySQL 的 TCP/IP 連接方式，如果 WEB 服務器是以遠程連接的方式訪問 MySQL 數據庫服務器則不要開啟該選項！否則將無法正常連接！ 如果所有的進程都是在同一台服務器連接到本地的 mysqld, 這樣設置將是增強安全的方法
#*** 系統資源相關選項 ***#
back_log=1024 全局靜態參數，默認值-1。在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的整數。修改系統內核參數，可以編輯/etc/sysctl.conf去調整它。如：net.ipv4.tcp_max_syn_backlog = 2048，改完后執行sysctl -p 讓修改立即生效。
max_connections=1000 全局動態參數，默認值151。同時連接到數據庫服務器允許的最大客戶端進程連接數。有Too Many Connections 的錯誤提示，則需要增大此值。達到max_connections限制而被拒絕的連接，會增加Connection_errors_max_connections狀態變量。mysqld實際上允許max_connections+1客戶端連接。給具有特權的賬號保留了一個連接，用於超過max_connections參數限制后，還可以連接數據庫進行SHOW PROCESSLIST，排查問題。
max_connect_errors=1000000 全局動態參數，默認100。如果來自主機的連續連接請求超過此數量而沒有成功連接而中斷，則服務器會阻止該主機進一步連接。可以通過刷新主機緩存來解除阻塞的主機。如果max_connect_errors 在前一個連接中斷后的幾次嘗試中成功建立連接，則主機的錯誤計數清零。但是，一旦主機被阻塞，刷新主機緩存是解除阻塞的唯一方法，執行FLUSH HOSTS語句或執行mysqladmin flush-hosts 命令。
max_user_connections=1000 全局會話級動態參數，默認值為0。每個用戶的最大的進程連接數。值0表示“沒有限制”。
table_open_cache 全局動態參數，默認值2000。所有線程能打開的表數。如果show global status like 'Opened_tables'值很大，且不經常使用flush tables操作（只會強制關閉並重新打開所有表），則需要增加table_open_cache的值。
table_definition_cache 全局動態參數，默認值為-1，最小是為400。是.frm文件在定義換成里面存儲的總量，如果你創建一個比較大的值，會加快你打開表的速度。這個表定義緩存會占據一些空間，它不同於常規的表緩存，它不會用文件描述符。它的值，最小400，之后一般依據下面的簡單計算來定：400+(table_open_cache/2)
table_open_cache_instances 全局靜態參數，默認16，最小1，最大64。打開的表緩存實例的數量。為了通過減少會話之間的爭用來提高可伸縮性，可以將打開的表緩存划分為幾個大小為 table_open_cache/table_open_cache_instances的較小緩存實例。一個會話只需要鎖定一個實例就可以訪問DML語句。這對實例之間的緩存訪問進行分段，從而在有許多會話訪問表時為使用緩存的操作提供更高的性能。（DDL語句仍然需要鎖定整個緩存，但此類語句的頻率遠低於DML語句。）對於通常使用 16 個或更多內核的系統，建議使用 8 或 16 的值。
MySQL默認的table_open_cache為64，這個數值是偏小的，如果max_connections較大，則容易引起性能問題。
表現：數據庫查詢效率慢，show processlist 發現比較多的查詢正在opening table。
進一步確認，執行以下語句：
> show global status like 'open%tables%';
Opened_tables數值非常大，說明cache太小，導致要頻繁地open table，可以查看下當前的table_open_cache設置
> show variables like '%table_open_cache%';
默認是64，一般設置為max_connections就沒問題了（如果還不夠，可以繼續加大，但不能設置大得離譜，可能會引發其他問題）。4G內存的機器，建議設置為2048
> set global table_open_cache=2048;
Query OK, 0 rows affected (0.00 sec)
設置后可以觀察一下，如果opening table不再怎么出現，說明此修改是有效的，將其添加到mysql的配置文件，這樣數據庫重啟后仍可保留此設置。
> show variables like '%table_open_cache%';
比較適合的值：
Open_tables/Opened_tables>=0.85
Open_tables/table_open_cache<=0.95
thread_stack 全局靜態參數，默認值262144為256kb。每個線程的堆棧大小，對於正常操作來說足夠大了。如果線程堆棧大小太小，則會限制服務器可以處理的SQL語句的復雜性、存儲過程的遞歸深度以及其他消耗內存的操作。
external-locking=FALSE 默認FALSE。禁用外部鎖定（系統鎖定），只會影響MyISAM表訪問。如果開啟會使mysqld很容易死鎖。要顯式禁用外部鎖定，可以使用 --skip-external-locking.
max_allowed_packet=64M 全局會話級動態參數，默認值為4MB，最大值為1GB，設置值必須為1024的倍數。設置在網絡傳輸中一次消息傳輸量的最大值。net_buffer_length和max_allowed_packet都以給出的大小開始，每個SQL語句的net_buffer_length根據需要動態放大到max_allowed_packet的值，結果緩沖區縮小到net_buffer_length的值。此參數值不用配置，連接緩沖區會自動擴大，在會話級別是只讀的。如果使用大BLOB列或長字符串，則必須增加此值，應該與BLOB使用的最大值一樣大，避免MySQL客戶端或mysqld服務器收到大於 max_allowed_packet 字節的信息包時，報“信息包過大”錯誤，並關閉連接。對於某些客戶端，如果通信信息包過大，在執行查詢期間，可能會遇到“丟失與 MySQL 服務器的連接”錯誤。當通過更改max_allowed_packet變量的值來更改消息緩沖區大小時，如果客戶端程序允許，還應該在客戶端更改緩沖區大小。客戶端庫中內置的默認max_allowed_packet值為1GB，但個別客戶端程序可能會覆蓋此值。例如，mysql和mysqldump的默認值分別為16MB和24MB。可以在命令行或選項文件中更改客戶端max_allowed_packet的值。此變量在會話級別是只讀的，客戶端最多可以接收與會話值一樣多的字節。但是，服務器不會向客戶端發送比當前全局max_allowed_packet值更多的字節。注：如果客戶端連接后更改全局值，則全局值可能小於會話值。
sort_buffer_size=4M 全局會話級動態參數，不限定存儲引擎，默認值256KB。查詢排序時所能使用的緩沖區大小。通過SHOW GLOBAL STATUS，如果Sort_merge_passes的值很大，可以增大sort_buffer_size參數值，以加快ORDER BY或GROUP BY在無法通過查詢優化或改進索引來優化的操作。在排序發生時會分配給每個線程，由於該參數對應的分配內存是每個連接獨占，過大的設置+高並發可能會耗盡系統內存資源。如果有500個連接，那么實際分配的總共排序緩沖區大小為500×4＝2GB，所以該參數值並不是越大越好。
join_buffer_size=4M 全局會話級動態參數。用於普通索引掃描、范圍索引掃描和不使用索引並因此執行全表掃描的連接的緩沖區的最小大小，該參數對應的分配內存也是每個連接獨享。此緩沖被用來優化全聯合(full JOINs 不帶索引的聯合)，類似的聯合在極大多數情況下的性能非常糟糕, 但是將此值設大能夠減輕性能影響。可以通過Select_full_join狀態變量查看全聯合的數量。
thread_cache_size 全局動態參數。服務器中可以重新利用保存在緩存中線程的數量。當客戶端斷開連接時，如果客戶端的線程少於緩存中的線程，則將客戶端的線程放入緩存中thread_cache_size。通過重用從緩存中獲取的線程來滿足對線程的請求，並且只有當緩存為空時才會創建新線程。如果有很多新連接，可以增加此變量以提高性能。如果服務器每秒看到數百個連接，通常應該調整thread_cache_size值足夠高，以便於大多數新連接都使用緩存線程。通過比較Connections和Threads_created狀態的變量，查看線程緩存的效率。默認值參考，上限為100：8+(max_connections/100)根據物理內存設置規則如下：1G—>8/2G—>16/3G—>32/大於3G—>64
interactive-timeout 全局會話級動態參數，默認值28800s為8小時。服務器在關閉交互式連接之前等待其活動的秒數。如果前端程序采用短連接，建議縮短wait_timeout和interactive_timeout值, 如果前端程序采用長連接，可直接注釋掉這兩個參數，默認配置(8小時)
wait_timeout=600 全局會話級動態參數，默認值28800s為8小時。服務器在關閉非交互式連接之前等待其活動的秒數。在線程啟動時，會話wait_timeout初始值從全局interactive_timeout值獲取。
lock_wait_timeout=3600 全局會話級動態參數，默認值為31536000s（1 年）。此變量指定嘗試獲取元數據鎖的超時時間（以秒為單位）,允許值范圍為1到31536000。此超時適用於所有使用元數據鎖的語句。這些包括DML和DDL操作對表、視圖、存儲過程和函數，以及LOCK TABLES，FLUSH TABLES WITH READ LOCK和HANDLER語句。
connect_timeout=10 全局動態參數，默認值是10s。連接超時之前的最大秒數,在 Linux 平台上，該超時也用作等待服務器首次回應的時間。如果客戶經常遇到Lost connection to MySQL server at 'XXX', system error: errno，可以增加connect_timeout的值。連接超時之前的最大秒數,在 Linux 平台上，該超時也用作等待服務器首次回應的時間。
#*** tmp && heap settings相關選項 ***#
tmp_table_size 全局會話級動態參數，默認值16M。內部內存臨時表的最大大小，如果超過該值，則結果放到磁盤中,此限制是針對單個表的,而不是總和。實際由tmp_table_size和max_heap_table_size中較小的值確定。如果內存中的臨時表超出限制，MySQL會自動將其轉換為磁盤上的臨時表。如果執行許多高級GROUP BY查詢，並且有大量內存，增加tmp_table_size和max_heap_table_size的值。通過比較Created_tmp_disk_tables和Created_tmp_tables變量的值，確定tmp_table_size設置的是否合理。
max_heap_table_size 全局會話級動態參數，默認值16M。獨立的內存表所允許的最大容量，此選項為了防止意外創建一個超大的內存表導致用盡所有的內存資源。
#*** log settings 相關選項 ***#
log_timestamps=SYSTEM 全局動態參數，默認值UTC。控制寫入錯誤日志的消息中時間戳的時區，以及寫入文件的一般查詢日志和慢速查詢日志消息。不影響一般查詢日志和慢查詢日志消息寫入表的時區（mysql.general_log, mysql.slow_log）。
log-bin=/path/logs/mysql-binlog 全局靜態參數。打開二進制日志功能，在復制(replication)配置中,作為MASTER主服務器必須打開此項。如果需要從最后的備份中做基於時間點的恢復，也同樣需要二進制日志。默認在datadir下。這樣設置后相當於，制定了log_bin_basename和log_bin_index的配置。
log_slave_updates=1 全局靜態參數，默認false。表示slave將從主服務器接收到的復制事件寫進自己的二進制日志，必須在從屬設備上啟用二進制日志記錄才能使此變量生效。
relay-log 全局靜態參數，文件名。定義relay_log的位置和名稱，如果值為空，則默認位置在數據文件的目錄，文件名為host_name-relay-bin.nnnnnn
relay_log_index 全局靜態參數，文件名。如果為空，則默認位置在數據文件的目錄。
log_error_verbosity 全局動態參數，默認值為2。1在錯誤日志中記錄ERROR，2記錄ERROR,WARNING，3記錄ERROR,WARNING,INFORMATION。從MySQL5.7.2開始，log_error_verbosity系統變量優先於並且應該代替--log-warnings選項或log_warnings系統變量使用。
log-error=/path/data/error.log 全局靜態參數，文件名。記錄錯誤日志的路徑。
slow_query_log=1 全局動態參數，默認值OFF。是否開啟慢查詢日志。慢查詢是指執行時間超過long_query_time定義時間的查詢。如果log_long_format被打開,那些沒有使用索引的查詢也會被記錄。
long-query-time=0.1 全局會話級動態參數，默認值為10s。設定慢查詢的閥值，超出次設定值的SQL即被記錄到慢查詢日志，同時會增加Slow_queries狀態變量的值。不要設置為1, 否則會導致所有的查詢,甚至非常快的查詢也被記錄下來。該值可以指定為微秒。
log_output=FILE 全局動態參數，默認值為FILE，可以為FILE和TABLE。指定了慢查詢輸出的格式，可以設置為TABLE，然后就可以查詢mysql.slow_log表了。
slow_query_log_file=/path/slow.log 全局動態參數，文件名。指定慢日志文件存放位置，可以為空，系統會給一個缺省的文件host_name-slow.log
log-queries-not-using-indexes=1 全局動態參數，默認值OFF。啟用慢查詢日志的情況下啟用此變量，會記錄SQL語句沒有使用索引的查詢。此選項不一定意味着不使用索引，例如，使用全索引掃描的查詢使用索引但會被記錄，因為索引不會限制行數。
log_throttle_queries_not_using_indexes=60 全局動態參數，如果log_queries_not_using_indexes啟用，該log_throttle_queries_not_using_indexes變量會限制每分鍾可以寫入慢查詢日志的此類查詢的數量。值0（默認值）表示“無限制”。
min_examined_row_limit=100 全局會話級動態參數，默認值為0。記錄那些由於查找了多余1000次而引發的慢查詢。
log_slow_admin_statements=on 全局動態參數，默認關閉。默認寫入慢查詢日志的語句中不包含管理語句，也不會記錄不使用索引進行查找的查詢。打開后會記錄執行慢的管理語句，包括ALTER TABLE、 ANALYZE TABLE、 CHECK TABLE、 CREATE INDEX、 DROP INDEX、 OPTIMIZE TABLE和 REPAIR TABLE。
log_slow_slave_statements=on 全局動態參數，默認關閉。此變量會啟用日志記錄在從屬服務器上執行時間超過主庫定義long_query_time幾秒的查詢，變量的狀態適用於所有后續啟動START SLAVE之后的語句。需要注意，所有以行格式記錄在master中的語句都不會記錄在slave的慢日志中，即使log_slow_slave_statements已啟用。
log_queries_not_using_indexes=on 全局動態參數，默認關閉。開啟后會把不使用索引的查詢記錄到慢查詢日志中。
sync_binlog=1 全局動態參數，默認值為1。控制MySQL服務器將二進制日志同步到磁盤的頻率。sync_binlog=0：禁用MySQL服務器將二進制日志同步到磁盤。相反，MySQL服務器依賴操作系統不時將二進制日志刷新到磁盤，就像它對任何其他文件所做的那樣。此設置提供了最佳性能，但如果發生電源故障或操作系統崩潰，服務器可能已提交尚未同步到二進制日志的事務。sync_binlog=1：在提交事務之前啟用二進制日志到磁盤的同步。這是最安全的設置，但由於磁盤寫入次數增加，可能會對性能產生負面影響。在電源故障或操作系統崩潰的情況下，二進制日志中丟失的事務僅處於准備狀態。這允許自動恢復例程回滾事務，從而保證不會從二進制日志中丟失事務。sync_binlog=N, 其中是 0 或 1 以外的值：在收集到二進制日志提交組N后，將二進制日志同步到磁盤。N在電源故障或操作系統崩潰的情況下，服務器可能已經提交了尚未刷新到二進制日志的事務。由於磁盤寫入次數增加，此設置可能會對性能產生負面影響。較高的值會提高性能，但會增加數據丟失的風險。
binlog_cache_size=4M 全局動態參數，默認值32KB。在一個事務中binlog為了記錄SQL狀態所持有的cache大小，如果經常使用大事務，可以增加此值來獲取更大的性能。事務中的狀態都將被緩沖在binlog緩沖中，然后在提交后一次性寫入到binlog中，如果事務比此值大, 會使用磁盤上的臨時文件來替代。此緩沖在每個連接的事務第一次更新狀態時在session級別被創建。可以結合Binlog_cache_use和Binlog_cache_disk_use參數的值，調整此變量的大小。binlog_cache_size僅設置事務緩存的大小；語句緩存的大小由binlog_stmt_cache_size系統變量控制。
max_binlog_cache_size=2G 全局動態參數。如果一個事務需要超過這么多字節的內存，服務器會生成一個多語句事務需要超過'max_binlog_cache_size'字節的存儲錯誤。最小值為 4096。可能的最大值為 16EB。最大推薦值為4GB，這是因為MySQL目前無法處理大於4GB的二進制日志。max_binlog_cache_size僅設置事務緩存的大小，語句緩存的上限由max_binlog_stmt_cache_size系統變量控制。在MySQL 5.7中，max_binlog_cache_size對會話的可見性與binlog_cache_size系統變量的可見性相匹配，換句話說，更改其值只會影響值更改后啟動的新會話。
max_binlog_size=1G 全局動態參數，默認值1073741824為1GB。如果二進制日志寫入的內容超出給定值，日志就會發生滾動。該值不能大於1GB或小於4096字節。如果正使用大的事務，二進制日志還會超過max_binlog_size。如果寫入二進制日志導致當前日志文件大小超過此變量的值，則服務器輪換二進制日志（關閉當前文件並打開下一個文件）。最小值為 4096 字節。最大值和默認值為 1GB。加密的二進制日志文件有一個額外的512字節標頭，包含在max_binlog_size。如果max_relay_log_size為0，則該值max_binlog_size也適用於中繼日志。開啟GTID，當max_binlog_size被用完，如果無法訪問系統表mysql.gtid_executed，把當前的GTID信息寫入二進制日志文件，則無法切換二進制日志。在這種情況下，服務器會根據其binlog_error_action設置做出響應。如果設置為IGNORE_ERROR，則在服務器上記錄錯誤並停止二進制日志記錄，如果設置為ABORT_SERVER，則服務器會關閉。
secure-file-priv=/path/tmp 全局靜態參數。此變量用於限制數據導入和導出操作的影響，例如由 LOAD DATA and SELECT ... INTO OUTFILE語句和LOAD_FILE()函數執行的操作。這些操作只允許有FILE權限的用戶使用。secure_file_priv可以設置如下：如果為空，則變量無效。這不是一個安全的設置。如果設置為目錄的名稱，則服務器將導入和導出操作限制為僅處理該目錄中的文件。目錄必須存在；服務器不會創建它。如果設置為NULL，服務器將禁用導入和導出操作。服務器 secure_file_priv在啟動時檢查 的值，如果該值不安全，則將警告寫入錯誤日志。如果非NULL值是空的，或者值是數據目錄或其子目錄，或者所有用戶都可以訪問的目錄，則認為非值是不安全的。如果secure_file_priv設置為不存在的路徑，則服務器將錯誤消息寫入錯誤日志並退出。
expire_logs_days=30 全局動態參數。自動刪除binlog的天數，8.0已棄用，由binlog_expire_logs_seconds代替。MySQL 8.0開始，binlog_expire_logs_seconds選項也存在的話，會忽略expire_logs_days選項
binlog_expire_logs_seconds 全局靜態參數，默認值2592000秒，即30天。如果expire_logs_days和binlog_expire_logs_seconds在啟動時有一個參數設置為非0，則該值決定二進制日志有效期，如果同時出現則binlog_expire_logs_seconds決定二進制日志有效期，如果未設置則用binlog_expire_logs_seconds的默認值為二進制日志有效期。
master_info_repository=TABLE 全局動態參數，5.7默認為FILE，8.0默認值為TABLE。該變量的設置決定了從服務器是將主狀態和連接信息記錄到系統數據庫中mysql.slave_master_info表中，還是記錄到數據目錄中的文件中。在配置多個復制通道之前，必須設置此變量，只有在沒有執行復制線程時才能更改此變量的值。
relay_log_info_repository=TABLE 全局動態參數，5.7默認為FILE，8.0默認值為TABLE。該變量的設置決定了從服務器是將其在中繼日志中的位置記錄到系統數據庫中的mysql.slave_relay_log_info表中，還是記錄到數據目錄中的文件中。配置多個復制通道時需要設置。還需要中繼日志信息日志的TABLE設置以使復制對意外停止具有彈性，為此還必須啟用--relay-log-recovery選項。
relay_log_recovery=1 全局靜態參數，默認5.7FALSE/8.0OFF關閉。在服務器啟動后立即自動啟用中繼日志恢復。恢復進程創建一個新的中繼日志文件，將SQL線程位置初始化為這個新的中繼日志，並將I/O線程初始化為SQL線程位置，然后繼續從主服務器讀取中繼日志。這個全局變量是只讀的，可以通過使用該選項啟動從屬服務器來更改其值，該--relay-log-recovery選項應在復制從屬服務器意外停止后使用，以確保不會處理可能損壞的中繼日志。此變量還與relay-log-purge交互，后者控制在不再需要日志時清除日志。在禁用--relay-log-recovery選項時啟用relay-log-purge可能會從未清除的文件中讀取中繼日志，從而導致數據不一致。當relay_log_recovery啟用並且從屬服務器由於在多線程模式下運行時遇到錯誤而停止時，可以使用START SLAVE UNTIL SQL_AFTER_MTS_GAPS確保在切換回單線程模式或執行CHANGE MASTER TO 語句之前處理所有間隙。
relay-log-purge=1 全局動態參數，默認啟用。不再需要時立即禁用或者啟用中繼日志的自動清除。
gtid_mode=on 全局動態參數，默認關閉。此選項指定是否使用全局事務標識符(GTID) 來標識事務。將此選項設置為--gtid-mode=ON要求將enforce-gtid-consistency其設置為ON。記錄的事務可以是匿名的或使用GTID。匿名事務依賴二進制日志文件和位置來識別特定事務。GTID事務具有用於引用事務的唯一標識符。不同的模式是：OFF: 新的和復制的事務都必須是匿名的。OFF_PERMISSIVE: 新交易是匿名的。復制的交易可以是匿名交易或 GTID 交易。ON_PERMISSIVE: 新交易是 GTID 交易。復制的交易可以是匿名交易或 GTID 交易。ON：新事務和復制事務都必須是 GTID 事務。從一個值到另一個值的更改一次只能是一個步驟。例如，如果 gtid_mode當前設置為 OFF_PERMISSIVE，則可以更改為 OFF或ON_PERMISSIVE但不能更改為ON。
enforce_gtid_consistency=1 全局動態參數，默認關閉。啟用后，服務器通過只允許執行可以使用GTID安全記錄的語句來強制執行GTID一致性。在啟用基於GTID的復制之前，必須將--enforce-gtid-consistency選項設置為ON。可以配置的值為：OFF：允許所有事務違反 GTID 一致性。ON: 不允許任何事務違反 GTID 一致性。WARN：允許所有事務違反 GTID 一致性，但在這種情況下會生成警告。enforce_gtid_consistency開啟時，只能記錄可以使用GTID安全語句記錄的語句，因此以下操作不能使用：CREATE TABLE ... SELECT statements。CREATE TEMPORARY TABLE 或 DROP TEMPORARY TABLEstatements 在事務內部。更新事務和非事務表的事務或語句。如果所有非事務性表都是臨時的，則在與事務性DML相同的事務或同一語句中允許非事務性DML是一個例外。
slave-rows-search-algorithms='INDEX_SCAN,HASH_SCAN' 全局動態參數，在8.0.18棄用。在為基於行的日志記錄和復制准備成批的行時，此選項控制如何搜索行以查找匹配項，散列是否用於使用主鍵或唯一鍵、其他鍵或不使用鍵的搜索全部。默認值為 TABLE_SCAN,INDEX_SCAN，這意味着所有可以使用索引的搜索都使用它們，而沒有任何索引的搜索使用表掃描。
binlog_format=ROW 全局會話級動態參數，默認值為ROW，其他值ROW/STATEMENT/MIXED。MySQL復制主要有三種方式：基於SQL語句的復制(statement-based replication, SBR)，基於行的復制(row-based replication, RBR)，混合模式復制(mixed-based replication, MBR)。對應的，binlog的格式也有三種：STATEMENT，ROW，MIXED。STATEMENT模式（SBR）每一條會修改數據的sql語句會記錄到binlog中。優點是並不需要記錄每一條sql語句和每一行的數據變化，減少了binlog日志量，節約IO，提高性能。缺點是在某些情況下會導致master-slave中的數據不一致(如sleep()函數，last_insert_id()，以及user-defined functions(udf)等會出現問題)ROW模式（RBR）不記錄每條sql語句的上下文信息，僅需記錄哪條數據被修改了，修改成什么樣了。而且不會出現某些特定情況下的存儲過程、或function、或trigger的調用和觸發無法被正確復制的問題。缺點是會產生大量的日志，尤其是alter table的時候會讓日志暴漲。MIXED模式（MBR）以上兩種模式的混合使用，一般的復制使用STATEMENT模式保存binlog，對於STATEMENT模式無法復制的操作使用ROW模式保存binlog，MySQL會根據執行的SQL語句選擇日志保存方式。
binlog_checksum=1 全局動態參數。啟用后，會校驗主服務器寫入二進制日志中的每個事件。binlog_checksum支持值NONE（禁用）和CRC32，默認值為CRC32。不能在事務中更改binlog_checksum的值。當binlog_checksum禁用（值 NONE）時，服務器通過寫入和檢查每個事件的事件長度（而不是校驗和）來驗證它是否僅將完整事件寫入二進制日志。更改此變量的值會切換二進制日志，導致校驗總是寫入整個二進制日志文件，而不是只寫入其中的一部分。在主服務器上將此變量設置為從服務器無法識別的值會導致從服務器將自己的binlog_checksum值設置為NONE，並停止復制並出現錯誤。（Bug #13553750，Bug #61096）如果與舊從站的向后兼容性是一個問題，可能需要顯式設置該值為NONE.
slow_launch_time 默認動態參數，默認值為2.如果創建線程花費的時間超過了這么多秒，服務器會增加show global status like 'Slow_launch_threads'狀態變量。
general_log=0 全局動態參數，默認關閉。將所有到達MySQL Server的SQL語句記錄下來。
general_log_file=/path/mysql.log 全局動態參數，文件名。general_log開啟才能生效。
max_relay_log_size=1G 全局靜態參數。服務器自動切換中繼日志文件的大小。如果此值非零，則中繼日志在其大小超過此值時自動切換。如果此值為零（默認值），則中繼日志在達到max_binlog_size時發生切換。
relay-log-purge=1 全局動態參數，默認值為on。是否自動清空不再需要中繼日志時。在啟用該選項時禁用清除中繼日志會導致數據一致性風險，因此不具備崩潰安全性。
binlog_stmt_cache_size 全局動態參數，默認32KB。二進制日志用於保存事務期間發出的非事務語句的內存緩沖區的大小。在服務器上啟用二進制日志記錄時（使用log_bin系統變量設置為ON），如果服務器支持任何事務存儲引擎，則為每個客戶端分配單獨的二進制日志事務和語句緩存。如果事務中使用的非事務性語句的數據超出內存緩沖區中的空間，則超出的數據將存儲在臨時文件中。當服務器上的二進制日志加密處於活動狀態時，內存緩沖區未加密，但（從 MySQL 8.0.17 開始）用於保存二進制日志緩存的任何臨時文件都被加密。提交每個事務后，通過清除內存緩沖區並截斷臨時文件（如果使用）來重置二進制日志語句緩存。如果經常在事務期間使用大型非事務性語句，則可以通過減少或消除寫入臨時文件的需要來增加此緩存大小以獲得更好的性能。查看Binlog_stmt_cache_use和Binlog_stmt_cache_disk_use狀態，調整此變量的大小。
slave-net-timeout=60 全局動態參數，默認值60s為1分鍾。在從服務器認為連接斷開、中止讀取並嘗試重新連接之前等待來自主服務器更多數據的秒數。第一次重試在超時后立即發生。但是，只有從服務器超過slave_net_timeout秒沒有從主服務器收到數據才通知網絡中斷。
net_read_timeout=30 全局會話級動態參數，默認30s。從服務器從主服務器讀取信息的超時時間。
net_write_timeout=60 全局動態參數，默認值60s。從服務器寫入信息的超時時間。
net_retry_count=10 全局會話級動態參數，默認值為10次。如果通信端口上的讀取或寫入中斷，在放棄之前重試的次數。
net_buffer_length 全局會話級動態參數，默認值16KB，最大為1MB。每個客戶端線程都與一個連接緩沖區和結果緩沖區相關聯。兩者都以給出的大小開始，每個SQL語句的net_buffer_length根據需要動態放大到max_allowed_packet的值，結果緩沖區縮小到net_buffer_length的值。此參數值不用配置，連接緩沖區會自動擴大，在會話級別是只讀的。
#*** MyISAM 相關選項 ***#
key_buffer_size=32M 全局動態參數。MyISAM引擎表索引塊緩沖區大小，增加它可得到更好的索引處理性能。如果是以InnoDB引擎為主的DB，key_buffer_size參數值可以設置較小，8MB已足夠。如果是以MyISAM引擎為主，可設置較大，但不能超過4G。如果對表的順序掃描請求非常頻繁，並且認為頻繁掃描進行得太慢，可以通過增加該變量值以及內存緩沖區大小提高其性能。強烈建議不使用MyISAM引擎，默認使用InnoDB引擎，該參數值設置的過大反而會是服務器整體效率降低！
read_buffer_size=8M 全局會話級動態參數。MyISAM引擎表進行全表順序掃描時分配的緩沖區大小。此變量的值應設置為4KB的倍數。
read_rnd_buffer_size=4M 全局會話級動態參數。MyISAM引擎表以索引掃描(Random Scan)方式掃描數據的buffer大小，多用於范圍讀取優化。當在排序之后,從一個已經排序好的序列中讀取行時,行數據將從這個緩沖中讀取來防止磁盤尋道。如果增高此值,可以提高很多ORDER BY操作的性能。
bulk_insert_buffer_size=64M 全局會話級動態參數。MyISAM用在塊插入優化中的樹緩沖區的大小。MyISAM引擎使用特殊的樹狀緩存來使得插入(INSERT … SELECT, INSERT … VALUES (…), (…), …, 以及 LOAD DATAINFILE) 更快地進行批量插入。此變量限制每個進程中緩沖樹的字節數，設置為0會關閉此優化，為了最優化不要將此值設置大於key_buffer_size。
myisam_sort_buffer_size=128M 全局會話級動態參數。MyISAM 設置恢復表之時使用的緩沖區的大小，當在REPAIR TABLE或用CREATE INDEX創建索引或ALTER TABLE過程中排序MyISAM索引分配的緩沖區。
myisam_max_sort_file_size=10G 全局動態參數。MySQL在重建MyISAM索引時允許使用的臨時文件的最大大小（在REPAIR TABLE、 ALTER TABLE或 期間LOAD DATA INFILE）。如果文件大小大於此值，則使用鍵緩存創建索引，這會更慢。該值以字節為單位。如果MyISAM索引文件超過此大小並且磁盤空間可用，則增加該值可能有助於提高性能。該空間必須在包含原始索引文件所在目錄的文件系統中可用。
myisam_repair_threads=1 全局會話級動態參數，默認值為1。如果此值大於1，MyISAM則在此過程中並行創建表索引（每個索引在其自己的線程中）。如果一個表擁有超過一個索引,MyISAM可以通過並行排序使用超過一個線程去修復他們。這對於擁有多個CPU以及大量內存情況的用戶，是一個很好的選擇。
#*** INNODB 相關選項 ***#
innodb_file_per_table=1 全局動態參數，默認開啟。InnoDB為獨立表空間模式。InnoDB將每個新創建的表的數據和索引存儲在單獨的.ibd文件中，而不是系統表空間中。當這些表被刪除或截斷時，這些表的存儲空間會被回收。此設置啟用 InnoDB表 壓縮等功能。通過ALTER TABLE操作會將InnoDB表從系統表空間移動到單個文件。
獨立表空間優點：1.每個表都有自已獨立的表空間。2.每個表的數據和索引都會存在自已的表空間中。
3.可以實現單表在不同的數據庫中移動。4.空間可以回收（除drop table操作處，表空不能自已回收）
缺點：1.單表增加過大，如超過100G
結論：共享表空間在Insert操作上稍有優勢。其它都沒獨立表空間表現好。當啟用獨立表空間時，請合理調整：innodb_open_files
innodb_open_files=65535 全局靜態參數，默認值是300。限制Innodb能打開的表的數據，如果庫里的表特別多的情況，請增加這個參數值。
innodb_buffer_pool_size=2G 全局靜態參數，默認值128MB。InnoDB緩存表和索引數據的內存區域（包括數據頁、索引頁、插入緩存、鎖信息、自適應哈希、數據字典信息）。當緩沖池的大小大於1GB時，設置innodb_buffer_pool_instances為大於1的值可以提高繁忙服務器上的可伸縮性。InnoDB使用一個緩沖池來保存索引和原始數據，設置越大，在存取表里面數據時所需要的磁盤I/O越少。在數據庫專用服務器上，可以設置這個變量到服務器物理內存大小的70%-80%。配置緩沖池大小時請注意以下潛在問題，並准備好在必要時縮減緩沖池的大小。物理內存的競爭可能導致操作系統中的分頁。InnoDB為緩沖區和控制結構保留額外的內存，因此分配的總空間大約比指定的緩沖池大小大 10%。緩沖池的地址空間必須是連續的，這在具有在特定地址加載的DLL的Windows系統上可能是一個問題。初始化緩沖池的時間大致與其大小成正比。在具有大型緩沖池的實例上，初始化時間可能很長。為了減少初始化時間，可以在服務器關閉時保存緩沖池狀態並在服務器啟動時恢復它。當增加或減少緩沖池大小時，操作是以塊的形式執行的。塊大小由innodb_buffer_pool_chunk_size配置選項定義，默認為 128 MB。緩沖池大小必須始終等於或倍數innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances。如果將緩沖池大小更改為不等於或倍數innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances的值，則緩沖池大小會自動調整為等於或倍數的值， 且不小於指定的緩沖池大小 innodb_buffer_pool_chunk_size*innodb_buffer_pool_instances。innodb_buffer_pool_size可以動態設置，可以在不重新啟動服務器的情況下調整緩沖池的大小。可通過查看Innodb_buffer_pool_resize_status變量的狀態，調整緩沖池大小。
innodb_buffer_pool_instances=4 全局靜態參數，默認值為8。Innodb緩沖池划分 的區域數。對於具有數 GB 范圍內緩沖池的系統，將緩沖池划分為單獨的實例可以通過減少不同線程讀取和寫入緩存頁面時的爭用來提高並發性。使用散列函數將存儲在緩沖池中或從緩沖池中讀取的每一頁隨機分配給緩沖池實例之一。每個緩沖池管理自己的空閑列表、刷新列表、 LRU和所有其他連接到緩沖池的數據結構，並受到自己的緩沖池互斥體的保護。innodb_buffer_pool_size此選項僅在設置為1GB或更大時生效，總緩沖池大小在所有緩沖池中分配。為獲得最佳效率，請指定innodb_buffer_pool_instances和innodb_buffer_pool_size的組合，以便每個緩沖池實例至少為1GB。
innodb_buffer_pool_load_at_startup=1 全局靜態參數，默認開啟。指定在MySQL服務器啟動時，InnoDB緩沖池通過加載它在較早時間持有的相同頁面來自動預熱。通常與innodb_buffer_pool_dump_at_shutdown結合使用。
innodb_buffer_pool_dump_at_shutdown=1 全局動態參數，默認開啟。指定是否在MySQL服務器關閉時記錄緩存在InnoDB緩沖池中的頁面，以縮短下次重啟時的預熱過程。innodb_buffer_pool_dump_pct選項定義要轉儲的最近使用的緩沖池頁面的百分比。
innodb_buffer_pool_dump_pct=25 全局動態參數，默認25。定義要轉儲的最近使用的緩沖池頁面的百分比。指定要讀取和轉儲的每個緩沖池最近使用的頁面的百分比。范圍為1到100。例如，如果有4個緩沖池，每個緩沖池有100個頁面，並且innodb_buffer_pool_dump_pct設置為25，則轉儲每個緩沖池中最近使用的25個頁面。
innodb_data_file_path=ibdata1:1G;ibdata2:1G:autoextend 全局靜態參數，默認ibdata1:12M:autoextend。InnoDB定義系統表空間數據文件的名稱、大小和屬性。InnoDB將數據保存在一個或者多個數據文件中成為表空間，如果只有單個盤保存的數據，一個自增文件就足夠了。其他情況下，每個設備一個文件一般就可以了，也可以配置InnoDB來使用裸盤分區。對第一個系統表空間數據文件強制執行最小文件大小，以確保有足夠的空間用於雙寫緩沖區頁面：對於innodb_page_size=16KB或更小的值，最小文件大小為 3MB。對於innodb_page_size=32KB的值，最小文件大小為 6MB。對於innodb_page_size=64KB的值，最小文件大小為 12MB。InnoDB定義系統表空間數據文件的名稱、大小和屬性。autoextend默認增量為64MB，要修改增量，請更改innodb_autoextend_increment系統變量。
innodb_flush_log_at_trx_commit=1 全局動態參數，默認值1。控制事務日志從innodb log buffer寫入到redo log中的頻率。>0每向二進制日志文件寫入N條SQL或者N個事務后，則把二進制日志文件的數據刷新到磁盤上。可以通過更改默認值來獲得更好的性能，但隨后可能會在崩潰中丟失多達一秒鍾的事務。
值為0時，由mysql的main_thread每秒將存儲引擎log buffer中的redo日志寫入到log file，並調用文件系統的sync操作，將日志刷新到磁盤。事務提交時不會執行從日志緩沖區到日志文件的寫入。在這種情況下，MySQL性能最好。由於進程調度問題，不能保證每秒一次的刷新。由於刷新到磁盤操作大約每秒發生一次，因此任何mysqld進程崩潰都會丟失多達一秒鍾的事務。
值為1時，完全符合ACID要求。每次事務提交時，將存儲引擎log buffer中的redo日志寫入到log file，並調用文件系統的sync操作，將日志刷新到磁盤。這是最安全的配置，但由於每次事務都需要進行磁盤I/O，所以也最慢。
值為2時，每次事務提交時，將存儲引擎log buffer中的redo日志寫入到log file，但並不會立即刷寫到磁盤，由存儲引擎的main_thread每秒將日志刷新到磁盤。由於進程調度問題，每秒一次的刷新不能保證每秒發生100%。刷新到磁盤操作大約每秒發生一次，因此可能會在操作系統崩潰或斷電時丟失多達一秒鍾的事務。InnoDB日志刷新頻率由innodb_flush_log_at_timeout控制，允許將日志刷新頻率設置為N秒（其中 N是1 … 2700，默認值為 1）。但是，任何 mysqld進程崩潰都可以抹掉多達N秒鍾的事務。DDL更改和其他內部InnoDB活動會獨立於設置innodb_flush_log_at_trx_commit刷新InnoDB日志。InnoDB無論innodb_flush_log_at_trx_commit設置如何，崩潰恢復都有效。事務要么完全應用，要么完全刪除。InnoDB為了在與事務一起使用的復制設置中獲得最大可能的持久性和一致性，請使用以下設置：
sync_binlog=1 && innodb_flush_log_at_trx_commit=1，在mysqld 服務崩潰或者服務器主機crash的情況下，binary log只有可能丟失最多一個語句或者一個事務。但是都為1會導致頻繁的IO操作，因此該模式也是最慢的一種方式。雙1適合數據安全性要求非常高，而且磁盤IO寫能力足夠支持業務，比如訂單,交易,充值,支付消費系統。雙1模式下，當磁盤IO無法滿足業務需求時，推薦的做法是
innodb_flush_log_at_trx_commit=2 && sync_binlog=N(N為500 或1000)且使用帶蓄電池后備電源的緩存cache，防止系統斷電異常。
警告：許多操作系統和一些磁盤硬件欺騙了刷新到磁盤操作。他們可能會告訴mysqld已經發生了刷新，即使它還沒有發生。在這種情況下，即使使用推薦的設置也無法保證事務的持久性，在最壞的情況下，斷電可能會損壞InnoDB數據。在SCSI磁盤控制器或磁盤本身中使用電池支持的磁盤緩存可加快文件刷新速度，並使操作更安全。可以嘗試禁用硬件緩存中磁盤寫入的緩存。
innodb_log_buffer_size=32M 全局靜態參數，默認值16MB。InnoDB用於寫入磁盤上日志文件的緩沖區大小（以字節為單位）。當此值快滿時, InnoDB將必須刷新數據到磁盤上。由於基本上每秒都會刷新一次，所以沒有必要將此值設置的太大。大型日志緩沖區使大型事務無需在事務提交之前將日志寫入磁盤即可運行。因此，如果有更新、插入或刪除許多行的事務，則使日志緩沖區更大可以節省磁盤 I/O。
innodb_log_file_size=48M 全局靜態參數，默認值48MB。在日志組中每個日志文件的大小，應該設置日志文件總合大小到緩沖池大小的25%~100%，來避免在日志文件覆寫上不必要的緩沖池刷新行為。通常，日志文件的組合大小應該足夠大，以便服務器可以消除工作負載活動的高峰和低谷，這通常意味着有足夠的重做日志空間來處理超過一個小時的寫入活動。該值越大，緩沖池中需要的檢查點刷新活動就越少，從而節省磁盤 I/O。較大的日志文件也會使崩潰恢復更慢。如果innodb_dedicated_server啟用，則 innodb_log_file_size如果未明確定義，則會自動配置該值。
innodb_log_files_in_group=2 全局靜態參數，默認為2。日志組中的日志文件數。以循環方式寫入文件。
#innodb_max_undo_log_size=1G 全局動態參數，默認值為1073741824字節(1024 MiB)。定義undo表空間的閾值大小。如果撤消表空間超過閾值，則可以在innodb_undo_log_truncate啟用時將其標記為截斷。
#innodb_purge_rseg_truncate_frequency 全局動態參數，默認128次。根據調用清除的次數定義清除系統釋放回滾段的頻率。在釋放回滾段之前，無法截斷undo表空間。通常，清除系統每調用128次清除就釋放回滾段一次。默認值為128。減小此值會增加清除線程釋放回滾段的頻率。
#innodb_undo_directory=/path/data/undolog 全局動態參數。InnoDB創建undo表空間的路徑。通常用於將undo日志放在不同的存儲設備上。與innodb_rollback_segments和innodb_undo_tablespaces一起使用。沒有默認值（它是NULL）。如果未指定路徑，則會在MySQL數據目錄中創建undo表空間。
#innodb_rollback_segments 全局動態參數，默認128。定義InnoDB使用undo回滾段的數。系統表空間總是分配一個回滾段，32個回滾段保留給臨時表使用，並托管在臨時表空間( ibtmp1)中。要為生成undo記錄的數據修改事務分配額外的回滾段，必須將innodb_rollback_segments設置為大於33的值。如果配置單獨的undo表空間，系統表空間中的回滾段將變為非活動狀態。每個回滾段最多可以支持1023個數據修改的事務。當innodb_rollback_segments設置為32或更少時，InnoDB將一個回滾段分配給系統表空間，將32分配給臨時表空間( ibtmp1)。當innodb_rollback_segments設置為大於32的值時，InnoDB將一個回滾段分配給系統表空間，將32分配給臨時表空間( ibtmp1)，並為undo表空間（如果存在）分配額外的回滾段。如果不存在撤消表空間，則會將額外的回滾段分配給系統表空間。盡管可以增加或減少InnoDB使用的回滾段的數量，但系統中物理存在的回滾段的數量永遠不會減少。因此，可以從該參數的低值開始並逐漸增加它，以避免分配不需要的回滾段。默認值為128，這也是innodb_rollback_segments的最大值。
#根據您的服務器IOPS能力適當調整，一般配普通SSD盤的話，可以調整到10000-20000。配置高端PCIe SSD卡的話，則可以調整的更高，比如 50000-80000。
innodb_io_capacity=4000 全局動態參數，默認值200。該參數設置InnoDB后台任務每秒執行I/O操作數的上限，例如從緩沖池刷新頁面和合並來自更改緩沖區的數據。該參數是限制所有緩沖池實例的總限制。刷新臟頁時，限制在緩沖池實例之間平均分配。innodb_io_capacity應該設置為系統每秒大約可以執行的I/O操作數。理想情況下，將設置保持在盡可能低的水平，但不要太低以至於后台活動落后。如果該值太高，則會從緩沖池中刪除數據並太快地插入緩沖區，從而無法為緩存提供顯着優勢。對於具有更高I/O速率的繁忙系統，可以設置更高的值以幫助服務器處理與高速率行更改相關的后台維護工作。通常，可以根據InnoDB用於I/O的驅動器數量來增加該值。例如，可以增加使用多個磁盤或固態磁盤(SSD)的系統的價值。對於低端SSD，默認設置200通常就足夠了。對於更高端的總線連接SSD，請考慮更高的設置，例如 1000。對於具有單個5400RPM或7200RPM驅動器的系統，可以將值降低到100，它表示可用於執行約100IOPS的老一代磁盤驅動器的每秒I/O操作(IOPS)的估計比例。盡管可以指定一個非常高的值，但在實踐中，比較大的值幾乎沒有任何好處。通常，不建議使用20000或更高的值，除非已證明較低的值不足以滿足工作負載。調整innodb_io_capacity時考慮寫入工作負載。具有大量寫入工作負載的系統可能會受益於更高的設置。對於寫入工作量較小的系統，較低的設置可能就足夠了。可以設置innodb_io_capacity為100或更大的任何數字，最大由innodb_io_capacity_max定義。innodb_io_capacity可以在MySQL選項文件(my.cnf或)中設置或使用需要權限的語句my.ini動態更改。SET GLOBALSUPER innodb_flush_sync配置選項會導致innodb_io_capacity在檢查點處發生的I/O活動突發期間忽略該設置。innodb_flush_sync默認啟用。
innodb_io_capacity_max=8000 全局動態參數，如果刷新活動落后，則可以以比InnoDB innodb_io_capacity變量定義的更高的每秒I/O操作(IOPS)速率更積極地刷新。innodb_io_capacity_max變量定義了在這種情況下后台任務執行的最大IOPS數。
innodb_flush_sync=0 全局動態參數，默認開啟。innodb_flush_sync的變量會導致在檢查點發生的I/O活動突發期間忽略innodb_io_capacity設置。要遵守innodb_io_capacity設置定義的I/O速率，請禁用innodb_flush_sync。
innodb_flush_neighbors=0 全局動態參數，5.7默認為1，8.0默認為0。指定從InnoDB緩沖池中刷新頁面是否也會刷新相同范圍內的其他臟頁面。設置為0禁用innodb_flush_neighbors相同范圍內的臟頁不會被刷新。設置1刷新相同范圍內的連續臟頁。設置為2會刷新相同范圍內的臟頁。
innodb_write_io_threads=8/innodb_read_io_threads=8 全局靜態參數，默認值4。innodb使用后台線程處理數據頁上的讀寫I/O(輸入輸出)請求，根據服務器的CPU核數來更改,默認是4。這兩個參數不支持動態改變，需要把該參數加入到my.cnf里，修改完后重啟MySQL服務，允許值的范圍從1-64。
innodb_purge_threads=4 全局靜態參數，默認為4。專門用於清除InnoDB操作的后台線程數。最小值1表示清除操作始終由后台線程執行，而不是作為主線程的一部分。在一個或多個后台線程中運行InnoDB清除操作有助於減少內部爭用，提高可伸縮性。將該值增加到大於1會創建許多單獨的清除線程，這可以提高對多個表執行DML操作的系統的效率。最大值為32。
innodb_page_cleaners=4 全局靜態參數，默認為4。從緩沖池實例中清理刷新臟頁的頁面線程數。頁面清理線程執行刷新列表和LRU刷新。當有多個頁面清理線程時，每個緩沖池實例的緩沖池刷新任務被分派給空閑的頁面清理線程。如果頁面清理線程的數量超過緩沖池實例的數量，則innodb_page_cleaners自動設置為與innodb_buffer_pool_instances相同的值。如果工作負載在將臟頁從緩沖池實例刷新到數據文件時受寫入IO限制，並且系統硬件具有可用容量，則增加頁面清理線程的數量可能有助於提高寫入IO吞吐量。多線程頁面清理器支持擴展到關閉和恢復階段。
innodb_max_dirty_pages_pct=75 全局動態參數，默認值75。innodb主線程刷新緩存池中的數據，使臟數據比例小於90%，這是一個軟限制，不被保證絕對執行。
innodb_flush_method=O_DIRECT 全局靜態參數。定義用於將數據刷新到InnoDB數據文件和日志文件的方法，這會影響I/O吞吐量。表空間總是使用雙重寫入刷新方法。innodb_flush_method參數的選項包括：fsync：InnoDB調用系統fsync()刷新數據和日志文件。fsync是默認設置。O_DSYNC：InnoDB用於O_SYNC打開和刷新日志文件，以及fsync()刷新數據文件。InnoDB不會直接使用O_DSYNC，因為在許多Unix上都存在問題。O_DIRECT：InnoDB使用O_DIRECT（或 directio()在 Solaris 上）打開數據文件，並用於fsync()刷新數據和日志文件。此選項在某些GNU/Linux版本、FreeBSD 和 Solaris 上可用。O_DIRECT_NO_FSYNC: InnoDB在刷新I/O期間使用O_DIRECT，但之后跳過系統對fsync()調用。此設置適用於某些類型的文件系統，但不適用於其他類型。例如，它不適合XFS。如果不確定使用的文件系統是否需要fsync()，例如保留所有文件元數據請O_DIRECT改用。如何設置innodb_flush_method取決於硬件配置和工作負載，會有不同的性能影響。對於特定配置進行基准測試，以決定使用哪個設置，或者是否保留默認設置。檢查Innodb_data_fsyncs的狀態變量，查看每個設置的調用總數。fsync()工作負載中讀取和寫入操作的混合會影響設置的執行方式。例如，在具有硬件RAID控制器和電池支持的寫入緩存的系統上，O_DIRECT可以幫助避免InnoDB緩沖池和操作系統文件系統緩存之間的雙重緩沖。在某些系統上InnoDB數據和日志文件位於SAN上，這是默認值，或者對於主要是語句O_DSYNC的讀取繁重的工作負載可能更快。SELECT始終使用反映您的生產環境的硬件和工作負載測試此參數。
innodb_lru_scan_depth=4000 全局動態參數，默認1024。影響InnoDB緩沖池刷新操作的算法和啟發式的參數。指定每個緩沖池實例，頁面清理線程掃描的緩沖池LRU頁面列表向下多遠，以查找要刷新的臟頁。這是每秒執行一次的后台操作。小於默認值的設置通常適用於大多數工作負載。遠高於必要的值可能會影響性能。只有在典型工作負載下有備用I/O容量時才考慮增加該值。相反，如果寫入密集型工作負載使I/O容量飽和，請減小該值，尤其是在緩沖池較大的情況下。在調整innodb_lru_scan_depth時，從一個低值開始並向上設置，目標是很少看到零空閑頁面。此外，在更改緩沖池實例的數量時考慮調整innodb_lru_scan_depth，因為innodb_lru_scan_depth*innodb_buffer_pool_instances定義了頁面清理線程每秒執行的工作量。
innodb_checksum_algorithm=crc32 全局動態參數，默認值為crc32。指定如何生成和驗證存儲InnoDB表空間在磁盤中的塊。
innodb_lock_wait_timeout=10 全局會話級動態參數，默認值50。InnoDB事務在放棄之前等待行鎖的時間秒數。嘗試訪問被另一個InnoDB事務鎖定的行的事務在發出以下錯誤之前最多等待這么多秒以對該行進行寫訪問：ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction對於高度交互的應用程序或OLTP系統，可能會降低此值，以快速顯示用戶反饋或將更新放入隊列以供稍后處理。可以為長時間運行的后端操作增加此值，例如數據倉庫中等待其他大型插入或更新操作完成的轉換步驟。innodb_lock_wait_timeout僅適用於InnoDB行鎖。MySQL表鎖不會在InnoDB內部發生，並且此超時不適用於等待表鎖。鎖定等待超時值在啟用時不適用於死鎖，因為會立即檢測死鎖並回滾其中一個死鎖事務。在禁用時，發生死鎖時依賴於事務回滾。innodb_lock_wait_timeout可以在運行時使用SET GLOBALor SET SESSION語句設置。更改 GLOBAL設置需要SUPER特權並影響隨后連接的所有客戶端的操作。任何客戶端都可以更改SESSION的innodb_lock_wait_timeout設置，僅影響該客戶端。
innodb_rollback_on_timeout=1 全局靜態參數，默認關閉。InnoDB默認情況下僅回滾事務超時的最后一條語句。如果--innodb_rollback_on_timeout指定，事務超時會導致InnoDB中止並回滾整個事務。
innodb_print_all_deadlocks=1 全局動態參數，默認關閉。啟用此選項后，有關InnoDB用戶事務中的所有死鎖的信息都會記錄在mysqld錯誤日志中。否則使用SHOW ENGINE INNODB STATUS命令只會看到最后一個死鎖的信息。偶爾的 InnoDB 死鎖不一定是問題，因為 InnoDB 會立即檢測到情況並自動回滾其中一個事務。如果應用程序沒有適當的錯誤處理邏輯來檢測回滾並重試其操作，可以使用此選項來解決為什么會發生死鎖。大量死鎖可能表明需要對發出 DML 或 SELECT … FOR UPDATE 語句的多個表的事務進行重組，以便每個事務以相同的順序訪問表，從而避免死鎖情況。
innodb_online_alter_log_max_size=4G 全局動態參數，默認134217728字節128M。指定在InnoDB表的聯機DDL操作期間使用臨時日志文件大小的上限。每個正在創建的索引或正在更改的表都有一個這樣的日志文件。此日志文件存儲在DDL操作期間在表中插入、更新或刪除的數據。臨時日志文件會在需要時按innodb_sort_buffer_size的值進行擴展，直至達到innodb_online_alter_log_max_size指定的最大值。如果臨時日志文件超出大小上限，則ALTER TABLE操作失敗並回滾所有未提交的並發DML操作。因此，此選項的較大值允許在線DDL操作期間發生更多DML，但也會延長DDL操作結束時表被鎖定以應用日志數據的時間段。
innodb_stats_on_metadata=0 全局動態參數，默認關閉。此選項僅適用於將優化器統計信息配置為非持久性的情況。當禁用innodb_stats_persistent或使用STATS_PERSISTENT=0創建或更改單個表時，優化器統計信息不會持久保存到磁盤。當innodb_stats_on_metadata啟用時，當元數據語句show table status或者訪問INFORMATION_SCHEMA.TABLES或INFORMATION_SCHEMA.STATISTICS表時（這些更新類似於ANALYZE TABLE發生的情況）InnoDB更新非持久統計信息。當關閉時，InnoDB在這些操作期間不會更新統計信息。禁用該設置可以提高具有大量表或索引的模式的訪問速度。它還可以提高涉及 InnoDB 表的查詢的執行計划的穩定性。要更改設置，請執行語句 SET GLOBAL innodb_stats_on_metadata=ON1|OFF0。更改設置需要SUPER權限並立即影響所有連接的操作。
innodb_undo_log_truncate=on 全局動態參數，默認關閉。啟用后，超過定義的閾值的undo表空間將innodb_max_undo_log_size標記為截斷。只有撤消表空間可以被截斷。不支持截斷駐留在系統表空間中的撤消日志。要發生截斷，必須至少有兩個undo表空間和兩個重做的undo日志被配置。意味着innodb_undo_tablespaces必須設置為等於或大於2的值，並且innodb_rollback_segments必須設置為等於或大於35的值。innodb_purge_rseg_truncate_frequency配置選項可用於加快撤消表空間的截斷。
internal_tmp_disk_storage_engine=InnoDB 全局動態參數，默認為InnoDB，8.0.16開始刪除該選項。磁盤內部臨時表的存儲引擎為InnoDB引擎。使用internal_tmp_disk_storage_engine=INNODB時，生成超出InnoDB行或列限制的磁盤內部臨時表的查詢將返回Row size too large或Too many columns錯誤。解決方法是設置internal_tmp_disk_storage_engine=MYISAM。
#注意: 開啟 innodb_status_output & innodb_status_output_locks 后, 可能會導致log-error文件增長較快
innodb_status_output=0 全局動態參數，默認關閉。啟用或禁用標准InnoDB監視器的定期輸出。還與innodb_status_output_locks結合使用以啟用或禁用InnoDB鎖定監視器的定期輸出。
innodb_status_output_locks=1 全局動態參數，默認關閉。啟用或禁用InnoDB鎖定監視器。啟用后，InnoDB鎖定監視器會在SHOW ENGINE INNODB STATUS輸出中打印有關鎖定的附加信息，並在定期輸出中打印到MySQL錯誤日志。InnoDB鎖定監視器的定期輸出作為標准InnoDB監視器輸出的一部分打印。因此，InnoDB必須啟用標准監視器才能使InnoDB Lock Monitor定期將數據打印到MySQL錯誤日志。
innodb_sort_buffer_size=67108864 全局靜態參數，默認1048576字節為1M。指定在創建InnoDB索引期間用於對數據進行排序的排序緩沖區的大小。指定的大小定義了讀入內存進行內部排序然后寫出到磁盤的數據量。這個過程被稱為“運行”。在合並階段，讀取和合並指定大小的緩沖區對。設置越大，運行和合並的次數就越少。該排序區域僅用於索引創建期間的合並排序，而不是在以后的索引維護操作期間。當索引創建完成時，緩沖區被釋放。
innodb_autoinc_lock_mode=1 全局靜態參數，默認值5.7版本為1，8.0版本為2。
0：“傳統”鎖定模式。在這種鎖定模式下，所有“ INSERT-like ”語句都會獲得一個特殊的表級AUTO-INC鎖定，用於插入到具有AUTO_INCREMENT列的表中。此鎖通常保持到語句的末尾（而不是事務的末尾），以確保為給定的語句序列以可預測和可重復的順序分配自動遞增值INSERT ，並確保自動遞增值任何給定語句分配的都是連續的。
1：“連續”鎖定模式。在這種模式下，“批量插入”使用特殊的AUTO-INC表級鎖並持有它直到語句結束。這適用於所有INSERT … SELECT、 REPLACE … SELECT和LOAD DATA語句。一次只能執行一個持有AUTO-INC鎖的語句。如果批量插入操作的源表與目標表不同，則AUTO-INC在對源表中選擇的第一行進行共享鎖之后，再對目標表進行鎖定。如果批量插入操作的源和目標是同一個表，則AUTO-INC在所有選定行上獲取共享鎖后獲取鎖。
2：“交錯”鎖定模式。在這種鎖模式下，沒有 “ INSERT-like ” 語句使用表級AUTO-INC鎖，可以同時執行多條語句。這是最快且最具可擴展性的鎖定模式，但 在使用基於語句的復制或恢復方案時從二進制日志重放SQL語句時，它是不安全的。在這種鎖定模式下，自動遞增值保證在所有並發執行 的“ INSERT-like ” 語句中是唯一的並且單調遞增。但是，由於多個語句可以同時生成數字（即，數字的分配在語句之間交錯），為任何給定語句插入的行生成的值可能不是連續的。如果唯一執行的語句是“簡單插入”，其中要插入的行數是提前知道的，那么除了“混合模式插入”之外，為單個語句生成的數字中沒有間隙。但是，當執行“批量插入”時，任何給定語句分配的自動增量值可能存在間隙。
將自動增量與復制一起使用：如果使用基於語句的復制，請設置innodb_autoinc_lock_mode為0或1，並在主服務器及其從服務器上使用相同的值。innodb_autoinc_lock_mode如果使用=2（“ interleaved ”）或主從不使用相同鎖定模式的配置，則不能確保從屬上的自動增量值與主控上的值相同。如果使用基於行或混合格式的復制，所有自動增量鎖定模式都是安全的，因為基於行的復制對 SQL 語句的執行順序不敏感（並且混合格式使用基於行的對於基於語句的復制不安全的任何語句的復制）。
批量插入的自動增量值的差距：innodb_autoinc_lock_mode設置為0（“傳統”）或1（“連續”）時，任何給定語句生成的自動增量值都是連續的，沒有間隙，因為表級AUTO-INC鎖一直保持到語句結束，並且僅一次可以執行一個這樣的語句。innodb_autoinc_lock_mode設置為2（“interleaved”）時，“bulk inserts”生成的自動增量值可能存在間隙，但前提是同時執行“INSERT-like”語句。
innodb_buffer_pool_chunk_size=128M 全局靜態參數，默認值128MB。定義InnoDB緩沖池大小調整操作的塊大小。允許在不重新啟動服務器的情況下調整緩沖池的大小。為避免在調整大小操作期間復制所有緩沖池頁面，該操作以 “塊”執行。一個塊中包含的頁數取決於innodb_page_size的值。innodb_buffer_pool_chunk_size可以以1MB（1048576 字節）為單位增加或減少。innodb_buffer_pool_chunk_size更改值時適用以下條件：如果在緩沖池初始化時innodb_buffer_pool_chunk_size*
innodb_buffer_pool_instances大於當前緩沖池大小，innodb_buffer_pool_chunk_size則截斷為innodb_buffer_pool_size/innodb_buffer_pool_instances。緩沖池大小必須始終等於或數倍innodb_buffer_pool_chunk_size*innodb_buffer_pool_instances。如果更改innodb_buffer_pool_chunk_size, innodb_buffer_pool_size 會自動調整為等於或倍數innodb_buffer_pool_chunk_size*innodb_buffer_pool_instances且不小於當前緩沖池大小的值。調整發生在緩沖池初始化時。更改innodb_buffer_pool_chunk_size時應小心，因為更改此值會自動增加緩沖池的大小。在更改innodb_buffer_pool_chunk_size之前，計算它將產生的影響，innodb_buffer_pool_size以確保生成的緩沖池大小是可以接受的。為避免潛在的性能問題，塊 (innodb_buffer_pool_size/innodb_buffer_pool_chunk_size)的數量不應超過1000。
innodb_page_size=16384 全局靜態參數，默認值16KB。指定MySQL實例中所有表空間的頁面大小。可以使用值4096/4k 8192/8k 16384/16k 32768/32k 65536/64k來指定頁面大小。innodb_page_size只能在初始化MySQL實例之前配置，之后不能更改。如果未指定值，則使用默認頁面大小初始化實例。在ROW_FORMAT=COMPRESSED時不支持設置為32KB或64KB。默認的16KB或更大的頁面大小適用於廣泛的工作負載，特別是涉及表掃描的查詢和涉及批量更新的DML操作。對於涉及許多小寫入的OLTP工作負載，較小的頁面大小可能更有效，當單個頁面包含許多行時，爭用可能是一個問題。對於通常使用小塊大小的SSD存儲設備，較小的頁面可能也很有效。使InnoDB頁面大小接近存儲設備塊大小可以最大限度地減少重寫到磁盤的未更改數據量。第一個系統表空間數據文件 ( ibdata1) 的最小文件大小因innodb_page_size值而異。
innodb_thread_concurrency=16 全局動態參數，默認為0。服務器有幾個CPU就設置為幾。InnoDB嘗試將並發的操作系統線程數保持在InnoDB小於或等於此變量給定的限制內（InnoDB使用操作系統線程來處理用戶事務）。一旦線程數達到此限制，額外的線程將被置於“先進先出”（FIFO）隊列中以等待執行。等待鎖的線程不計入並發執行的線程數。此變量的范圍是0到1000。0（默認值）被解釋為無限並發（不限制並發數），可以更好去發揮CPU多核處理能力來提高並發量。如果MySQL實例與其他應用程序共享CPU資源，工作負載或並發用戶數量正在增長，請考慮設置此變量。最優值依賴於應用程序，硬件以及操作系統的調度方式和運行的MySQL版本。需要測試一系列值以確定提供最佳性能的設置。
innodb_flush_log_at_timeout=1 全局動態參數，默認為1，每秒一次。設置多少秒寫入和刷新日志。innodb_flush_log_at_timeout允許增加刷新之間的超時時間，以減少刷新並避免影響二進制日志組提交的性能。
innodb_log_group_home_dir 全局靜態參數，目錄名。InnoDB重做日志文件的目錄路徑，其編號由innodb_log_files_in_group指定。如果不指定任何InnoDB日志變量，則默認在MySQL數據目錄中創建名為ib_logfile0和ib_logfile1的兩個文件。日志文件大小由innodb_log_file_size系統變量給出。可以將其指定到一個獨立的硬盤上或者一個RAID1卷上來提高其性能。
innodb_force_recovery=1 全局靜態參數，默認值為0，一般不調整。如果InnoDB表空間損壞, 設置此值為一個非零值可能導出業務表，從1開始並且增加此值直到能夠成功的導出表。
innodb_fast_shutdown 全局動態參數，默認值為1。InnoDB關機模式。如果值為0，InnoDB則在關閉之前會進行慢速關閉、完全清除和更改緩沖區合並。如果值為1，則InnoDB在關機時跳過這些操作，該過程稱為快速關機。如果值為2，則InnoDB刷新其日志並冷關機，就好像MySQL崩潰了：沒有提交的事務丟失，但是崩潰恢復操作使下次啟動需要更長的時間。在仍然緩沖大量數據的極端情況下，緩慢關閉可能需要幾分鍾甚至幾小時。在MySQL主要版本之間升級或降級之前使用慢速關閉技術，以便在升級過程更新文件格式時做好所有數據文件的准備。在緊急情況或故障排除情況下使用innodb_fast_shutdown=2，以在數據存在損壞風險時獲得絕對最快的關閉速度。
#*** performance_schema相關設置 ***#
performance_schema=1 全局靜態參數，默認開啟。是否啟用性能模式，會在performance_schema數據庫中記錄相關的信息。
#*** innodb monitor相關設置 ***#
#innodb monitor 全局動態參數。啟用InnoDB指標計數器。可以使用INFORMATION_SCHEMA.INNODB_METRICS表格查詢計數器數據。配置在my.cnf中。
innodb_monitor_enable="module_innodb"
innodb_monitor_enable="module_server"
innodb_monitor_enable="module_dml"
innodb_monitor_enable="module_ddl"
innodb_monitor_enable="module_trx"
innodb_monitor_enable="module_os"
innodb_monitor_enable="module_purge"
innodb_monitor_enable="module_log"
innodb_monitor_enable="module_lock"
innodb_monitor_enable="module_buffer"
innodb_monitor_enable="module_index"
innodb_monitor_enable="module_ibuf_system"
innodb_monitor_enable="module_buffer_page"
innodb_monitor_enable="module_adaptive_hash"
[mysqldump]
quick 不要緩存結果，逐行打印。支持較大數據庫的轉儲，在導出非常巨大的表時需要此項。
max_allowed_packet=32M 增加該變量的值十分安全，這是因為僅當需要時才會分配額外內存。例如，僅當發出長查詢或mysqld必須返回大的結果行時mysqld才會分配更多內存。該變量之所以取較小默認值是一種預防措施，以捕獲客戶端和服務器之間的錯誤信息包，並確保不會因偶然使用大的信息包而導致內存溢出。如果使用大的BLOB值，而且未為mysqld授予為處理查詢而訪問足夠內存的權限，也會遇到與大信息包有關的問題。如果懷疑出現了該情況，請嘗試在mysqld_safe腳本開始增加ulimit -d 256000，並重啟mysqld。
三、數據庫對象命名規范
1、數據庫對象
數據庫對象是數據庫的組成部分，常見的有以下幾種： 表（Table ）、索引（Index）、視圖（View）、圖表（Diagram）、缺省值（Default）、規則（Rule）、觸發器（Trigger）、存儲過程（Stored Procedure）、 用戶（User）等。 命名規范是指數據庫對象如數據庫（SCHEMA）、表（TABLE）、索引（INDEX）、約束（CONSTRAINTS）等的命名約定。
2、數據庫對象全局命名規范
1、命名使用具有意義的英文詞匯，詞匯中間以下划線分隔。
2、命名只能使用英文字母、數字、下划線，以英文字母開頭。
3、避免用MySQL的保留字如：backup、call、group等，參考MySQL 5.7+的關鍵字和保留字。
4、所有數據庫對象使用小寫字母，實際上MySQL中是可以設置大小寫是否敏感的，為了保證統一性，規范全部用小寫字母。
3、數據庫命名規范
1、數據庫命名盡量不超過30個字符。
2、數據庫命名一般為項目名稱+代表庫含義的簡寫，比如IM項目的工作流數據庫，可以是 im_flow。
3、數據庫創建時必須添加默認字符集和校對規則子句。默認字符集為UTF8。
4、命名應使用小寫。
4、表命名規范
1、常規表表名以t_開頭，t代表table的意思，命名規則即 t + 模塊（包含模塊含義的簡寫）+ 表（包含表含義的簡寫），比如用戶模塊的教育信息表：t_user_eduinfo。
2、臨時表（RD、QA或DBA同學用於數據臨時處理的表），命名規則：temp前綴+模塊+表+日期后綴：temp_user_eduinfo_20210719。
3、備份表（用於保存和歸檔歷史數據或者作為災備恢復的數據）命名規則，bak前綴+模塊+表+日期后綴：bak_user_eduinfo_20210719。
4、同一個模塊的表盡可能使用相同的前綴，表名稱盡可能表達含義。
5、多個單詞以下划線 _ 分隔。
6、常規表表名不超過30個字符，temp表和bak表視情況而定，盡量簡短為宜，命名應使用小寫。
5、字段命名規范
1、字段命名需要表示其實際含義的英文單詞或簡寫，單詞之間用下划線 _ 進行連接，如 service_ip、service_port。
2、各表之間相同意義的字段必須同名，比如a表和b表都有創建時間，應該統一為create_time，不一致會很混亂。
3、多個單詞以下划線 _ 分隔。
4、字段名盡量不超過30個字符，命名應該使用小寫。
6、索引命名規范
1、唯一索引使用uni + 字段名 來命名
> create unique index uni_uid on t_user_basic(uid);
2、非唯一索引使用idx + 字段名 來命名
> create index idx_uname_mobile on t_user_basic(uname,mobile);
3、多個單詞以下划線 _ 分隔。
4、索引名不超過50個字符，命名使用小寫，組合索引的字段不宜太多，不然也不利於查詢效率的提升。
5、多單詞組成的列名，取盡可能代表意義的縮寫，如 test_contact表member_id和friend_id上的組合索引：idx_mid_fid。
6、理解組合索引最左前綴原則，避免重復建設索引，如果建立了(a,b,c)，相當於建立了(a), (a,b), (a,b,c)。
7、視圖命名規范
1、視圖名以v開頭，表示view，完整結構是v+視圖內容含義縮寫。
2、如果視圖只來源單個表，則為v+表名。如果視圖由幾個表關聯產生就用v+下划線（_）連接幾個表名，視圖名不超過30個字符。
3、如無特殊需要，嚴禁開發人員創建視圖。
4、命名應使用小寫。
8、存儲過程命名規范
1、存儲過程名以sp開頭，表示存儲過程（storage procedure）。之后多個單詞以下划線（_）進行連接。存儲過程命名中應體現其功能。存儲過程名不能超過30個字符。
2、存儲過程中的輸入參數以i_開頭，輸出參數以o_開頭。
3、命名應使用小寫。
> create procedure sp_multi_param(in i_id bigint,in i_name varchar(32),out o_memo varchar(100));
9、函數命名規范
1、函數名以func開始，表示function。之后多個單詞以下划線（_）進行連接，函數命名中應體現其功能。函數名不超過30個字符。
2、命名應使用小寫。
> create function func_format_date(ctime datetime)
10、觸發器命名規范
1、觸發器以trig開頭，表示trigger 觸發器。
2、基本部分，描述觸發器所加的表，觸發器名不超過30個字符。
3、后綴（_i,_u,_d）,表示觸發條件的觸發方式（insert,update或delete）。
4、命名應使用小寫。
> DROP TRIGGER IF EXISTS trig_attach_log_d;
> CREATE TRIGGER trig_attach_log_d AFTER DELETE ON t_dept FOR EACH ROW;
11、約束命名規范
1、唯一約束：uk_表名稱_字段名。uk是UNIQUE KEY的縮寫。比如給一個部門的部門名稱加上唯一約束，來保證不重名，如下：
> ALTER TABLE t_dept ADD CONSTRAINT un_name UNIQUE(name);
2、外鍵約束：fk_表名，后面緊跟該外鍵所在的表名和對應的主表名（不含t_）。子表名和父表名用下划線(_)分隔。如下：
>ALTER TABLE t_user ADD CONSTRAINT fk_user_dept FOREIGN KEY(depno) REFERENCES t_dept (id);
3、非空約束：如無特殊需要，建議所有字段默認非空(not null)，不同數據類型必須給出默認值(default)，如下：
Create table emp(
id int(11) NOT NULL,
name varchar(30) DEFAULT '',
deptId int(11) DEFAULT 0,
salary float DEFAULT NULL,
primary key(id));
4、出於性能考慮，如無特殊需要，建議不使用外鍵。參照完整性由代碼控制。這個也是普遍的做法，從程序角度進行完整性控制，但是如果不注意，也會產生臟數據。
5、命名應使用小寫。
12、用戶命名規范
1、生產使用的用戶命名格式為 code_應用。
2、只讀用戶命名規則為 read_應用。
13、對象名稱使用小寫字母、下划線分割
Windows默認情況下無法建立大寫庫名
Linux大小寫敏感，MySQL數據文件（庫名、表名、表別名嚴格區分大小寫）
Linux查詢大小寫敏感
Windows查詢大小寫不敏感
MySQL 5.6，lower_case_table_names，0：表示區分大小寫、1：表示不區分大小寫
MySQL 5.7，lower_case_table_names，2：表示區分大小寫、1：表示不區分大小寫
統一命名使用全小寫字母和下划線分割
列名與列表名在所有情況下忽略大小寫
四、數據庫用戶權限規范
1、權限划分一般原則
# 數據庫一般划分為生產庫，測試庫，開發庫
1.生產庫
DBA：有所有權限，超級管理員權限
應用程序：分配insert、delete、update、select、execute、events、jobs權限。
測試人員：select某些業務表權限
開發人員：select某些業務表權限
原則：所有對線上表的操作，除了應用程序之外，都必須經由DBA來決定是否執行、以及什么時候執行等。
2.測試庫
DBA：所有權限。
測試人員：有insert、delete、select、update、execute、jobs權限。
數據分析人員：只有select查詢權限
開發人員：有select權限。
原則：DBA有所有權限，而且嚴格控制表結構的變更，不允許除了dba之外的人對測試環境的庫環境進行修改，以免影響測試人員測試。所有對測試庫的表結構進行的修改必須由測試人員和DBA一起審核過后才能操作。
3.開發庫
DBA：所有權限
測試人員：有庫表結構以及數據的所有操作權限。
開發人員：有庫表結構以及數據的所有操作權限。
數據分析人員：有庫表結構以及數據的所有操作權限。
2、數據庫用戶划分
# 這里以MySQL為例
1.普通數據管理用戶：
-- 賦予對業務表的查詢維護權限即可
grant select, insert, update, delete on dbname.* to 'username'@'host' identified by 'pwd';
2.開發人員賬戶
-- 賦予增刪改查的權限
grant select,insert,delete,update on dbname.* to 'kaifa'@'host' identified by 'pwd';
-- 授予創建、修改、刪除 MySQL數據表結構權限
grant create,alter,drop on dbname.* to 'kaifa'@'host';
-- 授予操作MySQL外鍵權限
grant references on dbname.* to 'kaifa'@'host';
-- 授予操作MySQL臨時表權限
grant create temporary tables on dbname.* to 'kaifa'@'host';
-- 授予操作MySQL索引權限
grant index on dbname.* to 'kaifa'@'host';
-- 授予操作MySQL視圖、查看視圖權限
grant create view,show view on dbname.* to 'kaifa'@'host';
-- 授予操作MySQL存儲過程、函數權限
grant create routine,alter routine,execute on dbname.* to 'kaifa'@'host';
匯總以上權限
grant select,insert,delete,update,create,alter,drop, references,create temporary tables,index, create view,show view,create routine,alter routine,execute on dbname.* to 'kaifa'@'host' identified by 'pwd';
3.DBA人員賬戶
-- 授予普通DBA管理某個MySQL數據庫的權限
grant all privileges on dbname.* to sysdba@'host' identified by 'pwd';
-- 授予高級DBA管理MySQL中所有數據庫的權限
grant all on . to sysdba@'host' identified by 'pwd';
4.數據分析人員只讀賬號
-- 只需要分配只讀的權限
grant select on dbname.* to 'dataquery'@'host' identified by 'pwd';
-- 甚至有些用戶，可以只分配讀取某些表列的權限
grant select on test.* to 'dataquery'@'host’ identified by 'pwd';
grant select(id,uname) on dbname.tablename to 'dataquery'@’hostname’ identified by 'pwd';
五、數據庫維護規范
1、超100萬行的批量寫（UPDATE、DELETE、INSERT）操作，要分批多次進行操作 ①大批量操作可能會造成嚴重的主從延遲 主從環境中，大批量操作可能會造成嚴重的主從延遲，大批量的寫操作一般都需要執行一定長的時間，而只有當主庫上執行完成后，才會在其他從庫上執行，所以會造成主庫與從庫長時間的延遲情況 ②binlog日志為row格式時會產生大量的日志 大批量寫操作會產生大量日志，特別是對於row格式二進制數據而言，由於在row格式中會記錄每一行數據的修改，我們一次修改的數據越多，產生的日志量也就會越多，日志的傳輸和恢復所需要的時間也就越長，這也是造成主從延遲的一個原因。 ③避免產生大事務操作 大批量修改數據，一定是在一個事務中進行的，這就會造成表中大批量數據進行鎖定，從而導致大量的阻塞，阻塞會對MySQL的性能產生非常大的影響。 特別是長時間的阻塞會占滿所有數據庫的可用連接，這會使生產環境中的其他應用無法連接到數據庫，因此一定要注意大批量寫操作要進行分批。
2、對於大表使用pt-online-schema-change修改表結構 避免大表修改產生的主從延遲，避免在對表字段進行修改時進行鎖表。 對大表數據結構的修改一定要謹慎，會造成嚴重的鎖表操作，尤其是生產環境，是不能容忍的。 pt-online-schema-change它會首先建立一個與原表結構相同的新表，並且在新表上進行表結構的修改，然后再把原表中的數據復制到新表中，並在原表中增加一些觸發器。把原表中新增的數據也復制到新表中，在行所有數據復制完成之后，把新表命名成原表，並把原來的表刪除掉。把原來一個DDL操作，分解成多個小的批次進行。
3、禁止為程序使用的賬號賦予super權限 當達到最大連接數限制時，還運行1個有super權限的用戶連接super權限只能留給DBA處理問題的賬號使用。
4、對於程序連接數據庫賬號，遵循權限最小原則 程序使用數據庫賬號只能在一個DB下使用，不准跨庫程序使用的賬號原則上不准有drop權限。