mysql 常見參數

時間 2019-11-11

標籤 mysql 常見參數欄目 MySQL 简体版

原文原文鏈接

my.cnf
[client] 對mysql的全部客端都生效的
[mysql] 只對mysql這個命令有效了
[mysqd]
[mysqld_multi] 多實例啓動
[mysqld_safe]
[mysqldNNNN]
#[global]
set SQL_SAFE_UPDATES = 1;
運行一段時間，mysql參數優化
1 慢查詢
show variables like '%slow%';
mysql> show variables like '%slow%';
+---------------------------+-----------------------------------------+
| Variable_name | Value |
+---------------------------+-----------------------------------------+
| log_slow_admin_statements | ON |
| log_slow_slave_statements | OFF |
| slow_launch_time | 2
| slow_query_log | ON 指定是否開啓慢查詢日誌
| slow_query_log_file | /data/mysqldata/3306/log/mysql-slow.log 指定慢日誌文件存放位置，能夠爲空，系統會給一個缺省的文件host_name-slow.log
log-warnings
log_error_verbosity,The log_error_verbosity system variable is preferred over,and should be used instead of, the --log-warnings

log_queries_not_using_indexes: 不使用索引的慢查詢日誌是否記錄到索引
long_query_time ：設定慢查詢的閥值，超出次設定值的SQL即被記錄到慢查詢日誌，缺省值爲10s
show global status like '%slow%';
show variables like '%long_query_time%';
> set global log_slow_queries=1;
> set session long_query_time=2;
> set global long_query_time=2;
> show warnings;
> set global log_queries_not_using_indexes=1;
mysql> show global status like '%slow%';
+---------------------+-------+
| Variable_name | Value |
+---------------------+-------+
| Slow_launch_threads | 0 |
| Slow_queries | 3 |
mysql> set global slow_query_log=on;
mysql> show variables like '%error%';php

innodb buffer的預讀取是否有用
(system@127.0.0.1:3306) [test]> show global status like 'Innodb_buffer_pool_read%';
| Innodb_buffer_pool_read_ahead | 767 | 預讀取的頁
| Innodb_buffer_pool_read_ahead_evicted | 0 | 預讀取被清除的頁
( 1 - Innodb_buffer_pool_read_ahead_evicted / Innodb_buffer_pool_read_ahead ) *100 = xx%
innodb_read_ahead_threshold:此參數是設置預讀取的頁數，設置0是關閉預讀取功能
(system@127.0.0.1:3306) [(none)]> show global variables like 'innodb_read_ahead_threshold';
+-----------------------------+-------+
| Variable_name | Value |
+-----------------------------+-------+
| innodb_read_ahead_threshold | 56 |
+-----------------------------+-------+
(system@127.0.0.1:3306) [test]> show global variables like 'innodb%log%';
Handler_read_rnd
Select_full_join
Select_scan
Connections
Threads_created html

2 鏈接數
show variables like 'max_connections';
show global status like 'Max_used_connections';
max_used_connections / max_connections * 100% = 99.6% （理想值 ≈ 85%）前端

4 臨時表
show global status like 'created_tmp%';
(system@127.0.0.1:3306) [test]> show variables like '%tmp%';
mysql> show global status like 'created_tmp%';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| Created_tmp_disk_tables | 25 |--在磁盤上建立臨時表
| Created_tmp_files | 5 |--MySQL服務建立的臨時文件文件數
| Created_tmp_tables | 24283 |--每次建立臨時表
show variables where Variable_name in ('tmp_table_size', 'max_heap_table_size');
max_heap_table_size Default 16M(5.6)
Created_tmp_tables
服務器執行語句時自動建立的內存臨時表的數量。若是Created_tmp_disk_tables值較大。須要增長tmp_table_size和max_heap_table_size的值。
內部臨時表最初建立爲一個內存中的表，但變得太大時，MySQL會自動將其轉換爲磁盤上的表。在內存中的臨時表的最大尺寸是最小的tmp_table_size
和max_heap_table_size的值控制。若是Created_tmp_disk_tables較大，可能要增長tmp_table_size和max_heap_table_size值。以減小在內存臨時表被轉換爲磁盤上的表。
出現臨時表的緣由
（1）若是有一個ORDER BY子句和一個不一樣的GROUP BY子句，或若是ORDER BY或GROUP BY包含第一個表中的其餘列，建立一個臨時表
（2）DISTINCT加上ORDER BY可能須要一個臨時表
（3）若是使用SQL_SMALL_RESULT選項，MySQL使用內存中的臨時表
（4）表中有BLOB或TEXT列的存在
（5）在GROUP BY或DISTINCT子句大於512字節的任意列的存在
（6）在查詢中，若是使用UNION或UNION ALL的任何列大於512字節
（7）GROUP BY和ORDER BY 沒法使用索引時
tmp_table_size=32M 做用：該參數用於決定內部內存(memory)臨時表的最大值，每一個線程都要分配（實際起限制做用的是tmp_table_size和
max_heap_table_size的最小值），若是內存臨時表超出了限制，MySQL就會自動地把它轉化爲基於磁盤的MyISAM表
，優化查詢語句的時候，要避免使用臨時表，若是實在避免不了的話，要保證這些臨時表是存在內存中的。
現象：若是複雜的SQL語句中包含了group by/distinct等不能經過索引進行優化而使用了臨時表，則會致使SQL執行時間加長。
建議：若是應用中有不少group by/distinct等語句，同時數據庫有足夠的內存，能夠增大tmp_table_size(max_heap_table_size)的值，以此來提高查詢性能。
5 open table狀況
show global status like 'open%tables%';
show variables like '%cache%';
6 進程使用狀況
show global status like 'Thread%';
show variables like 'thread_cache_size';#150
當有鏈接被關閉時，mysql檢查緩存中是否還有空閒來緩存線程，若有，就緩存該線程以備下次鏈接重用，沒有就銷燬
7 查詢緩存(query cache)
show global status like 'qcache%';
show variables like 'query_cache%';
> show global status like 'binlog_ca%';
在事務提交之後，binlog是先寫入緩存，而後由操做系統決定什麼時候刷新到磁盤上。若是事務大小超過定義的緩存，則在磁盤上建立一個臨時文件。
Binlog_cache_use
binlog_cache_size=32K =4M
使用臨時二進制日誌緩存的事務數量，若是有較大的事務，能夠增長該值
Binlog_cache_disk_use
使用臨時二進制日誌緩存可是超過binlog_cache_size的值並使用臨時文件來保存事務中的語句的事務數量。若是該值很大，須要加大binlog_cache_size的值
8 排序使用狀況
show global status like 'sort%';
mysql> show global status like 'sort%';
+-------------------+--------+
| Variable_name | Value |
+-------------------+--------+
| Sort_merge_passes | 0 |
| Sort_range | 666 |
| Sort_rows | 420043 |
| Sort_scan | 22526 |
Sort_merge_passes 包括兩步。MySQL 首先會嘗試在內存中作排序使用的內存大小由系統變量Sort_buffer_size 決定，
若是它的大小不夠把全部的記錄都讀到內存中MySQL 就會把每次在內存中排序的結果存到臨時文件中，等MySQL 找到所
有記錄以後，再把臨時文件中的記錄作一次排序,這再次排序就會增長 Sort_merge_passes
> show global status like 'sort%';
Sort_merge_passes
排序算法已經執行的合併的數量。若是這個變量值較大，能夠考慮增長sort_buffer_size變量的值。
緣由：
ORDER BY（不可以使用索引進行排序）
GROUP BY(使用了GROUP BY COLUMN沒有使用ORDER BY NULL).
9 文件打開數(open_files)
show global status like 'open_files';
show variables like 'open_files_limit';
(system@127.0.0.1:3306) [(none)]> show variables like 'open_files_limit';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| open_files_limit | 65535 |
+------------------+-------+
(system@127.0.0.1:3306) [(none)]> show global status like 'open%file%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_files | 15 | # 系統當前打開的文件數
| Opened_files | 1988 | # 系統打開過的文件總數
+---------------+-------+
[root@hongquan1 ~]# ulimit -n
1024
ulimit -a
[root@hongquan1 ~]# ulimit -n 65535
[root@hongquan1 ~]# vim /data/mysqldata/3306/my.cnf
mysql soft nproc 65535
mysql hard nproc 65535
mysql soft nofile 65535
mysql hard nofile 65535linux

已經打開的表的數量。若是Opend_tables較大，則須要考慮加大table_open_cache的值
10 表鎖狀況
show global status like 'table_locks%';
mysql> show global status like 'table_locks%';
+-----------------------+--------+
| Variable_name | Value |
+-----------------------+--------+
| Table_locks_immediate | 133063 |查看當即得到的表的鎖的次數
| Table_locks_waited | 0 |查看不能當即得到的表的鎖的次數。若是該值較高，而且有性能問題，你應首先優化查詢，而後拆分表或使用複製
> show global status like '%row_lock%';
Innodb_current_row_locks
Innodb_deadlocks
(system@127.0.0.1:3306) [test]> show variables like '%deadlocks%';
+----------------------------+-------+
| Variable_name | Value |
+----------------------------+-------+
| innodb_print_all_deadlocks | OFF |
set global innodb_print_all_deadlocks=1
When this option is enabled, information about all deadlocks in InnoDB user transactions is recorded in the mysqld error log算法

11 表掃描狀況
show global status like 'handler_read%';
show global status like 'com_select';
表掃描率 = Handler_read_rnd_next / Com_select數據庫

Handler_read_first .此選項代表SQL是在作一個全索引掃描，注意是所有，而不是部分，因此說若是存在WHERE語句，這個選項是不會變的。
若是這個選項的數值很大，既是好事也是壞事。說它好是由於畢竟查詢是在索引裏完成的，而不是數據文件裏，說它壞
是由於大數據量時，即便是索引文件，作一次完整的掃描也是很費時間的。
Handler_read_key 此選項數值若是很高，那麼恭喜你，你的系統高效的使用了索引，一切運轉良好
Handler_read_last的原意：The number of requests to read the last key in an index. With ORDER BY,
the server will issue a first-key request followed by several next-key requests, whereas with ORDER BY DESC,
the server will issue a last-key request followed by several previous-key requests. This variable was added in MySQL 5.6.1.
Handler_read_next 的原意：The number of requests to read the next row in key order. This value is incremented if
you are querying an index column with a range constraint or if you are doing an index scan.
此選項代表在進行索引掃描時，按照索引從數據文件裏取數據的次數
Handler_read_prev 的原意：The number of requests to read the previous row in key order. This read method is mainly used to optimize ORDER BY ... DESC.
此選項代表在進行索引掃描時，按照索引倒序從數據文件裏取數據的次數，通常就是ORDER BY ... DESC。注意Handler_read_next是ORDER BY ... ASC的方式取數據。
Handler_read_rnd 就是查詢直接操做了數據文件，不少時候表現爲沒有使用索引或者文件排序
Handler_read_rnd_next 表示「在數據文件中讀下一行的請求數。若是你正進行大量的表掃描，該值較高。一般說明你的表索引不正確或寫入的查詢沒有利用索引。
=====
Handler_read_first 表明讀取索引頭的次數，若是這個值很高，說明全索引掃描不少。
Handler_read_key表明一個索引被使用的次數，若是咱們新增長一個索引，能夠查看Handler_read_key是否有增長，若是有增長，說明sql用到索引。
Handler_read_next 表明讀取索引的下列，通常發生range scan。
Handler_read_prev 表明讀取索引的上列，通常發生在ORDER BY … DESC。
Handler_read_rnd 表明在固定位置讀取行，若是這個值很高，說明對大量結果集進行了排序、進行了全表掃描、關聯查詢沒有用到合適的KEY。
Handler_read_rnd_next 表明進行了不少表掃描，查詢性能低下。
=====

log_timestamps --5.7默認的值UTC，會出現log的時間戳比now晚8個小時
修改set global log_timestamps=system;
my.cnf，log_timestamps=SYSTEM

修改全站搜索
修改my.ini(my.cnf) ，在 [mysqld] 後面加入一行「ft_min_word_len=1」，而後重啓Mysql，再登陸網站後臺（模塊管理->全站搜索）重建全文索引。
記錄慢查詢sql語句，修改my.ini(my.cnf)，添加以下代碼
show variables like '%log_output%';
set global log_output='TABLE';
select * from mysql.slow_log;
#log-slow-queries
long_query_time = 1 #是指執行超過多久的 sql 會被 log 下來
log-slow-queries = E:/wamp /logs/slow.log #設置把日誌寫在那裏，能夠爲空，系統會給一個缺省的文件
#log-slow-queries = /var /youpath/slow.log linux下 host_name-slow.log
log-queries-not-using-indexes
slow_launch_time Global Default=2
Query_time：語句執行的時間及實際消耗時間。
Lock_time：包含MDL lock和InnoDB row lock和MyISAM表鎖消耗時間的總和及鎖等待消耗時間。
Rows_sent：發送給mysql客戶端的行數，下面是源碼中的解釋
Number of rows we actually sent to the client
Rows_examined：InnoDB引擎層掃描的行數,下面是源碼中的解釋
Rows_affected：涉及到修改的話(好比DML語句)這是受影響的行數。
for DML statements: to the number of affected rows;
for DDL statements: to 0.
Bytes_sent：發送給客戶端的實際數據的字節數
Tmp_tables：臨時表的個數。
Tmp_disk_tables：磁盤臨時表的個數。
Tmp_table_sizes：臨時表的大小。

mysql> set global general_log=on;
mysql> set global general_log=off;
mysql>set global general_log_file='/tmp/general.lg'; #設置路徑
mysql>set global log_output='table'
character-set-server = utf8mb4
collation-server = utf8mb4_general_ci

thread_stack = 256K （每一個線程的大小）
sort_buffer_size = 6M 查詢排序時所能使用的緩衝區大小。注意：該參數對應的分配內存是每鏈接獨佔！mysql須要查詢排序時分配該內存，指定大小。
read_buffer_size = 4M 讀查詢操做所能使用的緩衝區大小。在查詢須要時才分片指定內存的大小
read_rnd_buffer_size mysql在查詢須要時才分配須要的大小。This variable is used for reads from MyISAM tables, and, for any storage engine, for Multi-Range Read optimization.
join_buffer_size = 8M 聯合查詢操做所能使用的緩衝區大小，，該參數對應的分配內存也是每一個鏈接獨享！
myisam_sort_buffer_size = 64M （myisam引擎排序緩衝區的大小）The size of the buffer that is allocated when sorting MyISAM indexes during a REPAIR TABLE or when
creating indexes with CREATE INDEX or ALTER TABLE
table_cache = 512 （緩存數據表的數量，避免重複打開表的開銷）
thread_cache_size = 64 緩存可重用線程數，減少建立新線程的開銷）
query_cache_size = 64M 指定MySQL查詢緩衝區的大小。能夠經過在MySQL控制檯執行如下命令觀察：（全局）
mysql>show variables like '%query_cache%'; mysql 自己是有對sql語句緩存的機制的，合理設置咱們的mysql緩存能夠下降數據庫的io資源。
#
query_cache_type=0 查詢緩存的方式(默認是 ON)
query_cache_size=0 若是你但願禁用查詢緩存，設置 query_cache_size=0。禁用了查詢緩存，將沒有明顯的開銷
做用：該參數用於控制MySQL query cache的內存大小；若是MySQL開啓query cache，再執行每個query的時候會先鎖住query cache，
而後判斷是否存在query cache中，若是存在直接返回結果，若是不存在，則再進行引擎查詢等操做
同時insert、update和delete這樣的操做都會將query cahce失效掉，這種失效還包括結構或者索引的任何變化
cache失效的維護代價較高，會給MySQL帶來較大的壓力，因此當咱們的數據庫不是那麼頻繁的更新的時候
uery cache是個好東西，可是若是反過來，寫入很是頻繁，並集中在某幾張表上的時候，那麼query cache lock的鎖機制會形成很頻繁的鎖衝突，
對於這一張表的寫和讀會互相等待query cache lock解鎖，致使select的查詢效率降低。
現象：數據庫中有大量的鏈接狀態爲checking query cache for query、Waiting for query cache lock、storing result in query cache；

query_cache_limit 不緩存大於這個值的結果。(缺省爲 1M) 查詢緩存的統計信息
# > SHOW VARIABLES LIKE '%query_cache%';
# > SHOW STATUS LIKE 'Qcache%';
# 若是Qcache_lowmem_prunes的值很是大，則代表常常出現緩衝不夠的狀況；
#若是Qcache_hits的值很是大，則代表查詢緩衝使用很是頻繁，若是該值較小反而會影響效率，那麼能夠考慮不用查詢緩衝；
Qcache_free_blocks，如果該值很是大，則代表緩衝區中碎片不少

thread_cache_size = 64 能夠複用的保存在中的線程的數量。若是有，新的線程從緩存中取得，
當斷開鏈接的時候若是有空間，客戶的線置在緩存中。若是有不少新的線程，爲了提升性能能夠這個變量值。經過比較 Connections 和 Threads_created 狀態的變量，能夠看到這個變量的做用
max_connections = 1000 指定MySQL容許的最大鏈接進程數。若是在訪問論壇時常常出現Too Many Connections的錯誤提示，則須要增大該參數值。
wait_timeout = 10 指定一個請求的最大鏈接時間，對於4GB左右內存的服務器能夠設置爲5-10。
skip-networking 開啓該選項能夠完全關閉MySQL的TCP/IP鏈接方式，若是WEB服務器是以遠程鏈接的方式訪問MySQL數據庫服務器則不要開啓該選項!不然將沒法正常鏈接!
long_query_time = 10 （設定慢查詢的時間）
log-slow-queries =
log-queries-not-using-indexes
(system@127.0.0.1:3306) [test]> show status where Variable_name like 'Threads_%';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Threads_cached | 7 |
| Threads_connected | 46 |
| Threads_created | 58 |
| Threads_running | 2 |
+-------------------+-------+
mysql> show global status like 'Thread%';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Threads_cached | 11 | 線程緩存內的線程的數量
| Threads_connected | 22 | 當前打開鏈接的數量
| Threads_created | 33 | 建立用來處理鏈接的線程數。若是Threads_created較大，須要增長thread_cache_size的值。thread cache命中率計算方法Thread_cache_hits = (1 - Threads_created / Connections) * 100%
| Threads_running | 3 |
+-------------------+-------+
若是咱們在MySQL服務器配置文件中設置了thread_cache_size，當客戶端斷開以後，服務器處理此客戶的線程將會緩存起來以響應下一個客戶而不是
銷燬(前提是緩存數未達上限)。Threads_created表示建立過的線程數，若是發現Threads_created值過大的話，代表 MySQL服務器一直在建立線程，
這也是比較耗資源，能夠適當增長配置文件中thread_cache_size值，查詢服務器 thread_cache_size配置
mysql> show variables like 'thread_cache_size';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| thread_cache_size | 28 |
mysql> show global status like 'qcache%';
+-------------------------+---------+
| Variable_name | Value |
+-------------------------+---------+
| Qcache_free_blocks | 1 |
| Qcache_free_memory | 1031376 |
| Qcache_hits | 0 |
| Qcache_inserts | 0 |
| Qcache_lowmem_prunes | 0 |
| Qcache_not_cached | 2322582 |
| Qcache_queries_in_cache | 0 |
| Qcache_total_blocks | 1 |
+-------------------------+---------+
MySQL查詢緩存變量解釋：
　　Qcache_free_blocks：緩存中相鄰內存塊的個數。數目大說明可能有碎片。FLUSH QUERY CACHE會對緩存中的碎片進行整理，從而獲得一個空閒塊。
　　Qcache_free_memory：緩存中的空閒內存。
　　Qcache_hits：每次查詢在緩存中命中時就增大
　　Qcache_inserts：每次插入一個查詢時就增大。命中次數除以插入次數就是不中比率。
　　Qcache_lowmem_prunes：緩存出現內存不足而且必需要進行清理以便爲更多查詢提供空間的次數。這個數字最好長時間來看;若是這個數字在不斷增加，
就表示可能碎片很是嚴重，或者內存不多。(上面的 free_blocks和free_memory能夠告訴您屬於哪一種狀況)
　　Qcache_not_cached：不適合進行緩存的查詢的數量，一般是因爲這些查詢不是 SELECT 語句或者用了now()之類的函數。
　　Qcache_queries_in_cache：當前緩存的查詢(和響應)的數量。
　　Qcache_total_blocks：緩存中塊的數量。

extra_port=13306 若是使用extra_port參數，MySQL max_connection個鏈接所有被佔用，DBA能夠以管理員權限建立 extra_max_connections+1個鏈接

mysql> show variables like 'max_connections%';
+-----------------+-------+
| Variable_name | Value |
+-----------------+-------+
| max_connections | 2000 |
+-----------------+-------+
Max_used_connections / max_connections * 100% ≈ 85%
max_connect_errors = 10000000
max_connections=1024 是指整個mysql服務器的最大鏈接數
max_user_connections=256 是指每一個數據庫用戶的最大鏈接數
max_connect_errors=65536

timeout 只是針對空閒會話有影響
interactive_timeout：120 服務器關閉交互式(CLIENT_INTERACTIVE)鏈接前等待活動的秒數。交互式客戶端定義爲
在mysql_real_connect()中使用CLIENT_INTERACTIVE選項的客戶端。
wait_timeout = 120 指定一個請求的最大鏈接時間，對於4GB左右內存的服務器能夠設置爲5-10。
MySQL客戶端的數據庫鏈接閒置最大時間值,說得比較通俗一點，就是當你的MySQL鏈接閒置超過必定時間後將會被強行關閉
致使MySQL超過最大鏈接數歷來沒法新建鏈接致使「Too many connections」的錯誤
mysql中的sleep線程最多睡120秒，就會被強行關閉
local_wait_timeout 以秒爲單位設定全部SQL語句等待獲取元數據鎖(metadata lock)的超時時長，默認爲31536000(1年
其影響的SQL語句包括用於表、視圖、存儲過程和存儲函數的DML和DDL語句，以及LOCK TABLES、FLUSH TABLES WITH READ LOCK和HANDLER語句等
| interactive_timeout | 120 |
| wait_timeout | 120 |
(system@127.0.0.1:3306) [(none)]> show full processlist;
ERROR 2013 (HY000): Lost connection to MySQL server during query
(system@127.0.0.1:3306) [(none)]> show full processlist;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
(system@127.0.0.1:3306) [(none)]> set global interactive_timeout = 3660;
| interactive_timeout | 3660 |
| wait_timeout | 3660 |
交互式會話的timeout時間受global級別的interactive_timeout影響。所以要修改非交互模式下的timeout，必須同時修改interactive_timeout的值
非交互模式下，wait_timeout參數繼承global級別的wait_timeout

mysql> show variables like '%wait_timeout%';
+--------------------------+----------+
| Variable_name | Value |
+--------------------------+----------+
| innodb_lock_wait_timeout | 5 |
| lock_wait_timeout | 31536000 |
| wait_timeout | 28800 |
+--------------------------+----------+
innodb_lock_wait_timeout：指的是事務等待獲取資源等待的最長時間，超過這個時間還未分配到資源則會返回應用失敗
參數支持範圍爲Session和Global，且支持動態修改，因此能夠經過兩種方法修改；
set innodb_lock_wait_timeout=100;
set global innodb_lock_wait_timeout=100;
注意global的修改對當前線程是不生效的，只有創建新的鏈接才生效
set global interactive_timeout = 120;
set global wait_timeout = 120;
show session variables like '%timeout%';
set session wait_timeout=10;#超時後，仍是取global的值
set session interactive_timeout=10;
timeout值，對於處於運行狀態SQL語句是否起效（便是否等價於執行超時）？ A：由下例可見SQL正在執行狀態的等待時間不計入timeout時間。即SQL運行再久也不會由於timeout的配置而中斷
同一個session中，wait_timeout 和 interacitve_timeout是否都會生效。 A：只有wait_timeout 會真正起到超時限制的做用
global timeout和session timeout是否都會做爲超時判斷依據？ A：只有session級別 timeout 會起做用。即一個session開始後，不管如何修改global級別的timeout都不會影響該session
超時時間只對非活動狀態的connection進行計算。
超時時間只以session級別的wait_timeout 爲超時依據，global級別只決定session初始化時的超時默認值。
交互式鏈接的wait_timeout 繼承於global的interactive_timeout。非交互式鏈接的wait_timeout繼承於global的wait_timeout
繼承關係和超時對 TCP/IP 和 Socket 鏈接均有效果

lock_wait_timeout：This timeout applies to all statements that use metadata locks，mysql的mdl鎖
These include DML and DDL operations on tables, views, stored procedures, and stored functions,
as well as LOCK TABLES, FLUSH TABLES WITH READ LOCK, and HANDLER statements
此超時適用於使用元數據鎖的全部語句。這些包括對錶，視圖，存儲過程和存儲函數的DML和DDL操做，
以及LOCK TABLES，FLUSH TABLES WITH READ LOCK和HANDLER語句。
此超時不適用於對mysql數據庫中系統表的隱式訪問，例如由GRANT或REVOKE語句或表記錄語句修改的受權表。
該超時功能適用於直接訪問的系統表，例如使用SELECT或UPDATE。

lock_wait_timeout=120
The timeout value applies separately for each metadata lock attempt. A given statement can
require more than one lock, so it is possible for the statement to block for longer than the
lock_wait_timeout value before reporting a timeout error.
--5.7
This variable specifies the timeout in seconds for attempts to acquire metadata locks.
The permissible values range from 1 to 31536000 (1 year). The default is 31536000

connect_timeout Default=10
mysql> set global connect_timeout=60;
The number of seconds that the mysqld server waits for a connect packet before responding with Bad handshake. The default value is 10 seconds.
Increasing the connect_timeout value might help if clients frequently encounter errors of the form Lost connection to MySQL server at 'XXX', system error: errno.
當一個鏈接上來，在三次握手的時候出現錯誤，mysql服務器會等待一段時間客戶端進行從新鏈接，connect_timeout就是服務端等待重連的時間了

net_write_timeout 做用：等待將一個block發送給客戶端的超時時間。現象：參數設置太小可能致使客戶端報錯
the last packet successfully received from the server was milliseconds ago，the last packet sent successfully to the server was milliseconds ago。
建議：該參數在RDS中默認設置爲60S，通常在網絡條件比較差的時，或者客戶端處理每一個block耗時比較長時，因爲net_write_timeout設置太小致使的鏈接中斷很容易發生，建議增長該參數的大小
| net_write_timeout | 60 |
set @@global.net_write_timeout=500;

skip-grant-tables :不使用mysql數據庫裏的信息來進行訪問控制(警告:這將容許用戶任何用戶去修改任何數據庫)。
skip-networking 開啓該選項能夠完全關閉MySQL的TCP/IP鏈接方式，若是WEB服務器是以遠程鏈接的方式訪問MySQL數據庫服務器則不要開啓該選項！不然將沒法正常鏈接！
---------------
skip-locking # 避免MySQL的外部鎖定，減小出錯概率加強穩定性。
skip-name-resolve 禁止MySQL對外部鏈接進行DNS解析，使用這一選項能夠消除MySQL進行DNS 解析的時間。但須要注意，
若是開啓該選項，則全部遠程主機鏈接受權都要使用IP地址方式，不然MySQL將沒法正常處理鏈接請求!
skip-ssl Do not use secure connection

back_log = 500 要求 MySQL 能有的鏈接數量。當主要MySQL線程在一個很短期內獲得很是多的鏈接請求，
這就起做用，而後主線程花些時間(儘管很短)檢查鏈接而且啓動一個新線程。
不須要配置 =50 + (max_connections / 5)，===50+ 3000/5=650
Default Value -1 (autosized)
back_log值指出在MySQL暫時中止回答新請求以前的短期內多少個請求能夠被存在堆棧中。只有若是指望在一個短期內有不少鏈接，
你須要增加它，換句話說，這值對到來的TCP/IP鏈接的偵聽隊列的大小。
你的操做系統在這個隊列大小上有它本身的限制。試圖設定 back_log高於你的操做系統的限制將是無效的。
當你觀察你的主機進程列表，發現大量 264084 | unauthenticated user | xxx.xxx.xxx.xxx | NULL | Connect | NULL | login |
NULL 的待鏈接進程時，就要加大 back_log 的值了。默認數值是50，我把它改成500。
做用：MySQL每處理一個鏈接請求的時候都會對應的建立一個新線程與之對應，那麼在主線程建立新線程期間，若是前端應用有
大量的短鏈接請求到達數據庫，MySQL 會限制此刻新的鏈接進入請求隊列，由參數back_log控制，若是等待的鏈接數量超過back_log，
則將不會接受新的鏈接請求，因此若是須要MySQL可以處理大量的短鏈接，須要提升此參數的大小。現象：若是參數太小可能會致使應用報錯
SQLSTATE[HY000] [2002] Connection timed out;
# ps aux|wc -l
innodb_autoinc_lock_mode
InnoDB爲了解決自增主鍵鎖表的問題，引入了參數innodb_autoinc_lock_mode，用於控制自增主鍵的鎖機制，該參數能夠設置的值爲0/1/2，
RDS 默認的參數值爲1，表示InnoDB使用輕量級別的mutex鎖來獲取自增鎖，替代最原始的表級鎖，可是在load data（包括：INSERT …
SELECT, REPLACE … SELECT）場景下會使用自增表鎖，這樣會則可能致使應用在併發導入數據出現死鎖。現象：若是應用併發使用
load data(包括：INSERT … SELECT, REPLACE … SELECT)導入數據的時候出現死鎖：
RECORD LOCKS space id xx page no xx n bits xx index PRIMARY of table xx.xx trx id xxx lock_mode X insert intention
waiting. TABLE LOCK table xxx.xxx trx id xxxx lock mode AUTO-INC waiting；
建議：建議將參數設置改成2，則表示全部狀況插入都使用輕量級別的mutex鎖(只針對row模式)，這樣就能夠避免auto_inc的死鎖，
同時在INSERT … SELECT 的場景下會提高很大的性能（注意該參數設置爲2，binlog的格式須要設置爲row）。

open_files_limit (打開文件數，linux的系統默認是1024）==my.cnf不配置，取值[root@hongquan soft]# ulimit -n
open_files_limit值總結以下：
my.cnf裏若是配置了open_files_limit
open_files_limit最後取值爲配置文件 open_files_limit，max_connections*5， wanted_files= 10+max_connections+table_cache_size*2 三者中的最大值。
若是my.cnf裏若是沒配置了open_files_limit
open_files_limit最後取值爲max_connections*5，10+max_connections+table_cache_size*2，ulimit -n中的最大者

[root@hongquan soft]# vim /etc/security/limits.conf
mysql soft nproc 65535
mysql hard nproc 65535
mysql soft nofile 65535
mysql hard nofile 65535
[root@hongquan soft]# source /etc/profile
[mysql@hongquan 3306]$ ulimit -a

key_buffer_size = 8M Size of buffer used for index blocks for MyISAM tables
# key_buffer_size指定用於索引的緩衝區大小，增長它可獲得更好處理的索引(對全部讀和多重寫)，到你能負擔得起那樣多。
若是你使它太大，系統將開始換頁而且真的變慢了。對於內存在4GB左右的服務器該參數可設置爲384M或512M。經過檢查狀態值Key_read_requests和Key_reads,能夠知道key_buffer_size設置是否合理。
比例key_reads / key_read_requests應該儘量的低，至少是1:100，1:1000更好(上述狀態值可使用SHOW STATUS LIKE 'key_read%'得到)。注意：該參數值設置的過大反而會是服務器總體效率下降!
(system@127.0.0.1:3306) [sys]> SHOW STATUS LIKE 'key_read%';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Key_read_requests | 126 |
| Key_reads | 5 |

使用排序
mysql> show global status like 'sort%';
+-------------------+--------+
| Variable_name | Value |
+-------------------+--------+
| Sort_merge_passes | 0 |
| Sort_range | 20576 |
| Sort_rows | 830484 |
| Sort_scan | 637562 |
+-------------------+--------+
Sort_merge_passes 包括兩步。MySQL 首先會嘗試在內存中作排序，使用的內存大小由系統變量 Sort_buffer_size 決定，
若是它的大小不夠把全部的記錄都讀到內存中，MySQL 就會把每次在內存中排序的結果存到臨時文件中，等 MySQL 找到所
有記錄以後，再把臨時文件中的記錄作一次排序。這再次排序就會增長 Sort_merge_passes。實際上，MySQL 會用另外一個
臨時文件來存再次排序的結果，因此一般會看到 Sort_merge_passes 增長的數值是建臨時文件數的兩倍。由於用到了臨時
文件，因此速度可能會比較慢，增長 Sort_buffer_size 會減小 Sort_merge_passes 和建立臨時文件的次數。但盲目的
增長 Sort_buffer_size 並不必定能提升速度

開啓慢查詢日誌( slow query log )
慢查詢日誌對於跟蹤有問題的查詢很是有用。它記錄全部查過long_query_time的查詢，若是須要，還能夠記錄不使用索引的記錄。下面是一個慢查詢日誌的例子：
開啓慢查詢日誌，須要設置參數log_slow_queries、long_query_times、log-queries-not-using- indexes。
log_slow_queries指定日誌文件，若是不提供文件名，MySQL將本身產生缺省文件名。long_query_times指定慢查詢的閾值，缺省是10秒。
log-queries-not-using-indexes是4.1.0之後引入的參數，它指示記錄不使用索引的查詢。設置 long_query_time=10
使用show status命令
aborted_clients 客戶端非法中斷鏈接次數
aborted_connects 鏈接mysql失敗次數
com_xxx xxx命令執行次數,有不少條
connections 鏈接mysql的數量 The number of connection attempts (successful or not) to the MySQL server.
Created_tmp_disk_tables 在磁盤上建立的臨時表
Created_tmp_tables 在內存裏建立的臨時表
Created_tmp_files 臨時文件數
Key_read_requests The number of requests to read a key block from the cache
Key_reads The number of physical reads of a key block from disk
Max_used_connections 同時使用的鏈接數
Open_tables 開放的表
Open_files 開放的文件
Opened_tables 打開過的表的數量
mysql> show global status like 'open%tables%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_tables | 300 |
| Opened_tables | 313 |
Open_tables / Opened_tables * 100% >= 85%
Open_tables / table_cache * 100% <= 95%
Questions 提交到server的查詢數
Sort_merge_passes 若是這個值很大,應該增長my.cnf中的sort_buffer值

Uptime 服務器已經工做的秒數
提高性能的建議:
1.若是opened_tables太大,應該把my.cnf中的table_cache變大
2.若是Key_reads太大,則應該把my.cnf中key_buffer_size變大.能夠用 Key_reads/Key_read_requests計算出cache失敗率
3.若是Handler_read_rnd太大,則你寫的SQL語句裏不少查詢都是要掃描整個表,而沒有發揮索引的鍵的做用
4.若是Threads_created太大,就要增長my.cnf中thread_cache_size的值.能夠用 Threads_created/Connections計算cache命中率
5.若是Created_tmp_disk_tables太大,就要增長my.cnf中tmp_table_size的值,用基於內存的臨時表代替基於磁盤的

set profiling =1;
insert

innodb_buffer_pool_size is configured to 50 to 75 percent of system memory
innodb_buffer_pool_size:主要針對InnoDB表性能影響最大的一個參數。功能與Key_buffer_size同樣。InnoDB佔用的內存，
除innodb_buffer_pool_size用於存儲頁面緩存數據外，另外正常狀況下還有大約8%的開銷，主要用在每一個緩存頁幀的描述、adaptive hash等數據結構
另外InnoDB和 MyISAM 存儲引擎不一樣， MyISAM 的 key_buffer_size 只能緩存索引鍵，而 innodb_buffer_pool_size 卻能夠緩存數據塊和索引鍵。
適當的增長這個參數的大小，能夠有效的減小 InnoDB 類型的表的磁盤 I/O
當咱們操做一個 InnoDB 表的時候，返回的全部數據或者去數據過程當中用到的任何一個索引塊，都會在這個內存區域中走一遭。
能夠經過 (Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100% 計算緩存命中率，
並根據命中率來調整 innodb_buffer_pool_size 參數大小進行優化。值能夠用如下命令查
innodb_buffer_pool_instances=8 將innodb_buffer_pool劃分爲不一樣的instance，每一個instance獨立的LRU、FLUSH、FREE
InnoDB_buffer_pool_instances:8 (platform dependent) 5.6.6
innodb_log_file_size=512M 官方文檔建議最好不要超過innodb_log_files_in_group*innodb_log_file_size的0.75， innodb_log_files_in_group的default值爲2.
logfile大小對於性能的影響主要體如今checkpoint上
innodb_log_files_in_group=3
innodb_log_group_home_dir
innodb_log_buffer_size=200M 默認8388608先寫入innodb_log_buffer，buffer寫滿或事務提交，刷新數據，大事務頻繁，增長innodb_log_buffer_size大小
innodb_thread_concurrency=(64-128) ，default 0 表示沒有併發線程的限制，全部請求都會直接請求線程執行，innodb內部本身控制 kernel_mutex競爭
設置太高值，可能會由於系統資源內部爭奪致使性能降低，
併發查詢和併發鏈接
innodb_io_capacity=1000 innodb每秒後臺進程處理IO操做的數據頁上限，default 200,測試的虛擬機，200或者100
innodb_buffer_pool_size總的io處理能力上限
innodb_buffer_pool_instances分割成多個內存塊時，每一個內存塊的IO處理能力爲：innodb_io_capacity/innodb_buffer_pool_instances
對於個別5400轉或7200轉硬盤系統上，可能下降值的100前者默認。
innodb_flush_neighbors This option optimizes I/O for rotational storage devices. Disable it for non-rotational storage or a mix of rotational and non-rotational storage.
innodb_io_capacity The default setting of 200 is generally sufficient for a lower-end non-rotational storage device. For higher-end, bus-attached devices, consider a higher setting such as 1000
innodb_io_capacity_max The default value of 2000 is intended for workloads that use non-rotational storage. For a highend, bus-attached non-rotational storage device, consider a higher setting such as 2500
innodb_lru_scan_depth 每一個緩衝池實例，緩衝池LRU在多大程度上列出了頁面清理線程These options primarily help write-intensive workloads. With heavy DML activity, flushing can fall
behind if it is not aggressive enough, resulting in excessive memory use in the buffer pool or, disk
writes due to flushing can saturate your I/O capacity if that mechanism is too aggressive

Optimizing InnoDB Disk I/O
The configuration options innodb_flush_neighbors and innodb_lru_scan_depth let you finetune aspects of the flushing process for the InnoDB buffer pool.
innodb_flush_neighbors 在buffer pool中刷新髒頁時是否刷新其餘髒頁，在hdd磁盤上，刷新鄰居頁面會減小磁盤的io消耗，在ssd來講，這個能夠禁用。

(system@127.0.0.1:3306) [(none)]> SHOW GLOBAL VARIABLES LIKE 'innodb_lru_scan_depth';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| innodb_lru_scan_depth | 1024 |
+-----------------------+-------+
而從MySQL 5.6版本，也就是InnoDB1.2.x版本開始，這個檢查被放在了一個單獨的Page Cleaner線程中進行，而且用戶能夠經過參數innodb_lru_scan_depth控制LRU列表中可用頁的數量，該值默認爲1024
innodb_max_dirty_pages_pct=60 default 75 InnoDB試着從緩衝池刷新數據，使髒頁的百分比不超過這個值
innodb從innodb buffer中刷新髒頁的比例
刷新髒頁，產生checkpoint
髒頁刷新innodb_max_dirty_pages_pct * innodb_io_capacity
innodb_flush_method=O_DIRECT 定義用於刷新數據到InnoDB數據文件和日誌文件的方法，這可能會影響I / O吞吐量。
O_DSYNC：使用O_SYNC打開和刷新log文件，使用fsync()刷新數據文件。
O_DIRECT：使用O_DIRECT打開數據文件，使用fsync()刷新日誌文件和數據文件
在raid設備上，爲了不數據被innodb_buffer和raid屢次cache，設置爲O_DIRECT方式
fdatasync模式：寫數據時，write這一步並不須要真正寫到磁盤纔算完成（可能寫入到操做系統buffer中就會返回完成），
真正完成是flush操做，buffer交給操做系統去flush,而且文件的元數據信息也都須要更新到磁盤。
O_DSYNC模式：寫日誌操做是在write這步完成，而數據文件的寫入是在flush這步經過fsync完成
O_DIRECT模式：數據文件的寫入操做是直接從mysql innodb buffer到磁盤的，並不用經過操做系統的緩衝，
而真正的完成也是在flush這步,日誌(redo log)仍是要通過OS緩衝

innodb_file_per_table=1 Permitted Values (>= 5.6.6) Default ON 不一樣的表空間能夠靈活設置數據目錄的地址避免共享表空間產生的IO競爭
innodb_flush_log_at_trx_commit=1 default 1
0：每秒將log buffer的內容寫事務日誌而且刷新到磁盤；
1：每一個事務提交後，將log_buffer的內容寫事務日誌並數據磁盤；---大量事務提交，磁盤io增長
2：每一個事務提交，將log_buffer內容寫事務日誌，但不進行數據刷盤，在整個操做系統掛了時纔可能丟數據，通常不會丟失超過1-2秒的更新。
sync_binlog=1 非核心數據庫，能夠不設置爲1，提升性能
雙1模式，即：innodb_flush_log_at_trx_commit = 1，sync_binlog = 1，這樣主備的數據是一致的，不會丟失數據
sync_binlog=1 Mysql在提交事務時調用MYSQL_LOG::write完成寫binlog，並根據sync_binlog決定是否進行刷盤。
默認值是0，即不刷盤，從而把控制權讓給OS。若是設爲1，則每次提交事務，就會進行一次刷盤；這對性能有影響
(5.6已經支持binlog group)，因此不少人將其設置爲100
innodb_flush_log_at_trx_commit=1 該參數控制innodb在提交事務時刷redo log的行爲。默認值爲1，即每次提交事務，
都進行刷盤操做。爲了下降對性能的影響，在不少生產環境設置爲2，甚至0
innodb_support_xa=1 用於控制innodb是否支持XA事務的2PC，默認是TRUE。若是關閉，則innodb在prepare階段就什麼
也不作；這可能會致使binlog的順序與innodb提交的順序不一致(好比A事務比B事務先寫binlog，
可是在innodb內部卻可能A事務比B事務後提交)，這會致使在恢復或者slave產生不一樣的數據。
binlog_row_image='minimal' 5.7
上面3個參數不一樣的值會帶來不一樣的效果。三者都設置爲1(TRUE)，數據才能真正安全
sync_binlog非1，可能致使binlog丟失(OS掛掉)，從而與innodb層面的數據不一致
innodb_flush_log_at_trx_commit非1，可能會致使innodb層面的數據丟失(OS掛掉)，從而與binlog不一致。

skip-external-locking：default on，每一個進程若要訪問數據表，則必須等待以前的進程完成操做並解除鎖定。
lower_case_table_names 數據庫大小寫是否敏感，默認=0 （區分大小寫），
設置爲1後，表名能夠正常忽略大小寫，可是若是是爲0時建立的數據庫如Test這樣，而後修改成1，進行查詢test是查詢不到的，務必謹記
safe-user-create 只有在mysql.user數據庫表上擁有INSERT權限的用戶才能使用GRANT命令; 這是一種雙保險機制(此用戶還必須具有GRANT權限才能執行GRANT命令)
GRANT INSERT(user) ON mysql.user TO 'user_name'@'host_name';
local-infile=1 要支持命令load data local infile，應當在/etc/mysql/my.cnf中添加這樣的設置:
transaction-isolation
mysql> show variables like 'tx_isolation';
+---------------+----------------+
| Variable_name | Value |
+---------------+----------------+
| tx_isolation | READ-COMMITTED | REPEATABLE-READ
READ-COMMITTED 讀取提交內容（oracle默認）
REPEATABLE-READ 可重讀（mysql默認）
max_binlog_size=1073741824
max_binlog_cache_size

If a transaction requires more than this many bytes of memory, the server generates a Multi-statement
transaction required more than 'max_binlog_cache_size' bytes of storage error. The minimum value is 4096.
The maximum possible value is 16EB (exabytes). The maximum recommended value is 4GB; this is due to the fact
that MySQL currently cannot work with binary log positions greater than 4GB.

binlog_cache_size 爲每一個session 分配的內存，在事務過程當中用來存儲二進制日誌的緩存，沒有什麼大事務，
dml也不是很頻繁的狀況下能夠設置小一點，若是事務大並且多，dml操做也頻繁，則能夠適當的調大一點
mysql> show global status like 'bin%';
+----------------------------+-------+
| Variable_name | Value |
+----------------------------+-------+
| Binlog_cache_disk_use | 0 |
| Binlog_cache_use | 1 |
Binlog_cache_disk_use表示由於咱們binlog_cache_size設計的內存不足致使緩存二進制日誌用到了臨時文件的次數
Binlog_cache_use 表示用binlog_cache_size緩存的次數
當對應的Binlog_cache_disk_use 值比較大的時候咱們能夠考慮適當的調高 binlog_cache_size 對應的值

innodb_rollback_on_timeout 該變量默認值爲OFF，若是事務由於加鎖超時，會回滾上一條語句執行的操做。若是設置ON，則整個事務都會回滾。
a.max_binlog_cache_size 表示的是binlog 可以使用的最大cache 內存大小
當咱們執行多語句事務的時候全部session的使用的內存超過max_binlog_cache_size的值時
就會報錯：「Multi-statement transaction required more than 'max_binlog_cache_size' bytes ofstorage」
b.設置太大的話，會比較消耗內存資源;設置過小又會使用到臨時文件即disk

performance_schema (>= 5.6.6) ON
log_slow_admin_statements 包括行政語句的語句寫入緩慢慢查詢日誌。管理報表包括ALTER TABLE,分析表,檢查表,建立索引,指數降低,優化表、和維修表。
table_definition_cache (>= 5.6.8) -1 (autosized) 若是你使用大量的表,您能夠建立一個大表定義緩存加速的表。須要更少的空間和表定義緩存

複製有關的參數
#replication
master-info-file=Default master.info，默認路徑/data/mysqldata/3307/data/master.info
The name to use for the file in which the slave records information about the master.
relay_log 中繼日誌文件
relay_log_info_file
relay-log-index
slave_type_conversions =ALL_LOSSY，ALL_NON_LOSSY
ALL_SIGNED and ALL_UNSIGNED were added in MySQL 5.6.13 (Bug#15831300).
ALL_LOSSY容許數據截斷
ALL_NON_LOSSY不容許數據截斷，若是從庫類型大於主庫類型，是能夠複製的，翻過了，就不行了，從庫報復制錯誤，複製終止。
ALL_LOSSY,ALL_NON_LOSSY: 全部容許的轉換都會執行，而無論是否是數據丟失。
空值（不設置）：要求主從庫的數據類型必須嚴格一致，不然都報錯。

skip_slave_start: Default FALSE,默認在啓動mysql 的時候啓動slave threads 線程,skip-slave-start: DESCRIPTION: If set, slave is not autostarted
slave_exec_mode=STRICT ：Default，STRICT (ALL)
slave_load_tmpdir
slave_max_allowed_packet=1073741824
slave_net_timeout=3600:The number of seconds to wait for more data from a master/slave connection before aborting the read. 改爲slave_net_timeout=60
slave_parallel_workers=0:Sets the number of slave worker threads for executing replication events (transactions) in parallel.
slave_skip_errors=OFF
sync_master_info
sync_relay_log_info
sync_relay_log 默認值是10000，也就是10000個事物進行一次fdatasync。
skip_name_resolve 關閉dns查找
slave_net_timeout=60 #意味着在沒有獲得更多數據以後slave等待的時間，默認值3600s
master-connect-retry #意味着每次和主庫創建連接重試的等待時間，默認值爲60s
master-retry-count #意味着從庫同主庫創建連接的重試次數，默認86400次
log-slave-updates 這個參數用來配置從服務器的更新是否寫入二進制日誌
log-slave-updates=1
rpl_semi_sync_master_enabled=1 是否在master節點開啓半同步複製，Default OFF
rpl_semi_sync_master_timeout=3 知道master等待響應slave的時間，毫秒，超出時間，將轉變爲異步複製，Default 10000
rpl_semi_sync_slave_enabled=1 控制slave是否開啓半同步複製 Default OFF
rpl_semi_sync_master_clients 顯示當前處於半同步模式的slave節點數量
rpl_semi_sync_master_status 標示當前master是否啓動半同步模式
rpl_semi_sync_master_no_tx 當前未成功發送到slave節點事務數量
rpl_semi_sync_master_yes_tx 當前已成功發送到slave節點的事務數量
enable_table_relay_info = 1 #開啓crash safe功能
relay_log_recovery = 1 #開啓crash safe功能，默認| relay_log_recovery | OFF |
relay_log_purge = 1 #default no
slave_parallel_threads=16 #並行複製的線程數
relay-log-recovery: Enables automatic recovery of relay log files from master at startup
relay_log_recovery: Whether automatic recovery of relay log files from master at startup is enabled;must be enabled for a crash-safe slave
? replicate-do-db: Tells the slave SQL thread to restrict replication to the specified database
? replicate-do-table: Tells the slave SQL thread to restrict replication to the specified table
? replicate-ignore-db: Tells the slave SQL thread not to replicate to the specified database
? replicate-ignore-table: Tells the slave SQL thread not to replicate to the specified table
? replicate-rewrite-db: Updates to a database with a different name than the original
? replicate-same-server-id: In replication, if set to 1, do not skip events having our server id
? replicate-wild-do-table: Tells the slave thread to restrict replication to the tables that match the specified wildcard pattern
? replicate-wild-ignore-table: Tells the slave thread not to replicate to the tables that match the given wildcard pattern

主上：
rpl_semi_sync_master_enabled：表示主上是否開啓半同步複製功能，能夠動態修改。可選值：ON\OFF
rpl_semi_sync_master_timeout：爲了防止半同步複製中主在沒有收到S發出的確認發生堵塞，用來設置超時，超過這個時間值沒有收到信息，
則切換到異步複製，執行操做。默認爲10000毫秒，等於10秒，這個參數動態可調，表示主庫在某次事務中，若是等待時間超過10秒，
那麼則降級爲異步複製模式，再也不等待SLAVE從庫。若是主庫再次探測到，SLAVE從庫恢復了，則會自動再次回到半同步複製模式。能夠設置成1000，即1秒。
rpl_semi_sync_master_wait_for_slave_count：控制slave應答的數量，默認是1，表示master接收到幾個slave應答後才commit。
rpl_semi_sync_master_wait_no_slave ：當一個事務被提交，可是Master沒有Slave鏈接，這時M不可能收到任何確認信息，但M會在時間限制範圍內繼續等待。
若是沒有Slave連接，會切換到異步複製。是否容許master每一個事務提交後都要等待slave的接收確認信號。默認爲on，每個事務都會等待。若是爲off，
則slave追遇上後，也不會開啓半同步複製模式，須要手工開啓。
rpl_semi_sync_master_wait_point：該參數表示半同步複製的主在哪一個點等待從的響應，默認AFTER_SYNC，在獲得slave的應答後再commit，可選值AFTER_COMMIT。

從上：
rpl_semi_sync_slave_enabled：表示從上是否開啓半同步複製功能，能夠動態修改。可選值：ON\OFF
Rpl_semi_sync_master_clients ：說明支持和註冊半同步複製的已連Slave數。
Rpl_semi_sync_master_net_avg_wait_time ：master等待slave回覆的平均等待時間，單位毫秒。
Rpl_semi_sync_master_net_wait_time ：master總的等待時間。Rpl_semi_sync_master_net_waits ：master等待slave回覆的的總的等待次數，即半同步複製的總次數，
無論失敗仍是成功，不算半同步失敗後的異步複製。Rpl_semi_sync_master_no_times ：master關閉半同步複製的次數。
Rpl_semi_sync_master_no_tx ：master沒有收到slave的回覆而提交的次數，能夠理解爲master等待超時的次數，即半同步模式不成功提交數量。
Rpl_semi_sync_master_status ：ON是活動狀態（半同步），OFF是非活動狀態（異步），用於表示主服務器使用的是異步複製模式，仍是半同步複製模式。
Rpl_semi_sync_slave_status ：Slave上的半同步複製狀態，ON表示已經被啓用，OFF表示非活動狀態。
Rpl_semi_sync_master_tx_avg_wait_time ：master花在每一個事務上的平均等待時間。
Rpl_semi_sync_master_tx_wait_time ：master總的等待時間。
Rpl_semi_sync_master_tx_waits ：master等待成功的次數，即master沒有等待超時的次數，也就是成功提交的次數
Rpl_semi_sync_master_wait_pos_backtraverse ：master提交後來的先到了，而先來的尚未到的次數。
Rpl_semi_sync_master_wait_sessions ：前有多少個session由於slave的回覆而形成等待。Rpl_semi_sync_master_yes_tx ：master成功接收到slave的回覆的次數，即半同步模式成功提交數量。

SET GLOBAL SQL_SLAVE_SKIP_COUNTER =1;
--slave-skip-errors=1062,1053
--slave-skip-errors=all
--slave-skip-errors=ddl_exist_errors
[mysqld]
gtid_mode=ON #啓用gtid類型，不然就是普通的複製架構
log-slave-updates=ON #slave更新是否記入日誌
enforce-gtid-consistency=ON #強制GTID的一致性
binlog_format=row #二進制格式改成行row模式
#當設置隔離級別爲READ-COMMITED必須設置二進制日誌格式爲ROW
sync-master-info=1 # 同步主庫信息，確保服務器崩潰時無信息丟失
slave-parallel-workers=4 #從服務器的SQL線程數，要複製庫數目相同
binlog-checksum=CRC32 # 校驗碼
master-verify-checksum=1 # 主服校驗
slave-sql-verify-checksum=1 #從服校驗
binlog-rows-query-log_events=1 # 二進制日誌詳細記錄事件
report-port=3306 # 提供複製報告端口
report-host=station20.example.com #提供複製報告主機

#gitd
gtid_mode = on
enforce_gtid_consistency = 1
transaction-isolation=READ-COMMITTED
binlog_format=row
log_bin=/data/mysqldata/3306/binlog/mysql-bin
log_slave_updates=ON
--5.7 並行複製
# slave
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=16
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON
mysql> show tables like 'replication%';
+---------------------------------------------+
| Tables_in_performance_schema (replication%) |
+---------------------------------------------+
| replication_applier_configuration |
| replication_applier_status |
| replication_applier_status_by_coordinator |
| replication_applier_status_by_worker |
| replication_connection_configuration |
| replication_connection_status |
| replication_group_member_stats |
| replication_group_members |
並行複製配置與調優
master_info_repository 開啓MTS功能後，務必將參數master_info_repostitory設置爲TABLE
slave_parallel_workers 若將slave_parallel_workers設置爲0，則MySQL 5.7退化爲原單線程複製，將slave_parallel_workers設置爲1
，則SQL線程功能轉化爲coordinator線程，可是隻有1個worker線程進行回放，也是單線程複製。然而，這兩種性能卻又有一些的區別，由於多了
一次coordinator線程的轉發，所以slave_parallel_workers=1的性能反而比0還要差
這裏其中引入了另外一個問題，若是主機上的負載不大，那麼組提交的效率就不高，頗有可能發生每組提交的事務數量僅有1個，那麼在從機
的回放時，雖然開啓了並行複製，但會出現性能反而比原先的單線程還要差的現象，即延遲反而增大了

建立函數
log_bin_trust_function_creators=1；
A setting of 0 also enforces the restriction that a function must be declared with the DETERMINISTIC characteristic, or with the READS SQL DATA or NO SQL characteristic.
mysql> SHOW SLAVE STATUS\G
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it

SET GLOBAL sql_mode = 'modes';
SET SESSION sql_mode = 'modes';

1(SRV_FORCE_IGNORE_CORRUPT):忽略檢查到的corrupt頁。
2(SRV_FORCE_NO_BACKGROUND):阻止主線程的運行，如主線程須要執行full purge操做，會致使crash。
3(SRV_FORCE_NO_TRX_UNDO):不執行事務回滾操做。
4(SRV_FORCE_NO_IBUF_MERGE):不執行插入緩衝的合併操做。
5(SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重作日誌，InnoDB存儲引擎會將未提交的事務視爲已提交。
6(SRV_FORCE_NO_LOG_REDO):不執行前滾的操做。
innodb_force_recovery default 0
1 (SRV_FORCE_IGNORE_CORRUPT)
Lets the server run even if it detects a corrupt page. Tries to make SELECT * FROM tbl_name jump over corrupt index records and pages, which helps in dumping tables.
2 (SRV_FORCE_NO_BACKGROUND)
Prevents the master thread and any purge threads from running. If a crash would occur during the purge operation, this recovery value prevents it.
3 (SRV_FORCE_NO_TRX_UNDO)
Does not run transaction rollbacks after crash recovery.
4 (SRV_FORCE_NO_IBUF_MERGE)
Prevents insert buffer merge operations. If they would cause a crash, does not do them. Does not calculate table statistics.
This value can permanently corrupt data files. After using this value, be prepared to drop and recreate all secondary indexes.
As of MySQL 5.6.15, sets InnoDB to read-only.
5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
Does not look at undo logs when starting the database: InnoDB treats even incomplete transactions as committed.
This value can permanently corrupt data files. As of MySQL 5.6.15, sets InnoDB to read-only.
6 (SRV_FORCE_NO_LOG_REDO)
Does not do the redo log roll-forward in connection with recovery. This value can permanently corrupt data files.
Leaves database pages in an obsolete state, which in turn may introduce more corruption into B-trees and other database structures. As of MySQL 5.6.15, sets InnoDB to read-only.

innodb_purge_threads Dynamic No
Permitted Values (>= 5.6.5)，Default 1
The number of background threads devoted to the InnoDB purge operation.
Default Value (>= 5.7.8) 4

innodb_additional_mem_pool_size 所設置的是用於存放 Innodb 的字典信息和其餘一些內部結構所須要的內存空間
InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
innodb_use_sys_malloc
Default ON
設置爲0：表示Innodb使用自帶的內存分配程序，設置爲1：表示InnoDB使用操做系統的內存分配程序
Whether InnoDB uses the operating system memory allocator (ON) or its own (OFF). The default value is ON. See Section 14.6.4, 「Configuring the Memory Allocator for InnoDB」 for more information.
innodb_open_files InnoDB一次能夠保持打開的.ibd文件的最大數目(
>= 5.6.6 Max Value 4294967295 Default -1 (autosized)
<= 5.6.5 Default 300
thread_stack 64-bit platforms Default 262144，256KB for 64-bit systems
The stack size for each thread. Many of the limits detected by the crash-me test are dependent on this value.
thread_cache_size
How many threads the server should cache for reuse. When a client disconnects,
the client's threads are put in the cache if there are fewer than thread_cache_size threads there.
This variable can be increased to improve performance if you have a lot of new connections.

show status like 'Opened_files';--當前打開表的數量
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Opened_files | 180 |
| table_definition_cache | 1400 |
| table_open_cache | 2000 |
| table_open_cache_instances | 1
一個是打開表的緩存 ---> table_open_cache，每打開一個表，都會讀入該值中，當mysql在緩存中找不到，纔會讀取磁盤
一個是表定義的緩存 ---> table_definition_cache
mysql> show variables like 'open%';
mysql> show variables like 'thread%';
每當客戶端鏈接到mysql數據庫時，mysql會建立一個線程爲他服務，可是mysql首先回去thread_cache中去找，找不到纔會建立新的線程
mysql> show variables like 'thread%';
+--------------------+---------------------------+
| Variable_name | Value |
+--------------------+---------------------------+
| thread_cache_size | 28 |
| thread_concurrency | 10 |
| thread_handling | one-thread-per-connection |
| thread_stack | 262144
slow_launch_time
log_warnings
Permitted Values (64-bit platforms) Default 1
Whether to produce additional warning messages to the error log,This variable is enabled (1) by default and can be disabled by setting it to 0,
log_slow_admin_statements
NO_AUTO_CREATE_USER
NO_ZERO_DATE
NO_ZERO_IN_DATE
ERROR_FOR_DIVISION_BY_ZERO

sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER
(system@127.0.0.1:3306) [test]> show variables like 'sql_mode';
+---------------+------------------------------------------------------------------------------------------------------------------------+
| Variable_name | Value |
+---------------+------------------------------------------------------------------------------------------------------------------------+
| sql_mode | STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+---------------+------------------------------------------------------------------------------------------------------------------------+
(system@127.0.0.1:3306) [(none)]> show variables like 'sql_mode'; ##5.6.6 default
+---------------+------------------------+
| Variable_name | Value |
+---------------+------------------------+
| sql_mode | NO_ENGINE_SUBSTITUTION |
+---------------+------------------------+
Default Value (>= 5.7.8) ONLY_FULL_GROUP_BY STRICT_TRANS_TABLES NO_ZERO_IN_DATE NO_ZERO_DATE ERROR_FOR_DIVISION_BY_ZERO NO_AUTO_CREATE_USER NO_ENGINE_SUBSTITUTION

mysql常見啓動錯誤----my.cnf中關於innodb的配置，儘可能用默認值，否則不清楚的就容易搞錯
#innodb

innodb_data_file_path=ibdata1:12M:autoextend
innodb_log_file_size=256m
innodb_log_files_in_group=3
innodb_buffer_pool_size=512M

InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
02:56:13 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

key_buffer_size=8388608
read_buffer_size=1048576
max_used_connections=0
max_threads=214
thread_count=0
connection_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 449363 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x80000
2016-08-02 19:56:13 11665 [Note] InnoDB: 5.6.13 started; log sequence number 1755215
/usr/local/mysql/bin/mysqld(my_print_stacktrace+0x35)[0x8ad2a5]
/usr/local/mysql/bin/mysqld(handle_fatal_signal+0x40b)[0x62aa7b]
/lib64/libpthread.so.0[0x308860f710]
/lib64/libc.so.6(gsignal+0x35)[0x3088232625]
/lib64/libc.so.6(abort+0x175)[0x3088233e05]
/usr/local/mysql/bin/mysqld[0x97b092]
/usr/local/mysql/bin/mysqld[0x97bd2e]
/usr/local/mysql/bin/mysqld[0x97c503]
/usr/local/mysql/bin/mysqld[0x96e1fa]
/lib64/libpthread.so.0[0x30886079d1]
/lib64/libc.so.6(clone+0x6d)[0x30882e89dd]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
160802 19:56:14 mysqld_safe mysqld from pid file /data/mysqldata/3306/mysql.pid ended

2016-08-02 20:13:51 12831 [Note] InnoDB: 5.6.13 started; log sequence number 1755215
2016-08-02 20:13:51 12831 [Note] InnoDB: !!! innodb_force_recovery is set to 1 !!!
-------------
innodb_force_recovery=6
innodb_purge_threads=0
./mysqldump_full_bk_yhq.sh
/usr/local/mysql/scripts/mysql_install_db --datadir=/data/mysqldata/3306/data --basedir=/usr/local/mysql
mysqld_safe --defaults-file=/data/mysqldata/3306/my.cnf &
mysql -S /data/mysqldata/3306/mysql.sock<20160802-2025.sql

---
160803 00:45:35 mysqld_safe Number of processes running now: 0
160803 00:45:35 mysqld_safe mysqld restarted
2016-08-03 00:45:47 16581 [Warning] Buffered warning: Could not increase number of max_open_files to more than 1024 (request: 65536)
2016-08-03 00:45:47 16581 [Warning] Buffered warning: Changed limits: max_connections: 214 (requested 4500)
2016-08-03 00:45:47 16581 [Warning] Buffered warning: Changed limits: table_cache: 400 (requested 2000)
2016-08-03 00:45:47 16581 [Warning] Using unique option prefix innodb_read_ahead instead of innodb-read-ahead-threshold is deprecated and will be removed in a future release. Please use the full name instead.

table_cache * 2 + max_connections＝max_open_files

ls -lh /proc/16581/fd|wc -l

2016-08-03 02:02:32 17791 [Warning] 'proxies_priv' entry '@ root@hongquan.mysql2' ignored in --skip-name-resolve mode.

2016-08-03 02:01:58 16581 [Note] Giving 1 client threads a chance to die gracefully
2016-08-03 02:01:58 16581 [Note] Event Scheduler: Purging the queue. 0 events
2016-08-03 02:01:58 16581 [Note] Shutting down slave threads
2016-08-03 02:02:00 16581 [Note] Forcefully disconnecting 1 remaining clients
2016-08-03 02:02:00 16581 [Warning] /usr/local/mysql/bin/mysqld: Forcing close of thread 3 user: 'system'

2016-08-03 02:02:00 16581 [Note] Binlog end

160803 23:32:32 mysqld_safe Starting mysqld daemon with databases from /data/mysqldata/3306/data
2016-08-03 23:32:42 3414 [Warning] Buffered warning: Could not increase number of max_open_files to more than 65535 (request: 65536)

2016-08-03 23:32:42 3414 [Warning] Buffered warning: Performance schema disabled (reason: init failed).
--http://bugs.mysql.com/bug.php?id=72719
2016-08-03 23:32:42 7f74a8a11720 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the option innodb_use_sys_malloc and with the InnoDB's internal memory allocator.
--#innodb_additional_mem_pool_size

016-08-03 23:32:42 3414 [Note] InnoDB: Initializing buffer pool, size = 512.0M
InnoDB: mmap(549453824 bytes) failed; errno 12
2016-08-03 23:32:42 3414 [ERROR] InnoDB: Cannot allocate memory for the buffer pool
2016-08-03 23:32:42 3414 [ERROR] Plugin 'InnoDB' init function returned error.
2016-08-03 23:32:42 3414 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2016-08-03 23:32:42 3414 [ERROR] Unknown/unsupported storage engine: INNODB
2016-08-03 23:32:42 3414 [ERROR] Aborting

innodb_buffer_pool_size=512M

innodb_use_sys_malloc=0
2016-08-03 23:59:30 6677 [Warning] Buffered warning: Performance schema disabled (reason: init failed).
2016-08-03 23:59:31 6677 [Note] Plugin 'FEDERATED' is disabled.
2016-08-03 23:59:31 7f63be3a9720 InnoDB: Warning: Setting innodb_use_sys_malloc to FALSE is DEPRECATED. This option may be removed in future releases, together with the InnoDB's internal memory allocator.

--#innodb_use_sys_malloc=0
2016-08-04 00:05:52 8837 [Warning] Buffered warning: Performance schema disabled (reason: init failed).
2016-08-04 00:05:52 8837 [Note] Plugin 'FEDERATED' is disabled.
2016-08-04 00:05:52 8837 [Note] InnoDB: The InnoDB memory heap is disabled
2016-08-04 00:05:52 8837 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2016-08-04 00:05:52 8837 [Note] InnoDB: Compressed tables use zlib 1.2.3
2016-08-04 00:05:52 8837 [Note] InnoDB: Using CPU crc32 instructions
2016-08-04 00:05:52 8837 [Note] InnoDB: Initializing buffer pool, size = 256.0M
InnoDB: mmap(274726912 bytes) failed; errno 12
2016-08-04 00:05:52 8837 [ERROR] InnoDB: Cannot allocate memory for the buffer pool
2016-08-04 00:05:52 8837 [ERROR] Plugin 'InnoDB' init function returned error.
2016-08-04 00:05:52 8837 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2016-08-04 00:05:52 8837 [ERROR] Unknown/unsupported storage engine: INNODB
2016-08-04 00:05:52 8837 [ERROR] Aborting

max_connections=2000
max_user_connections=1500
mysql> show variables like '%cache%';
註釋掉參數
#table_definition_cache=65535
#table_cache=65536
| table_definition_cache | 1400 |
| table_open_cache | 2000 |
| table_open_cache_instances | 1
2016-08-04 00:21:45 9931 [Note] /usr/local/mysql/bin/mysqld: ready for connections.
Version: '5.6.13-r5436-log' socket: '/data/mysqldata/3306/mysql.sock' port: 3306 Source distribution
160804 20:49:29 mysqld_safe Number of processes running now: 0
160804 20:49:29 mysqld_safe mysqld restarted
2016-08-04 20:49:39 16897 [Note] Plugin 'FEDERATED' is disabled.
InnoDB: Doing recovery: scanned up to log sequence number 620450816
160804 21:36:39 mysqld_safe mysqld from pid file /data/mysqldata/3306/mysql.pid ended

innodb_force_recovery=6
2016-08-04 22:50:15 7568 [Note] InnoDB: Highest supported file format is Barracuda.
2016-08-04 22:50:15 7568 [Note] InnoDB: The user has set SRV_FORCE_NO_LOG_REDO on, skipping log redo
2016-08-04 22:50:15 7568 [Note] InnoDB: 5.6.13 started; log sequence number 0
2016-08-04 22:50:15 7568 [Note] InnoDB: !!! innodb_force_recovery is set to 6 !!!
2016-08-04 22:50:16 7568 [Note] Recovering after a crash using /data/mysqldata/3306/binlog/mysql-bin
2016-08-04 22:50:16 7568 [Note] Starting crash recovery...
2016-08-04 22:50:16 7568 [Note] Crash recovery finished.
2016-08-04 22:50:17 7568 [Note] Server hostname (bind-address): '*'; port: 3306
2016-08-04 22:50:17 7568 [Note] IPv6 is available.
2016-08-04 22:50:17 7568 [Note] - '::' resolves to '::';
2016-08-04 22:50:17 7568 [Note] Server socket created on IP: '::'.
2016-08-04 22:50:17 7568 [Warning] 'proxies_priv' entry '@ root@hongquan.mysql2' ignored in --skip-name-resolve mode.
2016-08-04 22:50:17 7568 [ERROR] InnoDB: Failed to find tablespace for table '"mysql"."slave_master_info"' in the cache. Attempting to load the tablespace with space id 8.
2016-08-04 22:50:17 7568 [Warning] InnoDB: Allocated tablespace 8, old maximum was 0
2016-08-04 22:50:17 7568 [ERROR] InnoDB: Failed to find tablespace for table '"mysql"."slave_worker_info"' in the cache. Attempting to load the tablespace with space id 10.
2016-08-04 22:50:17 7568 [ERROR] InnoDB: Failed to find tablespace for table '"mysql"."slave_relay_log_info"' in the cache. Attempting to load the tablespace with space id 9.
2016-08-04 22:50:18 7568 [Note] Event Scheduler: Loaded 0 events
2016-08-04 22:50:18 7568 [Note] /usr/local/mysql/bin/mysqld: ready for connections.

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (7f61cc005000): SELECT /*!40001 SQL_NO_CACHE */ * FROM `sbtest1`
Connection ID (thread ID): 1
Status: NOT_KILLED
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

[ERROR] InnoDB: Failed to find tablespace for table '"sbtest"."sbtest1"' in the cache. Attempting to load the tablespace with space id 27.

ERROR 1010 (HY000): Error dropping database (can't rmdir './sbtest', errno: 39)

Solution :
a. Stopped the mysql service
b. remove the mysql database folder in data directory
c. restart the mysqld service
Note : innodb_file_per_table would help to create each table entry has separate innodb file and this may very useful if the table may have GB of data.
---
[root@hongquan 3306]# tail -f -n 200 slow_query.log
/usr/local/mysql/bin/mysqld, Version: 5.6.13-log (hq for mysql). started with:
Tcp port: 3306 Unix socket: /data/mysqldata/3306/mysql.sock

-----------mysql 5.7
1 認證插件
mysql.user表中的plugin更改爲not null，5.7開始再也不支持mysql_old_password的認證插件，推薦所有使用mysql_native_password。從低版本升級到5.7的時候，須要處理兩個兼容性問題
[兼容性]
須要先遷移mysql_old_password的用戶，而後進行user表結構的升級
1. 遷移mysql_old_password用戶
MySQL 5.7.2以前的版本，是根據password的hash value來判斷使用的認證插件類型，5.7.2之後的版本，plugin字段爲not null，就直接根據plugin來判斷了。新的密碼從password字段中，保存到新的字段authentication_string中，password字段廢棄處理
若是user是隱式的mysql_native_password。直接使用sql進行變動：
UPDATE mysql.user SET plugin = 'mysql_native_password' WHERE plugin = '' AND (Password = '' OR LENGTH(Password) = 41);
FLUSH PRIVILEGES;
若是user是隱式的或者顯示的mysql_old_password，首先經過如下sql進行查詢
SELECT User, Host, Password FROM mysql.user WHERE (plugin = '' AND LENGTH(Password) = 16) OR plugin = 'mysql_old_password';
若是存在記錄，就表示還有使用mysql_old_password的user，使用如下sql進行用戶的遷移
ALTER USER 'user1'@'localhost' IDENTIFIED WITH mysql_native_password BY 'DBA-chosen-password';
user表結構升級
經過mysql_upgrade直接進行升級，步驟以下[5.6->5.7]：
stop MySQL 5.6實例
替換5.7的mysqld二進制版本
使用5.7啓動實例
run mysql_upgrade升級系統表
重啓MySQL 5.7實例

2 密碼過時
用戶能夠經過 ALTER USER 'jeffrey'@'localhost' PASSWORD EXPIRE;這樣的語句來使用戶的密碼過時。
並新增長 default_password_lifetime來表示用戶密碼自動過時時間，從5.7.10開始，其默認值從0變動到了360，也就是默認一年過時
能夠經過如下兩種方法禁止過時：
SET GLOBAL default_password_lifetime = 0;
ALTER USER 'jeffrey'@'localhost' PASSWORD EXPIRE NEVER;
[兼容性]
只須要經過mysql_upgrade升級mysql.user系統表就可使用密碼過時新功能
(system@127.0.0.1:3306) [(none)]> show variables like '%password%';

3 帳號鎖定
用戶能夠經過如下語法進行帳號鎖定，阻止這個用戶進行登陸：
ALTER USER 'jeffrey'@'localhost' ACCOUNT LOCK;
ALTER USER 'jeffrey'@'localhost' ACCOUNT UNLOCK;

4 SSL鏈接
若是mysqld編譯使用的openssl，在啓動的時候，默認建立SSL， RSA certificate 和 key 文件。
但無論是openssl仍是yassl，若是沒有設置ssl相關的參數，mysqld都會在data directory裏查找ssl認證文件，來儘可能打開ssl特性。
(system@127.0.0.1:3306) [(none)]> show global variables like '%ssl%';

5 安裝數據庫
5.7開始建議用戶使用 mysqld --initialize來初始化數據庫，放棄以前的mysql_install_db的方式，新的方式只建立了一個root@localhost的用戶，
隨機密碼保存在~/.mysql_secret文件中，而且帳號是expired，第一次使用必須reset password，而且再也不建立test db。

8 InnoDB加強
變動varchar 類型字段的長度支持inplace方法，但有一個限制，即用於表示varchar字段長度的字節數不能發生變化，也就是支持好比varchar的
長度在255如下變動或者255以上的範圍進行變動，由於從小於255變動到大於255，其size的字節須要從1個增長到2個。

注意：減小varchar的長度，仍然須要table copy

9 優化InnoDB臨時表
由於InnoDB臨時表的數據再也不不受redo保護，而redo只保護臨時表的元數據，因此大幅提高了臨時表的性能。
而且InnoDB臨時表的元數據保存在一個新的系統表中即innodb_temp_table_info，
臨時表將創建一個統一的表空間，咱們稱之爲臨時表空間，其目錄地址能夠經過參數innodb_temp_data_file_path來設置。系統在啓動的時候，都會新建這個表空間，重啓會刪除重建。
(system@127.0.0.1:3306) [(none)]> show global variables like '%temp%';
+----------------------------+-----------------------+
| Variable_name | Value |
+----------------------------+-----------------------+
| avoid_temporal_upgrade | OFF |
| innodb_temp_data_file_path | ibtmp1:12M:autoextend |
| show_old_temporals | OFF |
+----------------------------+-----------------------+
(system@127.0.0.1:3306) [(none)]> show global variables like '%storage_engine%';
注意：在開啓gtid的狀況下，非auto commit或者顯示begin的context下，create 或者drop 臨時表，仍然和5.6同樣
ERROR 1787 (HY000): Statement violates GTID consistency: CREATE TEMPORARY TABLE and DROP TEMPORARY TABLE can only be executed outside transactional context.
另外， insert into t select * from t也會遇到錯誤，不能在一個sql語句中reference兩次臨時表
在5.7中，咱們將臨時表從數據字典中分離出來，這樣，臨時表就不會跟其餘正常表爭搶數據字典的鎖。同時，咱們還將臨時表的表空間跟普通表空間區別開來，以減小IO的開銷
對於臨時表的DML操做，咱們只記錄Undo日誌，不記錄Redo日誌，由於，臨時表不須要在Crash的時候Recovery，可是它須要rollback。這樣也減小了大量的日誌開銷

10 InnoDB原生支持DATA_GEOMETRY類型
而且支持在spatial data types上創建index，加速查詢
CREATE TABLE triangle (sidea int, sideb int, area DOUBLE AS (sidea * sideb / 2),sumab int as (sidea + sideb));
insert into triangle(sidea, sideb) values(3, 4);
select * from triangle;

11 buffer pool dump
buffer pool dump和load支持一個新的參數innodb_buffer_pool_dump_pct，即dump的比例，而且使用innodb_io_capacity 來控制load過程當中的IO吞吐量

12 多線程flush dirty
從5.7.4開始，innodb_page_cleaners參數能夠設置，支持多線程flush dirty page，加快髒塊的刷新
innodb-page-cleaners = 8
performance-schema = OFF

13 NVM file system
MySQL 一直使用double write buffer來解決一個page寫入的partial write問題，但在linux系統上的Fusion-io Non-Volatile Memory (NVM) file system支持原子的寫入。
這樣就能夠省略掉double write buffer的使用， 5.7.4之後，若是Fusion-io devices支持atomic write，那麼MySQL自動把dirty block直接寫入到數據文件了。這樣減小了一次內存copy和IO操做。

14 InnoDB分區表
MySQL 5.7以前的版本，InnoDB並不支持分區表，分區表的支持是在ha_partition引擎上支持的，從5.7開始，InnoDB支持原生的分區表，而且可使用傳輸表空間
[兼容性]
mysql_upgrade會掃描ha_partition引擎支持的InnoDB表，並升級成InnoDB分區表，5.7.9以後，能夠經過命令ALTER TABLE … UPGRADE PARTITIONING.進行升級。
若是以前的版本大量使用了分區表，要注意使用mysql_upgrade會消耗很是長的時間來升級分區表

15 動態調整buffer pool size
MySQL 5.7.5以後，能夠online動態調整buffer pool size，經過設置動態的參數innodb_buffer_pool_size來調整，而且根據Innodb_buffer_pool_resize_status狀態來
查看resize的進度，由於resize的過程是以chunk爲大小，把pages從一個內存區域copy到另外一片內存的
innodb_buffer_pool_size can be configured dynamically, while the server is running.

16 加快recovery
MySQL 5.7.5以前，在recovery的過程當中，須要掃描全部的ibd文件，獲取元信息， 5.7.5以後，新加了一種redo log類型，即MLOG_FILE_NAME，
記錄從上一次checkpoint以來，發生過變動的文件，這樣在recovery的過程當中，只須要打開這些文件就能夠了。
[兼容性]
由於增長了新的log record type，須要安全的關閉5.7以前的實例，清理掉redo。

17 表空間管理
支持建立表空間，例如
CREATE TABLESPACE `tablespace_name`
ADD DATAFILE 'file_name.ibd'
[FILE_BLOCK_SIZE = n]
並能夠在建立表的時候，指定屬於哪一個表空間，
[兼容性]
由於能夠任意指定空間目錄，要注意升級過程當中，不要漏掉目錄。

18 InnoDB Tablespace Encryption
支持InnoDB數據文件加密，其依賴keyring plugin來進行祕鑰的管理，後面咱們單獨來介紹InnoDB加密的方法，而且RDS也實現了一種InnoDB數據文件透明加密方法，並經過KMS系統來管理祕鑰。例如：
create table t(id int) encryption='y';
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE 'keyring%';

19 事務相關優化
對InnoDB的事務（transaction）進行了優化，建立事務池（Transaction Pool），這樣就能減小不少事務建立和釋放的開銷
優化了事務的生命週期管理。全部事務首先都默認爲是隻讀事務，這樣這些事務就不會和其餘事務衝突，只有當此事務開始一個寫操做時才認爲它是一個讀寫事務：

20 支持更大的數據頁
以前咱們支持的是4k，8k，16k，如今能夠支持32k，64k了。這樣一些blob數據就能夠直接存在頁裏，訪問起來更快

21 GIS的支持
在5.7中最重要的新功能是對GIS的支持。咱們在InnoDB內部實現了基於R-tree的空間索引，這樣用戶就能很方便的查找地理信息數據了
好比，查找以我爲中心，周圍2千米範圍內的妹子之類的操做將變得異常迅速，

explicit_defaults_for_timestamp=1 default off
默認關閉，容許服務器使用非標準的TIMESTAMP columns
malloc-lib=tcmalloc
--malloc-lib Alternative malloc library to use for mysqld
If the option is given as --malloc-lib=tcmalloc, mysqld_safe looks for a tcmalloc library
in /usr/lib and then in the MySQL pkglibdir location (for example, /usr/local/mysql/
lib or whatever is appropriate). If tmalloc is found, its path name is added to the beginning of
the LD_PRELOAD value for mysqld. If tcmalloc is not found, mysqld_safe aborts with an error.

If the option is given as --malloc-lib=/path/to/some/library, that full path is added to
the beginning of the LD_PRELOAD value. If the full path points to a nonexistent or unreadable file,
mysqld_safe aborts with an error.

loose_innodb_numa_interleave = 1
MySQL 5.7 InnoDB提供了新的參數innodb_numa_interleave，即緩衝池內存的分配策略採用interleave的方式

innodb_numa_interleave 5.6.27
Default Value OFF
Enables the NUMA interleave memory policy for allocation of the InnoDB buffer pool. When
innodb_numa_interleave is enabled, the NUMA memory policy is set to MPOL_INTERLEAVE for
the mysqld process. After the InnoDB buffer pool is allocated, the NUMA memory policy is set back to
MPOL_DEFAULT. For the innodb_numa_interleave option to be available, MySQL must be compiled
on a NUMA-enabled Linux system.

binlog_gtid_simple_recovery
5.7.6如下中默認
simplified_binlog_gtid_recovery=flase
可是這會致使過多的BINLOG掃描，何況5.6沒有mysql.gtid_executed的支持，從庫必須開啓log_slave_updates，這會帶來性能影響。因此仍是少用GTID。
5.7.6以上中默認
binlog_gtid_simple_recovery=true
5.7.6以上因爲對每一個BINLOG都有Previous gtid Event的支持binlog_gtid_simple_recovery=true是合理的設置，BINLOG掃描很是的快由於只是第一個和最後一個BINLOG文件而已。
能夠看到Gtid也愈來愈成熟了。
(system@127.0.0.1:3306) [test]> show variables like '%gtid%';
+----------------------------------+-------------------------------------------------+
| Variable_name | Value |
+----------------------------------+-------------------------------------------------+
| binlog_gtid_simple_recovery | ON |
| enforce_gtid_consistency | ON |
| gtid_executed_compression_period | 1000 |
| gtid_mode | ON |
| gtid_next | AUTOMATIC |
| gtid_owned | |
| gtid_purged | 3d8c27f0-ff21-11e7-9564-0800279374ba:1-15862163 |
| session_track_gtids | OFF |
+----------------------------------+-------------------------------------------------+

show_compatibility_56 = on
--從mysql5.7.6開始information_schema.global_status已經開始被捨棄，爲了兼容性，此時須要打開 show_compatibility_56
(system@127.0.0.1:3306) [test]> select * from information_schema.global_status limit 3;
ERROR 3167 (HY000): The 'INFORMATION_SCHEMA.GLOBAL_STATUS' feature is disabled; see the documentation for 'show_compatibility_56'
(system@127.0.0.1:3306) [test]> show variables like '%show_compatibility_56%';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| show_compatibility_56 | OFF |
--把show_compatibility_56打開
mysql> set global show_compatibility_56=on;

validate_password=OFF 5.7 中可關閉密碼檢測插件
# password plugin #
validate_password_policy = STRONG
validate-password = FORCE_PLUS_PERMANENT

validate_password_policy=默認是1 ：符合長度，且必須含有數字，小寫或大寫字母，特殊字符
0 or LOW
Length
1 or MEDIUM
Length; numeric, lowercase/uppercase, and special characters
2 or STRONG
Length; numeric, lowercase/uppercase, and special characters; dictionary file

安裝validate_password插件：
install plugin valaidte_password soname 'validate_password.so';

log_error_verbosity = 2
Default Value 3
Desired Log Filtering log_error_verbosity Value
Error messages 1
Error and warning messages 2
Error, warning, and note messages 3

min_examined_row_limit 查詢檢查返回少於該參數指定行的SQL不被記錄到慢查詢日誌

--
slave_skip_errors
--slave-skip-errors=[err_code1,err_code2,...|all|ddl_exist_errors]
System Variable slave_skip_errors
Dynamic No
Default Value OFF
Valid Values OFF [list of error codes] all /ddl_exist_errors
The shorthand value ddl_exist_errors is equivalent to the error code list 1007,1008,1050,1051,1054,1060,1061,1068,1094,1146.
--slave-skip-errors=1062,1053
--slave-skip-errors=all
--slave-skip-errors=ddl_exist_errors
slave-skip-errors=1032

optimizer_search_depth
這個參數控制優化器在窮舉執行計劃時的限度。若是查詢長時間處於"statistics"狀態，能夠考慮調低此參數
optimizer_prune_level
默認是打開的，這讓優化器會根據須要掃描的行數來決定是否跳過某些執行計劃
optimizer_switch
這個變量包含了一些開啓/關閉優化器特性的標誌位
set optimizer_switch='mrr=on,mrr_cost_based=off,batched_key_access=on';
set optimizer_switch='mrr_cost_based=off';

innodb_strict_mode
Default Value (>= 5.7.7) ON

Oracle recommends enabling innodb_strict_mode when specifying KEY_BLOCK_SIZE for
InnoDB tables. When innodb_strict_mode is enabled, specifying an invalid KEY_BLOCK_SIZE
value returns an error. If innodb_strict_mode is disabled, an invalid KEY_BLOCK_SIZE value
results in a warning, and the KEY_BLOCK_SIZE option is ignored.

innodb_write_io_threads = 16
innodb_read_io_threads = 16 The number of I/O threads for read operations in InnoDB.
Default Value 4

event_scheduler 事件是否開啓
event_scheduler = 1

(system@127.0.0.1:3306) [trunk]> show variables like '%performance_sch%';
+----------------------------------------------------------+-------+
| Variable_name | Value |
+----------------------------------------------------------+-------+
| performance_schema | ON |
(system@127.0.0.1:3306) [trunk]> show variables like '%instance%';
+------------------------------------------------------+-------+
| Variable_name | Value |
+------------------------------------------------------+-------+
| innodb_buffer_pool_instances | 2 |
| metadata_locks_hash_instances | 8 |
| table_open_cache_instances | 16 |
table_open_cache_instances 指的是 MySQL 緩存 table 句柄的分區的個數，而每個 cache_instance 能夠包含不超過table_open_cache/table_open_cache_instances 的table_cache_element
MySQL 打開表的過程能夠簡單的歸納爲：
1根據線程的 thread_id 肯定線程將要使用的 table_cache，即 thread_id % table_cache_instances;
2從該 tabel_cache 元素中查找相關係連的 table_cache_element，若是存在轉 3，若是不存在轉 4；
3從 2 中查找的table_cache_element 的 free_tables 中出取一個並返回，並調整 table_cache_element 中的 free_tables & used_tables 元素；
4若是 2 中不存在，則從新建立一個 table, 並加入對應的 table_cache_element 的 used_tables的列表；

從以上過程能夠看出，MySQL 在打開表的過程當中會首先從 table_cache 中進行查找有沒有能夠直接使用的表句柄，有則直接使用
沒有則會建立並加入到對應的 table_cache 中對應的 table_cache_element 中

performance schema 是 MySQL 的內部診斷器，用於記錄 MySQL 在運行期間的各類信息，如表鎖狀況、mutex 竟爭狀況、執行語句的狀況等，和
Information Schema 相似的是擁用的信息都是內存信息，而不是存在磁盤上的，但和 information_schema 有如下不一樣點：
information_schema 中的信息都是從 MySQL 的內存對象中讀出來的，只有在須要的時候纔會讀取這些信息，如 processlist, profile, innodb_trx 等，
不須要額外的存儲或者函數調用，而 performance schema 則是經過一系列的回調函數來將這些信息額外的存儲起來，
使用的時候進行顯示，所以 performance schema 消耗更多的 CPU & memory 資源；
Information_schema 中的表是沒有表定義文件的，表結構是在內存中寫死的，而 performation_schema 中的表是有表定義文件的；
實現方式不一樣，Information_schema 只是對內存的 traverse copy, 而 performance_schema 則使用固定的接口來進行實現；
做用不一樣，Information_schema 主要是輕量級的使用，即便在使用的時候也不多會有性能影響，performance_schema 則是 MySQL 的內部監控系統，能夠很好的定位性能問題，但也很影響性能；
table_open_cache_instances=32
metadata_locks_hash_instances=32
performance_schema=OFF
innodb_purge_threads=4
(system@127.0.0.1:3306) [trunk]> show variables like '%spin%';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| innodb_spin_wait_delay | 6 |
| innodb_sync_spin_loops | 30 |

--character-set-server=charset_name, -C charset_name
Default Value latin1 #5.6,5.7
[mysqld]
character-set-server=utf8
collation-server=utf8_general_ci
----
[client]
default-character-set = utf8mb4

[mysql]
default-character-set = utf8mb4

[mysqld]
character-set-client-handshake = FALSE
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
init_connect='SET NAMES utf8mb4'

innodb_buffer_pool_load_at_startup
Default Value (>= 5.7.7) ON
Default Value (<= 5.7.6)
Specifies that, on MySQL server startup, the InnoDB buffer pool is automatically warmed
up by loading the same pages it held at an earlier time. Typically used in combination with
innodb_buffer_pool_dump_at_shutdown

Both innodb_buffer_pool_dump_at_shutdown and
innodb_buffer_pool_load_at_startup are enabled by default

innodb_monitor_enable
SHOW ENGINE PERFORMANCE_SCHEMA STATUS\G
This statement is intended to help the DBA understand the effects that different Performance Schema
options have on memory requirements

table_cache_size 打開表的線程數量
myisam_max_sort_file_size
The maximum size of the temporary file that MySQL is permitted to use while re-creating a MyISAM
index (during REPAIR TABLE, ALTER TABLE, or LOAD DATA INFILE).
-----------mysql 5.6
Table 5.1 Changes to Server Defaults in MySQL 5.6
Parameter Old Default New Default Version
back_log 50 Autosized using max_connections 5.6.6
binlog_checksum NONE CRC32 5.6.6
--binlog-row-event-max-size 1024 8192 5.6.6
flush_time 1800 (on Windows) 0 5.6.6
host_cache_size 128 Autosized using max_connections 5.6.8
innodb_autoextend_increment 8 64 5.6.6
innodb_buffer_pool_instances 1 8 (platform dependent) 5.6.6
innodb_concurrency_tickets 500 5000 5.6.6
innodb_data_file_path ibdata1:10M:autoextend ibdata1:12M:autoextend 5.6.7
innodb_file_per_table 0 1 5.6.6
innodb_log_file_size 5MB 48MB 5.6.8
innodb_old_blocks_time 0 1000 5.6.6
innodb_open_files 300 Autosized using innodb_file_per_table, table_open_cache 5.6.6
innodb_stats_on_metadata ON OFF 5.6.6
join_buffer_size 128KB 256KB 5.6.6
max_allowed_packet 1MB 4MB 5.6.6
max_connect_errors 10 100 5.6.6
open_files_limit 0 Autosized using max_connections 5.6.8
performance_schema OFF ON 5.6.6
performance_schema_events_waits_history_long_size 10000 Autosized 5.6.6
performance_schema_events_waits_history_size 10 Autosized 5.6.6
performance_schema_max_cond_instances 1000 Autosized 5.6.6
performance_schema_max_file_instances 10000 Autosized 5.6.6
performance_schema_max_mutex_instances 1000000 Autosized 5.6.6
performance_schema_max_rwlock_instances 1000000 Autosized 5.6.6
performance_schema_max_table_handles 100000 Autosized 5.6.6
performance_schema_max_table_instances 50000 Autosized 5.6.6
performance_schema_max_thread_instances 1000 Autosized 5.6.6
query_cache_size 0 1M 5.6.8
query_cache_type ON OFF 5.6.8
secure_auth OFF ON 5.6.7
sql_mode '' (empty string) NO_ENGINE_SUBSTITUTION 5.6.6
sync_master_info 0 10000 5.6.6
sync_relay_log 0 10000 5.6.6
sync_relay_log_info 0 10000 5.6.6
table_definition_cache 400 Autosized using table_open_cache 5.6.8
table_open_cache 400 2000 5.6.8
thread_cache_size 0 Autosized using max_connections 5.6.8

--5.6 time_zone
the initial value of this is 'SYSTEM' (which means, 「use the value of system_time_zone」)
time_zone默認是system，則用的值就是system_time_zone的值

This variable is used to initialize the time zone for each client that connects.
default 'SYSTEM'
If set to SYSTEM, every MySQL function call that requires a timezone calculation
makes a system library call to determine the current system timezone. This call
may be protected by a global mutex, resulting in contention.
--set global time_zone = '+8:00';
(system@127.0.0.1:3306) [(none)]> set time_zone='+8:00';
Query OK, 0 rows affected (0.00 sec)

(system@127.0.0.1:3306) [(none)]> show variables like '%time_zone%';
+------------------+--------+
| Variable_name | Value |
+------------------+--------+
| system_time_zone | CST |
| time_zone | +08:00 |
+------------------+--------+
(system@127.0.0.1:3306) [(none)]> select now(),CURRENT_TIMESTAMP;
+---------------------+---------------------+
| now() | CURRENT_TIMESTAMP |
+---------------------+---------------------+
| 2018-11-23 14:45:40 | 2018-11-23 14:45:40 |
+---------------------+---------------------+
(system@127.0.0.1:3306) [(none)]> set time_zone='+0:00';
+---------------------+---------------------+
(system@127.0.0.1:3306) [(none)]> select now(),CURRENT_TIMESTAMP;
+---------------------+---------------------+
| now() | CURRENT_TIMESTAMP |
+---------------------+---------------------+
| 2018-11-23 06:46:24 | 2018-11-23 06:46:24 |
+---------------------+---------------------+
發起死鎖檢測，主動回滾死鎖鏈條中的某一個事務，能夠禁用死鎖檢測，在高併發系統能夠提高必定的性能
innodb_deadlock_detect（default=on）（5.7.15以後的參數）
This option is used to disable deadlock detection. On high concurrency systems, deadlock detection
can cause a slowdown when numerous threads wait for the same lock. At times, it may be more
efficient to disable deadlock detection and rely on the innodb_lock_wait_timeout setting for
transaction rollback when a deadlock occurs.

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。