慢查詢日志 slow query log
https://dev.mysql.com/doc/refman/5.7/en/slow-query-log.html
打開慢日志開關
因為開啟慢查詢日志是有代價的（跟 bin log、optimizer-trace 一樣），所以它默 認是關閉的：
show variables like 'slow_query%';
除了這個開關，還有一個參數，控制執行超過多長時間的 SQL 才記錄到慢日志，默 認是 10 秒
show variables like 'long_query_time';
可以直接動態修改參數（重啟后失效）。
set @@global.slow_query_log=1; -- 1 開啟，0 關閉，重啟后失效
set @@global.long_query_time=3; -- mysql 默認的慢查詢時間是 10 秒，另開一個窗口
或者修改配置文件 my.cnf。 以下配置定義了慢查詢日志的開關、慢查詢的時間、日志文件的存放路徑。
slow_query_log = ON
long_query_time=2
slow_query_log_file =/var/lib/mysql/localhost-slow.log
模擬慢查詢：
select sleep(10);
--查詢 user_innodb 表的 500 萬數據（檢查是不是沒有索引）。
SELECT * FROM `user_innodb` where phone = '136';
慢日志分析
日志內容
show global status like 'slow_queries'; -- 查看有多少慢查詢
show variables like '%slow_query%'; -- 獲取慢日志目錄
假設文件在： /var/lib/mysql/ localhost-slow.log
cat /var/lib/mysql/ localhost-slow.log
有了慢查詢日志，怎么去分析統計呢？比如 SQL 語句的出現的慢查詢次數最多，平 均每次執行了多久？
https://dev.mysql.com/doc/refman/5.7/en/mysqldumpslow.html MySQL 提供了 mysqldumpslow 的工具，在 MySQL 的 bin 目錄下
mysqldumpslow --help
例如：查詢用時最多的 20 條慢 SQL：
mysqldumpslow -s t -t 20 -g 'select' /var/lib/mysql/localhost-slow.log
Count 代表這個 SQL 執行了多少次；
Time 代表執行的時間，括號里面是累計時間；
Lock 表示鎖定的時間，括號是累計；
Rows 表示返回的記錄數，括號是累計。
除了慢查詢日志之外，還有一個 SHOW PROFILE 工具可以使用。
SHOW PROFILE
https://dev.mysql.com/doc/refman/5.7/en/show-profile.html
SHOW PROFILE 是谷歌高級架構師 Jeremy Cole 貢獻給 MySQL 社區的，可以查看SQL 語句執行的時候使用的資源，比如 CPU、IO 的消耗情況。
在 SQL 中輸入 help profile 可以得到詳細的幫助信息。
- 查看是否開啟
select @@profiling;
set @@profiling=1;
- 查看 profile 統計
（命令最后帶一個 s）
show profiles;
6.2E-5，小數點左移 5 位，代表 0.000062 秒。
也可以根據 ID 查看執行詳細信息，在后面帶上 for query + ID。
show profile for query 1;
除了慢日志和 show profile，如果要分析出當前數據庫中執行的慢的 SQL，還可以 通過查看運行線程狀態和服務器運行信息、存儲引擎信息來分析。
其他系統命令
- show processlist 運行線程
https://dev.mysql.com/doc/refman/5.7/en/show-processlist.html
show processlist;
這是很重要的一個命令，用于顯示用戶運行線程。可以根據 id 號 kill 線程。 也可以查表，效果一樣：
select * from information_schema.processlist;
- show status 服務器運行狀態
https://dev.mysql.com/doc/refman/5.7/en/show-status.html SHOW STATUS 用于查看 MySQL 服務器運行狀態（重啟后會清空），有 session 和 global 兩種作用域，格式：參數-值。
可以用 like 帶通配符過濾。
SHOW GLOBAL STATUS LIKE 'com_select'; -- 查看 select 次數
- show engine 存儲引擎運行信息
https://dev.mysql.com/doc/refman/5.7/en/show-engine.html show engine 用來顯示存儲引擎的當前運行信息，包括事務持有的表鎖、行鎖信息； 事務的鎖等待情況；線程信號量等待；文件 IO 請求；buffer pool 統計信息。
例如：
show engine innodb status;
如果需要將監控信息輸出到錯誤信息 error log 中（15 秒鐘一次），可以開啟輸出。
show variables like 'innodb_status_output%';
-- 開啟輸出：
SET GLOBAL innodb_status_output=ON;
SET GLOBAL innodb_status_output_locks=ON;
我們現在已經知道了這么多分析服務器狀態、存儲引擎狀態、線程運行信息的命令， 如果讓你去寫一個數據庫監控系統，你會怎么做？
其實很多開源的慢查詢日志監控工具，他們的原理其實也都是讀取的系統的變量和 狀態。
現在我們已經知道哪些 SQL 慢了，為什么慢呢？慢在哪里？
MySQL 提供了一個執行計劃的工具（在架構中我們有講到，優化器最終生成的就是 一個執行計劃），其他數據庫，例如 Oracle 也有類似的功能。
通過 EXPLAIN 我們可以模擬優化器執行 SQL 查詢語句的過程，來知道 MySQL 是 怎么處理一條 SQL 語句的。通過這種方式我們可以分析語句或者表的性能瓶頸。
explain 可以分析 update、delete、insert 么？ MySQL 5.6.3以前只能分析 SELECT; MySQL5.6.3以后就可以分析update、delete、 insert 了。
EXPLAIN 執行計劃
官方鏈接：https://dev.mysql.com/doc/refman/5.7/en/explain-output.html
我們先創建三張表。一張課程表，一張老師表，一張老師聯系方式表（沒有任何索 引）。
DROP TABLE IF EXISTS course;
CREATE TABLE `course` (
`cid` INT(3) DEFAULT NULL,
`cname` VARCHAR(20) DEFAULT NULL,
`tid` INT(3) DEFAULT NULL
) ENGINE = INNODB CHARSET = utf8mb4;
DROP TABLE IF EXISTS teacher;
CREATE TABLE `teacher` (
`tid` INT(3) DEFAULT NULL,
`tname` VARCHAR(20) DEFAULT NULL,
`tcid` INT(3) DEFAULT NULL
) ENGINE = INNODB CHARSET = utf8mb4;
DROP TABLE IF EXISTS teacher_contact;
CREATE TABLE `teacher_contact` (
`tcid` INT(3) DEFAULT NULL,
`phone` VARCHAR(200) DEFAULT NULL
) ENGINE = INNODB CHARSET = utf8mb4;
INSERT INTO `course`
VALUES ('1', 'mysql', '1');
INSERT INTO `course`
VALUES ('2', 'jvm', '1');
INSERT INTO `course`
VALUES ('3', 'juc', '2');
INSERT INTO `course`
VALUES ('4', 'spring', '3');
INSERT INTO `teacher`
VALUES ('1', 'qingshan', '1');
INSERT INTO `teacher`
VALUES ('2', 'jack', '2');
INSERT INTO `teacher`
VALUES ('3', 'mic', '3');
INSERT INTO `teacher_contact`
VALUES ('1', '13688888888');
INSERT INTO `teacher_contact`
VALUES ('2', '18166669999');
INSERT INTO `teacher_contact`
VALUES ('3', '17722225555');
explain 的結果有很多的字段，我們詳細地分析一下。 先確認一下環境：
select version();
show variables like '%engine%';
id
id 是查詢序列編號。
- id 值不同
id 值不同的時候，先查詢 id 值大的（先大后小）。
-- 查詢 mysql 課程的老師手機號
EXPLAIN
SELECT
tc.phone
FROM
teacher_contact tc
WHERE tcid =
(SELECT
tcid
FROM
teacher t
WHERE t.tid =
(SELECT
c.tid
FROM
course c
WHERE c.cname = 'mysql')) ;
先查課程表，再查老師表，最后查老師聯系方式表。子查詢只能以這種方式進行， 只有拿到內層的結果之后才能進行外層的查詢。
- id 值相同
-- 查詢課程 ID 為 2，或者聯系表 ID 為 3 的老師
EXPLAIN
SELECT
t.tname,
c.cname,
tc.phone
FROM
teacher t,
course c,
teacher_contact tc
WHERE t.tid = c.tid
AND t.tcid = tc.tcid
AND (c.cid = 2
OR tc.tcid = 3) ;
id 值相同時，表的查詢順序是
從上往下順序執行。例如這次查詢的 id 都是 1，查詢 的順序是 teacher t（3 條）——course c（4 條）——teacher_contact tc（3 條）。teacher 表插入 3 條數據后：
INSERT INTO `teacher` VALUES (4, 'james', 4) ;
INSERT INTO `teacher` VALUES (5, 'tom', 5);
INSERT INTO `teacher` VALUES (6, 'seven', 6);
-- （備份）恢復語句
DELETE FROM teacher where tid in (4,5,6);
COMMIT;
id 也都是 1，但是從上往下查詢順序變成了：teacher_contact tc（3 條）——teacher t（6 條）——course c（4 條）。
為什么數據量不同的時候順序會發生變化呢？這個是由
笛卡爾積決定的。
舉例：假如有 a、b、c 三張表，分別有 2、3、4 條數據，如果做三張表的聯合查詢， 當查詢順序是 a→b→c 的時候，它的笛卡爾積是：234=64=24。如果查詢順序是 c →b→a，它的笛卡爾積是 432=122=24
因為 MySQL 要把查詢的結果，包括中間結果和最終結果都保存到內存，所以 MySQL 會優先選擇中間結果數據量比較小的順序進行查詢。所以最終聯表查詢的順序是 a→b→ c。這個就是為什么 teacher 表插入數據以后查詢順序會發生變化。
（小標驅動大表的思想）
- 既有相同也有不同
如果 ID 有相同也有不同，就是 ID 不同的先大后小，ID 相同的從上往下。
select type 查詢類型
這里并沒有列舉全部（其它：DEPENDENT UNION、DEPENDENT SUBQUERY、 MATERIALIZED、UNCACHEABLE SUBQUERY、UNCACHEABLE UNION）。 下面列舉了一些常見的查詢類型：
-
SIMPLE
簡單查詢，不包含子查詢，不包含關聯查詢 union。
image.png
再看一個包含子查詢的案例：
-- 查詢 mysql 課程的老師手機號
EXPLAIN
SELECT
tc.phone
FROM
teacher_contact tc
WHERE tcid =
(SELECT
tcid
FROM
teacher t
WHERE t.tid =
(SELECT
c.tid
FROM
course c
WHERE c.cname = 'mysql')) ;
- PRIMARY
子查詢 SQL 語句中的主查詢，也就是最外面的那層查詢 - SUBQUERY
子查詢中所有的內層查詢都是 SUBQUERY 類型的 - DERIVED
衍生查詢，表示在得到最終查詢結果之前會用到臨時表。例如：
-- 查詢 ID 為 1 或 2 的老師教授的課程
EXPLAIN
SELECT
cr.cname
FROM
(SELECT
*
FROM
course
WHERE tid = 1
UNION
SELECT
*
FROM
course
WHERE tid = 2) cr ;
對于關聯查詢，先執行右邊的 table（UNION），再執行左邊的 table，類型是 DERIVED。
- UNION
用到了 UNION 查詢。同上例。 - UNION RESULT
主要是顯示哪些表之間存在 UNION 查詢。<union2,3>代表 id=2 和 id=3 的查詢 存在 UNION。同上例。
type 連接類型
https://dev.mysql.com/doc/refman/5.7/en/explain-output.html#explain-join-types
所有的連接類型中，上面的最好，越往下越差。
在常用的鏈接類型中：system > const > eq_ref > ref > range > index > all
這 里 并 沒 有 列 舉 全 部 （ 其 他 ： fulltext 、 ref_or_null 、 index_merger 、 unique_subquery、index_subquery）。
以上訪問類型除了 all，都能用到索引
- const
主鍵索引或者唯一索引，只能查到一條數據的 SQL
CREATE TABLE single_data (
id int(3) PRIMARY KEY,
content varchar(20)
);
INSERT INTO single_data
VALUES (1, 'a');
EXPLAIN SELECT *
FROM single_data a
WHERE id = 1;
-
system
system是 const 的一種特例，只有一行滿足條件。例如：只有一條數據的系統表。
image.png - eq_ref
通常出現在多表的 join 查詢，表示對于前表的每一個結果,，都只能匹配到后表的 一行結果。一般是唯一性索引的查詢（UNIQUE 或 PRIMARY KEY）。
eq_ref 是除 const 之外最好的訪問類型。
先刪除 teacher 表中多余的數據，teacher_contact 有 3 條數據，teacher 表有 3 條數據
DELETE FROM teacher WHERE tid IN (4, 5, 6);
為 teacher_contact 表的 tcid（第一個字段）創建主鍵索引。
ALTER TABLE teacher_contact ADD PRIMARY KEY(tcid);
為 teacher 表的 tcid（第三個字段）創建普通索引。
ALTER TABLE teacher ADD INDEX idx_tcid (tcid);
執行以下 SQL 語句：
select t.tcid from teacher t,teacher_contact tc where t.tcid = tc.tcid;
小結： 以上三種 system，const，eq_ref，都是可遇而不可求的，基本上很難優化到這個 狀態。
-
ref
查詢用到了非唯一性索引，或者關聯操作只使用了索引的最左前綴。
例如：使用 tcid 上的普通索引查詢：
image.png - range
索引范圍掃描。
如果 where 后面是 between and 或 <或 > 或 >= 或 <=或 in 這些，type 類型就為 range。
不走索引一定是全表掃描（ALL），所以先加上普通索引。
ALTER TABLE teacher ADD INDEX idx_tid (tid);
執行范圍查詢（字段上有普通索引）：
IN 查詢也是 range（字段有主鍵索引）
-
index
Full Index Scan，查詢全部索引中的數據（比不走索引要快）。
image.png - all
Full Table Scan，如果沒有索引或者沒有用到索引，type 就是 ALL。代表全表掃描。 - NULL
不用訪問表或者索引就能得到結果，例如：
EXPLAIN select 1 from dual where 1=1;
小結： 一般來說，需要保證查詢至少達到 range 級別，最好能達到 ref。 ALL（全表掃描）和 index（查詢全部索引）都是需要優化的。
possible_key、key
可能用到的索引和實際用到的索引。如果是 NULL 就代表沒有用到索引。 possible_key 可以有一個或者多個，可能用到索引不代表一定用到索引。 反過來，possible_key 為空，key 可能有值嗎？
表上創建聯合索引：
ALTER TABLE user_innodb DROP INDEX comidx_name_phone;
ALTER TABLE user_innodb add INDEX comidx_name_phone (name,phone);
執行計劃（改成 select name 也能用到索引）：
explain select phone from user_innodb where phone='126';
結論：是有可能的（這里是覆蓋索引的情況）。
如果通過分析發現沒有用到索引，就要檢查 SQL 或者創建索引。
key_len
索引的長度（使用的字節數）。跟索引字段的類型、長度有關
rows
MySQL 認為掃描多少行才能返回請求的數據，是一個預估值。一般來說行數越少越 好
filtered
這個字段表示存儲引擎返回的數據在 server 層過濾后，剩下多少滿足查詢的記錄數 量的比例，它是一個百分比
ref
使用哪個列或者常數和索引一起從表中篩選數據。
Extra
執行計劃給出的額外的信息說明
- using index
用到了覆蓋索引，不需要回表
EXPLAIN SELECT tid FROM teacher ;
- using where
使用了 where 過濾，表示存儲引擎返回的記錄并不是所有的都滿足查詢條件，需要 在 server 層進行過濾（跟是否使用索引沒有關系）。
EXPLAIN select * from user_innodb where phone ='13866667777';
- Using index condition（索引條件下推）
https://dev.mysql.com/doc/refman/5.7/en/index-condition-pushdown-optimization.html - using filesort
不能使用索引來排序，用到了額外的排序（跟磁盤或文件沒有關系）。需要優化。 （復合索引的前提）
ALTER TABLE user_innodb DROP INDEX comidx_name_phone;
ALTER TABLE user_innodb add INDEX comidx_name_phone (name,phone);
EXPLAIN select * from user_innodb where name ='青山' order by id;
- using temporary
用到了臨時表。例如（以下不是全部的情況）：
1、distinct 非索引列
EXPLAIN select DISTINCT(tid) from teacher t
2、group by 非索引列
EXPLAIN select tname from teacher group by tname;
3、使用 join 的時候，group 任意列
EXPLAIN select t.tid from teacher t join course c on t.tid = c.tid group by t.tid;
總結一下： 模擬優化器執行 SQL 查詢語句的過程，來知道 MySQL 是怎么處理一條 SQL 語句的。 通過這種方式我們可以分析語句或者表的性能瓶頸。 分析出問題之后，就是對 SQL 語句的具體優化。
SQL 與索引優化
當我們的 SQL 語句比較復雜，有多個關聯和子查詢的時候，就要分析 SQL 語句有沒 有改寫的方法。 舉個簡單的例子，一模一樣的數據：
-- 大偏移量的 limit
select * from user_innodb limit 900000,10;
-- 改成先過濾 ID，再 limit
SELECT * FROM user_innodb WHERE id >= 900000 LIMIT 10;
對于具體的 SQL 語句的優化，MySQL 官網也提供了很多建議，這個是我們在分析 具體的 SQL 語句的時候需要注意的
https://dev.mysql.com/doc/refman/5.7/en/optimization.html
阿里云 polardb 默認配置
4C16G polardb 1主3從 查詢主配置
SHOW VARIABLES LIKE 'max_connections%'; 8512
SHOW VARIABLES LIKE '%innodb_buffer_pool_size%'; 12884901888 = 12G
32C256G polardb 1主3從 查詢主配置
SHOW VARIABLES LIKE 'max_connections%'; 64512
SHOW VARIABLES LIKE '%innodb_buffer_pool_size%'; 206158430208 = 192G
88C710G polardb 1主3從 查詢主配置
SHOW VARIABLES LIKE 'max_connections%'; 100512
SHOW VARIABLES LIKE '%innodb_buffer_pool_size%'; 572304392192 = 533G
buffer_pool_size 約等于 內存的75%
——學自咕泡學院
