知識點：Mysql 索引原理徹底手冊(1)
知識點：Mysql 索引原理徹底手冊(2)
知識點：Mysql 索引優化實戰(3)
知識點：Mysql 數據庫索引優化實戰(4)
8、 聯合索引與覆蓋索引
一 、聯合索引
聯合索引時指對錶上的多個列合起來作一個索引。聯合索引的建立方法與單個索引的建立方法同樣，不一樣之處在僅在於有多個索引列，以下html
mysql> create table t( -> a int, -> b int, -> primary key(a), -> key idx_a_b(a,b) -> ); Query OK, 0 rows affected (0.11 sec)
那麼什麼時候須要使用聯合索引呢？mysql
從本質上來講，聯合索引就是一棵B+樹，不一樣的是聯合索引的鍵值得數量不是1，而是>=2。sql
接着來討論兩個整型列組成的聯合索引，假定兩個鍵值得名稱分別爲a、b如圖 
數據庫
能夠看到這與咱們以前看到的單個鍵的B+樹並無什麼不一樣，鍵值都是排序的，經過葉子結點能夠邏輯上順序地讀出全部數據，就上面的例子來講，即（1,1），（1,2），（2,1），（2,4），（3,1），（3,2），數據按（a,b）的順序進行了存放。 所以，對於查詢select * from table where a=xxx and b=xxx, 顯然是可使用(a,b) 這個聯合索引的，對於單個列a的查詢select * from table where a=xxx,也是可使用（a,b）這個索引的。vim
但對於b列的查詢select * from table where b=xxx,則不可使用（a,b） 索引，其實你不難發現緣由，葉子節點上b的值爲一、二、一、四、一、2顯然不是排序的，所以對於b列的查詢使用不到(a,b) 索引緩存
聯合索引的第二個好處是在第一個鍵相同的狀況下，已經對第二個鍵進行了排序處理服務器
例如在不少狀況下應用程序都須要查詢某個用戶的購物狀況，並按照時間進行排序，最後取出最近三次的購買記錄，這時使用聯合索引能夠幫咱們避免多一次的排序操做，由於索引自己在葉子節點已經排序了，以下測試
#===========數據表============== create table base_purchate_log( userid int unsigned not null, buy_date date ); insert into base_purchate_log values (1,'2009-01-01'), (2,'2009-01-01'), (3,'2009-01-01'), (1,'2009-02-01'), (3,'2009-02-01'), (1,'2009-03-01'), (1,'2009-04-01'); alter table base_purchate_log add key(userid); alter table base_purchate_log add key(userid,buy_date); #===========數據表驗證============== mysql> show create table base_purchate_log; | base_purchate_log | CREATE TABLE `base_purchate_log` ( `userid` int(10) unsigned NOT NULL, `buy_date` date DEFAULT NULL, KEY `userid` (`userid`), KEY `userid_2` (`userid`,`buy_date`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 | #能夠看到possible_keys在這裏有兩個索引能夠用，分別是單個索引userid與聯合索引userid_2, 可是優化器最終選擇了使用的key是userid由於該索引的葉子節點包含單個鍵值，因此理論上一個頁能存放的記錄應該更多 mysql> explain select * from base_purchate_log where userid=2; +----+-------------+---------+------+-----------------+--------+---------+-------+------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+---------+------+-----------------+--------+---------+-------+------+-------+ | 1 | SIMPLE | base_purchate_log | ref | userid,userid_2 | userid | 4 | const | 1 | | +----+-------------+---------+------+-----------------+--------+---------+-------+------+-------+ 1 row in set (0.00 sec) #接着假定要取出userid爲1的最近3次的購買記錄，用的就是聯合索引userid_2了，由於在這個索引中，在userid=1的狀況下，buy_date都已經排序好了 mysql> explain select * from base_purchate_log where userid=1 order by buy_date desc limit 3; +----+-------------+---------+------+-----------------+----------+---------+-------+------+--------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+---------+------+-----------------+----------+---------+-------+------+--------------------------+ | 1 | SIMPLE | base_purchate_log | ref | userid,userid_2 | userid_2 | 4 | const | 4 | Using where; Using index | +----+-------------+---------+------+-----------------+----------+---------+-------+------+--------------------------+ 1 row in set (0.00 sec) #ps：若是extra的排序顯示是Using filesort，則意味着在查出數據後須要二次排序 #對於聯合索引（a,b）,下述語句能夠直接使用該索引，無需二次排序 select ... from table where a=xxx order by b; #而後對於聯合索引(a,b,c)來首，下列語句一樣能夠直接經過索引獲得結果 select ... from table where a=xxx order by b; select ... from table where a=xxx and b=xxx order by c; #可是對於聯合索引(a,b,c)，下列語句不能經過索引直接獲得結果，還須要本身執行一次filesort操做，由於索引（a，c)並未排序 select ... from table where a=xxx order by c;
2、 覆蓋索引優化
InnoDB存儲引擎支持覆蓋索引（covering index，或稱索引覆蓋），即從輔助索引中就能夠獲得查詢記錄，而不須要查詢彙集索引中的記錄。url
使用覆蓋索引的一個好處是：輔助索引不包含整行記錄的全部信息，故其大小要遠小於彙集索引，所以能夠減小大量的IO操做
注意：覆蓋索引技術最先是在InnoDB Plugin中完成並實現，這意味着對於InnoDB版本小於1.0的，或者MySQL數據庫版本爲5.0如下的，InnoDB存儲引擎不支持覆蓋索引特性
對於InnoDB存儲引擎的輔助索引而言，因爲其包含了主鍵信息，所以其葉子節點存放的數據爲（primary key1，priamey key2，...,key1，key2，...）。例如
select age from s1 where id=123 and name = 'duoduo'; #id字段有索引，可是name字段沒有索引,該sql命中了索引，但未覆蓋，須要去彙集索引中再查找詳細信息。 最牛逼的狀況是，索引字段覆蓋了全部，那全程經過索引來加速查詢以及獲取結果就ok了 mysql> desc s1; +--------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +--------+-------------+------+-----+---------+-------+ | id | int(11) | NO | | NULL | | | name | varchar(20) | YES | | NULL | | | gender | char(6) | YES | | NULL | | | email | varchar(50) | YES | | NULL | | +--------+-------------+------+-----+---------+-------+ 4 rows in set (0.21 sec) mysql> explain select name from s1 where id=1000; #沒有任何索引 +----+-------------+-------+------------+------+---------------+------+---------+------+---------+----------+-------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-------+------------+------+---------------+------+---------+------+---------+----------+-------------+ | 1 | SIMPLE | s1 | NULL | ALL | NULL | NULL | NULL | NULL | 2688336 | 10.00 | Using where | +----+-------------+-------+------------+------+---------------+------+---------+------+---------+----------+-------------+ 1 row in set, 1 warning (0.00 sec) mysql> create index idx_id on s1(id); #建立索引 Query OK, 0 rows affected (4.16 sec) Records: 0 Duplicates: 0 Warnings: 0 mysql> explain select name from s1 where id=1000; #命中輔助索引，可是未覆蓋索引，還須要從彙集索引中查找name +----+-------------+-------+------------+------+---------------+--------+---------+-------+------+----------+-------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-------+------------+------+---------------+--------+---------+-------+------+----------+-------+ | 1 | SIMPLE | s1 | NULL | ref | idx_id | idx_id | 4 | const | 1 | 100.00 | NULL | +----+-------------+-------+------------+------+---------------+--------+---------+-------+------+----------+-------+ 1 row in set, 1 warning (0.08 sec) mysql> explain select id from s1 where id=1000; #在輔助索引中就找到了所有信息，Using index表明覆蓋索引 +----+-------------+-------+------------+------+---------------+--------+---------+-------+------+----------+-------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-------+------------+------+---------------+--------+---------+-------+------+----------+-------------+ | 1 | SIMPLE | s1 | NULL | ref | idx_id | idx_id | 4 | const | 1 | 100.00 | Using index | +----+-------------+-------+------------+------+---------------+--------+---------+-------+------+----------+-------------+ 1 row in set, 1 warning (0.03 sec)
覆蓋索引的另一個好處是對某些統計問題而言的。base_purchate_log,查詢計劃以下
mysql> explain select count(*) from base_purchate_log; +----+-------------+---------+-------+---------------+--------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+---------+-------+---------------+--------+---------+------+------+-------------+
| 1 | SIMPLE | base_purchate_log | index | NULL | userid | 4 | NULL | 7 | Using index |
+----+-------------+---------+-------+---------------+--------+---------+------+------+-------------+
1 row in set (0.00 sec)
innodb存儲引擎並不會選擇經過查詢彙集索引來進行統計。base_purchate_log，而輔助索引遠小於彙集索引，選擇輔助索引能夠減小IO操做，故優化器的選擇如上key爲userid輔助索引
對於（a,b）形式的聯合索引，通常是不能夠選擇b中所謂的查詢條件。但若是是統計操做，而且是覆蓋索引，則優化器仍是會選擇使用該索引，以下
#聯合索引userid_2（userid,buy_date）,通常狀況，咱們按照buy_date是沒法使用該索引的，但特殊狀況下： 查詢語句是統計操做，且是覆蓋索引，則按照buy_date當作查詢條件時，也可使用該聯合索引 mysql> explain select count(*) from base_purchate_log where buy_date >= '2011-01-01' and buy_date < '2011-02-01'; +----+-------------+---------+-------+---------------+----------+---------+------+------+--------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+---------+-------+---------------+----------+---------+------+------+--------------------------+ | 1 | SIMPLE | base_purchate_log | index | NULL | userid_2 | 8 | NULL | 7 | Using where; Using index | +----+-------------+---------+-------+---------------+----------+---------+------+------+--------------------------+ 1 row in set (0.00 sec)
9、查詢優化神器-explain
強調rows是核心指標，絕大部分rows小的語句執行必定很快（有例外，下面會講到）。因此優化語句基本上都是在優化rows。
參考官網explain-output
執行計劃：讓mysql預估執行操做(通常正確) all < index < range < index_merge < ref_or_null < ref < eq_ref < system/const id,email 慢： select * from userinfo3 where name='alex' explain select * from userinfo3 where name='alex' type: ALL(全表掃描) select * from userinfo3 limit 1; 快： select * from userinfo3 where email='alex' type: const(走索引)
重寫非SELECT查詢
mysql explain只能解釋select查詢，並不會對存儲程序調用和insert、update、delete或其餘語句作解釋。
若是重寫某些非select查詢以利用explain，只須要將該語句轉化成一個等價的訪問全部相同列的select，任何體積的列都必須在select列表，關聯子句，或者where子句中。
假如重寫update語句使其能夠利用explain
# update語句 UPDATE test.actor INNER JOIN test.film_actor USING (actor_id) SET actor.last_update=film_actor.last_update; # 這條explain 語句並不等於上面的update，由於它並不要求服務器從任何一個表上獲取last_update列 explain select film_actor.actor_id from test.actor inner join test.film_actor USING(actor_id)\G; # 這個差異很是重要。例如，輸出結果顯示mysql將使用覆蓋索引，可是，當檢索更新last_updated列時，就沒法使用覆蓋索引了，下面這種改寫法就更接近原來的語句： explain select film_actor.last_update, actor.last_update from test.actor inner join test.film_actor USING (actor_id)\G;
MySQL 5.6將容許解釋非SELECT查詢，一個SELECT查詢只須要找到數據的一份副本並返回。
而任何修改數據的查詢必須在全部索引上查找並修改其全部副本，這經常比看起來等價的SELECT查詢的消耗要高得多。
EXPLAIN中的列
- 【id列】
這一列老是包含一個編號，識別select所屬的行，若是在語句當中沒有子查詢或聯合，那麼只會有惟一的select，因而每一行在這個列中都將顯示一個1，不然，內層的select語句通常會順序編號，對應於其在原始語句中的位置。
# 簡單的子查詢。子句中的子查詢和聯合給id列增長了更多的複雜性。 explain select (select 1 from test.actor limit 1) from test.film; # from 子句中的基本子查詢。一個匿名的臨時表，mysql內部經過別名（der）在外層查詢中引用這個臨時表，在更復雜的查詢中能夠看到ref列。 explain select film_id from (select film_id from test.film) as der; # union 查詢。union的結果老是放在一個匿名臨時表中，臨時表並不在原SQL中出現，所以它的id列爲null。 explain select 1 union all select 1;
- 【select_type列】
顯示了對應行是簡單仍是複雜的select。simple值意味着查詢不包括子查詢和union，若是查詢有任何負責的子部分，則最外層部分標記爲primary
- 【table列】
對應行正在訪問哪一個表。能夠在這一列中從上往下觀察mysql的關聯優化器爲查詢選擇的關聯順序，mysql的執行計劃老是左側深度優先樹，若是把這個計劃放倒，就能按順序讀出葉子節點，它們直接對應於explain中的行。
explain select film.film_id from test.film inner join test.fillm_actor USING(film_id) inner join test.actor USING(actor_id);
派生表和聯合
mysql建立的匿名臨時表僅在查詢執行過程當中存在.
-
from子句中有子查詢 table列是<derivedN>的形式，其中N是子查詢的id。這老是「向前引用」——換言之，N指向explain輸出中後面的一行。
-
union
union result的table列包含一個參與union的id列表。這老是「向後引用」，由於union result出如今union中全部參與行以後，若是在列表中有超過20個id，table列被截斷以防止太長，此時不可能看到全部的值，可是能夠推測包括哪些行，由於咱們能夠看到第一行的id，在這一行和union result之間出現的一切都會以某種方式被包含。
【type列】
這一列顯示了「關聯類型」，但咱們認爲更準確的說法是訪問類型——即mysql決定如何查找表中的行。
從最差到最優排序：
ALL：index：range：ref：eq_ref：const，system：null
【possible_keys列】
這一列顯示了查詢可使用哪些索引，這是基於查詢訪問的列和使用的比較操做符來判斷的。這個列表是在優化過程的早期建立的，所以有些羅列出來的索引可能對於後續優化過程是沒用的。
【key列】
這一列顯示了mysql決定採用哪一個索引來優化對該表的訪問。
若是該索引沒有出如今possible_keys列中，那麼mysql選用它可能由於其選擇了一個覆蓋索引，哪怕沒有where子句。
換句話說，possible_keys揭示了哪個索引能有助於高效地進行查找，而key顯示的是優化採用哪個索引能夠最小化查詢成本。
示例：
explain select actor_id, film_id from film_actor\G;
【key_len列】
該列顯示了mysql在索引裏使用的字節數
若是mysql正在使用的只是索引裏的某些列，那麼就能夠用這個值來算出具體是哪些列，要記住，mysql 5.5及以前的版本只能使用索引的最左前綴，舉例來講，film_actor的主鍵是兩個smallint列，而且每一個smallint列是兩字節，那麼索引中的每項是4字節
mysql並不老是顯示一個索引真正使用了多少，例如，若是對一個前綴模式匹配執行like查詢，它會顯示列的徹底寬度正在被使用。
key_len列顯示了在索引字段中可能的最大長度，而不是表中數據使用的實際字節數，在前面例子中mysql老是顯示13字節，即便a列恰巧只包含一個字符長度。換言之，key_len經過查找表的定義而被計算出，而不是表中的數據。
【ref列】
這一列顯示了以前的表在key列記錄的索引中查找值所用的列或常量
【rows列】
這一列是mysql爲了找到所需的行而要讀取的行數。
這個數字是內嵌循環關聯計劃裏的循環數目，它不是mysql認爲它最終要從表裏讀取出來的行數，而是mysql爲了找到符合查詢的每一點上標準的那些行而必須讀取的行的平均數。（這個標準包括sql裏給定的條件，以及來自聯接次序上前一個表的當前列。）
根據表的統計信息和索引的選用狀況，這個估算可能很不精確
要記住這個數字是mysql認爲它要檢查的行數，而不是結果集裏的行數，同時也要認識到有不少優化手段，例如關聯緩衝區和緩存，沒法影響到行數的顯示，mysql可能沒必要真的讀全部它估計到的行，它也不知道任何關於操做系統或硬件緩存的信息。
【Extra列】
這一列包含的是不適合在其餘列顯示的額外信息。mysql用戶手冊裏記錄了大多數能夠在這裏出現的值。
常見的最重要的值
Using index，Using where，Using temporary，Using filesort，Range checked for each record(index map: N)
樹形格式的輸出
mysql用戶每每更但願把explain的輸出格式化成一棵樹，更加精確地展現執行計劃。
然而，explain查看執行計劃的方式確實有點笨拙，樹狀結構也不適合表格化的輸出，當extra列裏有大量的值時，缺點更明顯，使用union也是這樣，union跟mysql能作的其餘類型的聯接不太同樣，它不太適合explain。
MySQL 5.6中的改進
- 能對相似update、insert等的查詢進行解釋
儘管能夠將dml語句轉化爲等價的「select」查詢並explain，但結果並不會徹底反映語句是如何執行的，於是這仍然很是有幫助。在開發使用相似Percona Toolkit中的pt-upgrade時曾嘗試使用過那個技術，咱們不止一次發現，在將查詢轉化爲select時，優化器並不能按咱們預期的代碼路徑執行。於是explain一個查詢而不須要轉化爲select，對咱們理解執行過程當中到底發生什麼，是很是有幫助的。
- 對查詢優化和執行引擎的一系列修改
容許匿名的臨時表儘量晚地被具體化，而不老是在優化和執行使用到此臨時表的部分查詢時建立並填充它們，這將容許mysql能夠直接解釋帶子查詢的查詢語句，而不須要先實際地執行子查詢。
- 在服務器中增長優化跟蹤功能的方式改進優化器
這將容許用戶查看優化器坐出的抉擇，以及輸入（例如，索引的基數）和抉擇的緣由。這對理解服務器選擇的執行計劃，爲何選擇這個計劃很是有幫助。
十 、慢查詢優化的基本步驟
- 0.先運行看看是否真的很慢，注意設置SQL_NO_CACHE
- 1.where條件單表查，鎖定最小返回記錄表。這句話的意思是把查詢語句的where都應用到表中返回的記錄數最小的表開始查起，單表每一個字段分別查詢，看哪一個字段的區分度最高
- 2.explain查看執行計劃，是否與1預期一致（從鎖定記錄較少的表開始查詢）
- 3.order by limit 形式的sql語句讓排序的表優先查
- 4.瞭解業務方使用場景
- 5.加索引時參照建索引的幾大原則
- 6.觀察結果，不符合預期繼續從0分析
11、 慢日誌管理
慢日誌 - 執行時間 > 10 - 未命中索引 - 日誌文件路徑 配置： - 內存 show variables like '%query%'; show variables like '%queries%'; set global 變量名 = 值 - 配置文件 mysqld --defaults-file='E:\wupeiqi\mysql-5.7.16-winx64\mysql-5.7.16-winx64\my-default.ini' my.conf內容： slow_query_log = ON slow_query_log_file = D:/.... 注意：修改配置文件以後，須要重啓服務
慢日誌的基本操做
MySQL日誌管理
- 錯誤日誌: 記錄 MySQL 服務器啓動、關閉及運行錯誤等信息
- 二進制日誌: 又稱binlog日誌，以二進制文件的方式記錄數據庫中除 SELECT 之外的操做
- 查詢日誌: 記錄查詢的信息
- 慢查詢日誌: 記錄執行時間超過指定時間的操做
- 中繼日誌： 備庫將主庫的二進制日誌複製到本身的中繼日誌中，從而在本地進行重放
- 通用日誌： 審計哪一個帳號、在哪一個時段、作了哪些事件
- 事務日誌或稱redo日誌： 記錄Innodb事務相關的如事務執行時間、檢查點等
1、bin-log 1. 啓用 # vim /etc/my.cnf [mysqld] log-bin[=dir\[filename]] # service mysqld restart 2. 暫停 //僅當前會話 SET SQL_LOG_BIN=0; SET SQL_LOG_BIN=1; 3. 查看 查看所有： # mysqlbinlog mysql.000002 按時間： # mysqlbinlog mysql.000002 --start-datetime="2017-12-05 10:02:56" # mysqlbinlog mysql.000002 --stop-datetime="2017-12-05 11:02:54" # mysqlbinlog mysql.000002 --start-datetime="2017-12-05 10:02:56" --stop-datetime="2017-12-05 11:02:54" 按字節數： # mysqlbinlog mysql.000002 --start-position=260 # mysqlbinlog mysql.000002 --stop-position=260 # mysqlbinlog mysql.000002 --start-position=260 --stop-position=930 4. 截斷bin-log（產生新的bin-log文件） a. 重啓mysql服務器 b. # mysql -uroot -p123 -e 'flush logs' 5. 刪除bin-log文件 # mysql -uroot -p123 -e 'reset master'
2、查詢日誌
啓用通用查詢日誌
# vim /etc/my.cnf [mysqld] log[=dir\[filename]] # service mysqld restart
3、慢查詢日誌
啓用慢查詢日誌
# vim /etc/my.cnf [mysqld] log-slow-queries[=dir\[filename]] long_query_time=n # service mysqld restart MySQL 5.6: slow-query-log=1 slow-query-log-file=slow.log long_query_time=3 查看慢查詢日誌 測試:BENCHMARK(count,expr) SELECT BENCHMARK(50000000,2*3);
4、query_time
- start_time爲slow log中所記錄的屬性
start_time：看字面意思很容易會被誤認爲「sql開始的時間」… 但實際上記錄的是sql結束的時間。
start_time - query_time 即爲sql真正開始的時間。
- lock_time與query_time爲slow log中所記錄的兩個屬性：
- lock_time：waiting for xxx lock的時間
- query_time：real time + lock time的總時間
實際query_time記錄的是lock_time + real time。 query_time ≥ lock_time
tips:有時候一條十分簡單的sql也可能執行很長而被記錄到slow log，那麼可能就須要關注一下lock time是否很大了。
- long_query_time 爲一個MySQL選項參數。
這個參數記錄超過執行時間超過該值以上的SQL。
tips：是按真正執行的時間（real time），不包括等待鎖的時間。
若是long_query_time設置爲1秒 一個insert被lock了10秒，執行只耗了0.5秒，那麼不會被記錄到慢日誌。
5、選項參數
- log_output
枚舉型，動態參數。 用於設置slow log和general log的輸出對象。
能夠設置爲none，table，file，分別表明：不輸出，存於表，存於文件。
而且也能夠組合設置： 好比SET GLOBAL log_output='table,file'; 則表明同時輸出到表和文件中。
若是設置SET GLOBAL log_output='none,file' 或 'none,table' 或 'table,file,none' 均表明'none'
- slow_query_log與slow_query_log_file
slow_query_log 布爾型，動態參數，默認爲OFF。 用於控制是否開啓slow log。
slow_query_log_file 動態參數，指定slow log文件的名稱和路徑。
若未設置，則slow log的文件名取默認值$host_name-slow.log，存放於$datadir下。
- long_query_time
動態參數，默認值爲10。 記錄執行時間（real time）超過該值以上的SQL。
- log_queries_not_using_indexes
布爾型，動態參數，默認爲OFF。
若開啓，則表示記錄全部未使用索引的SQL，不管是否超過long_query_time所設置的值。
不遵循long_query_time。
- log_throttle_queries_not_using_indexes
整型，動態參數，默認爲0。
若是log_queries_not_using_indexes開啓， 那麼log_throttle_queries_not_using_indexes用於限制每分鐘所記錄的slow log數量。
設置爲0則表示「不限制」。
- log_slow_admin_statements
布爾型，動態參數，默認爲OFF。5.7後新增的參數。
可用於控制slow log是否記錄數據庫管理的SQL。
若開啓，則表示記錄這些SQL。
- log_slow_slave_statements
布爾型，動態參數，默認爲OFF。5.7後新增的參數。
開啓後，在slave上將會記錄超過long_query_time的日誌記錄。
即使開啓了這個選項，也不會馬上生效，新的變動須要再一次START SLAVE後生效。
- min_examined_row_limit
整型，動態參數，默認爲0。
設置該值，則表示返回行數大於等於該值的sql，將會被記錄到slow log中。
- log-short-format 默認爲FLASE，該選項僅僅爲啓動時選項，並不支持系統變量。
若是該選項被激活，則表示在slow log中記錄更少的信息。
- log_timestamps
枚舉型，動態，默認爲UTC，5.7.2後出現。
這個參數是用於控制記錄在error log、general log、slow log中，對應日期時區的選項。
【參考文檔】(MySQL 5.7 Reference Manual - 5.1.3 Server Option and Variable Reference)
over