我們先來看第一個階段，MySQL慢的診斷思路，一般我們會從三個方向來做：
目前成都創(chuàng)新互聯(lián)公司已為千余家的企業(yè)提供了網(wǎng)站建設(shè)、域名、網(wǎng)絡(luò)空間、網(wǎng)站托管、企業(yè)網(wǎng)站設(shè)計、鐘山網(wǎng)站維護等服務(wù)，公司將堅持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。
第一個方向是MySQL內(nèi)部的觀測
第二個方向是外部資源的觀測
第三個方向是外部需求的改造
1.1 MySQL 內(nèi)部觀測
我們來看MySQL內(nèi)部的觀測，常用的觀測手段是這樣的，從上往下看，第一部分是Processlist，看一下哪個SQL壓力不太正常，第二步是explain，解釋一下它的執(zhí)行計劃，第三步我們要做Profilling，如果這個SQL能再執(zhí)行一次的話, 就做一個Profilling，然后高級的DBA會直接動用performance_schema ，MySQL 5.7 以后直接動用sys_schema，sys_schema是一個視圖，里面有便捷的各類信息，幫助大家來診斷性能。再高級一點，我們會動用innodb_metrics進行一個對引擎的診斷。
除了這些手段以外，大家還提出了一些亂七八糟的手段，我就不列在這了，這些是常規(guī)的一個MySQL的內(nèi)部的狀態(tài)觀測的思路。除了這些以外，MySQL還陸陸續(xù)續(xù)提供了一些暴露自己狀態(tài)的方案，但是這些方案并沒有在實踐中形成套路，原因是學(xué)習(xí)成本比較高。
1.2 外部資源觀測
外部資源觀測這部分，我引用了一篇文章，這篇文章的二維碼我貼在上面了。這篇文章是國外的一個神寫的，標題是：60秒的快速巡檢，我們來看一下它在60秒之內(nèi)對服務(wù)器到底做了一個什么樣的巡檢。一共十條命令，這是前五條，我們一條一條來看。
1.uptime，uptime告訴我們這個機器活了多久，以及它的平均的負載是多少。
2.dmesg -T | tail，告訴我們系統(tǒng)日志里邊有沒有什么報錯。
3.vmstat 1，告訴我們虛擬內(nèi)存的狀態(tài)，頁的換進換出有沒有問題，swap有沒有使用。
4. mpstat -P ALL，告訴我們CPU壓力在各個核上是不是均勻的。
5.pidstat 1，告訴我們各個進程的對資源的占用大概是什么樣子。
我們來看一下后五條：
首先是iostat-xz 1，查看IO的問題，然后是free-m內(nèi)存使用率，之后兩個sar，按設(shè)備網(wǎng)卡設(shè)備的維度，看一下網(wǎng)絡(luò)的消耗狀態(tài)，以及總體看TCP的使用率和錯誤率是多少。最后一條命令top，看一下大概的進程和線程的問題。
這個就是對于外部資源的診斷，這十條命令揭示了應(yīng)該去診斷哪些外部資源。
1.3 外部需求改造
第三個診斷思路是外部的需求改造，我在這里引用了一篇文檔，這篇文檔是MySQL的官方文檔中的一章，這一章叫Examples of Common Queries，文檔中介紹了常規(guī)的SQL怎么寫, 給出了一些例子。文章的鏈接二維碼在slide上。
我們來看一下它其中提到的一個例子。
它做的事情是從一個表里邊去選取，這張表有三列，article、dealer、price，選取每個作者的最貴的商品列在結(jié)果集中，這是它的最原始的SQL，非常符合業(yè)務(wù)的寫法，但是它是個關(guān)聯(lián)子查詢。
關(guān)聯(lián)子查詢成本是很貴的，所以上面的文檔會教你快速地把它轉(zhuǎn)成一個非關(guān)聯(lián)子查詢，大家可以看到中間的子查詢和外邊的查詢之間是沒有關(guān)聯(lián)性的。
第三步，會教大家直接把子查詢拿掉，然后轉(zhuǎn)成這樣一個SQL，這個就叫業(yè)務(wù)改造，前后三個SQL的成本都不一樣，把關(guān)聯(lián)子查詢拆掉的成本，拆掉以后SQL會跑得非常好，但這個SQL已經(jīng)不能良好表義了，只有在診斷到SQL成本比較高的情況下才建議大家使用這種方式。
為什么它能夠把一個關(guān)聯(lián)子查詢拆掉呢？
這背后的原理是關(guān)系代數(shù)，所有的SQL都可以被表達成等價的關(guān)系代數(shù)式，關(guān)系代數(shù)式之間有等價關(guān)系，這個等價關(guān)系通過變換可以把關(guān)聯(lián)子查詢拆掉。
上面的這篇文檔是一個大學(xué)的教材，它從頭教了關(guān)于代數(shù)和SQL之間的關(guān)系。然后一步步推導(dǎo)怎么去簡化這句SQL。
第一，MySQL本身提供了很多命令來觀察MySQL自身的各類狀態(tài)，大家從上往下檢一般能檢到SQL的問題或者服務(wù)器的問題。
第二，從服務(wù)器的角度，我們從巡檢的腳本角度入手，服務(wù)器的資源就這幾種，觀測手法也就那么幾種，我們把服務(wù)器的資源全部都觀察一圈就可以了。
第三，如果實在搞不定，需求方一定要按照數(shù)據(jù)庫容易接受的方式去寫SQL，這個成本會下降的非?？?，這個是常規(guī)的MySQL慢的診斷思路。
問題
我們有一個 SQL，用于找到?jīng)]有主鍵 / 唯一鍵的表，但是在 MySQL 5.7 上運行特別慢，怎么辦？
實驗
我們搭建一個 MySQL 5.7 的環(huán)境，此處省略搭建步驟。
寫個簡單的腳本，制造一批帶主鍵和不帶主鍵的表：
執(zhí)行一下腳本：
現(xiàn)在執(zhí)行以下 SQL 看看效果：
...
執(zhí)行了 16.80s，感覺是非常慢了。
現(xiàn)在用一下 DBA 三板斧，看看執(zhí)行計劃：
感覺有點慘，由于 information_schema.columns 是元數(shù)據(jù)表，沒有必要的統(tǒng)計信息。
那我們來 show warnings 看看 MySQL 改寫后的 SQL：
我們格式化一下 SQL：
可以看到 MySQL 將
select from A where A.x not in (select x from B) //非關(guān)聯(lián)子查詢
轉(zhuǎn)換成了
select from A where not exists (select 1 from B where B.x = a.x) //關(guān)聯(lián)子查詢
如果我們自己是 MySQL，在執(zhí)行非關(guān)聯(lián)子查詢時，可以使用很簡單的策略：
select from A where A.x not in (select x from B where ...) //非關(guān)聯(lián)子查詢:1. 掃描 B 表中的所有記錄，找到滿足條件的記錄，存放在臨時表 C 中，建好索引2. 掃描 A 表中的記錄，與臨時表 C 中的記錄進行比對，直接在索引里比對，
而關(guān)聯(lián)子查詢就需要循環(huán)迭代：
select from A where not exists (select 1 from B where B.x = a.x and ...) //關(guān)聯(lián)子查詢掃描 A 表的每一條記錄 rA： ? ? 掃描 B 表，找到其中的第一條滿足 rA 條件的記錄。
顯然，關(guān)聯(lián)子查詢的掃描成本會高于非關(guān)聯(lián)子查詢。
我們希望 MySQL 能先"緩存"子查詢的結(jié)果（緩存這一步叫物化，MATERIALIZATION），但MySQL 認為不緩存更快，我們就需要給予 MySQL 一定指導(dǎo)。
...
可以看到執(zhí)行時間變成了 0.67s。
整理
我們診斷的關(guān)鍵點如下：
\1. 對于 information_schema 中的元數(shù)據(jù)表，執(zhí)行計劃不能提供有效信息。
\2. 通過查看 MySQL 改寫后的 SQL，我們猜測了優(yōu)化器發(fā)生了誤判。
\3. 我們增加了 hint，指導(dǎo) MySQL 正確進行優(yōu)化判斷。
但目前我們的實驗僅限于猜測，猜中了萬事大吉，猜不中就無法做出好的診斷。
MySQL 在崩潰恢復(fù)時，會遍歷打開所有 ibd 文件的 header page 驗證數(shù)據(jù)字典的準確性，如果 MySQL 中包含了大量表，這個校驗過程就會比較耗時。 MySQL 下崩潰恢復(fù)確實和表數(shù)量有關(guān)，表總數(shù)越大，崩潰恢復(fù)時間越長。另外磁盤 IOPS 也會影響崩潰恢復(fù)時間，像這里開發(fā)庫的 HDD IOPS 較低，因此面對大量的表空間，校驗速度就非常緩慢。另外一個發(fā)現(xiàn)，MySQL 8 下正常啟用時居然也會進行表空間校驗，而故障恢復(fù)時則會額外再進行一次表空間校驗，等于校驗了 2 遍。不過 MySQL 8.0 里多了一個特性，即表數(shù)量超過 5W 時，會啟用多線程掃描，加快表空間校驗過程。
如何跳過校驗MySQL 5.7 下有方法可以跳過崩潰恢復(fù)時的表空間校驗過程嘛？查閱了資料，方法主要有兩種：
1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳過表空間校驗。實際測試的時候設(shè)置 innodb_force_recovery =1，也就是強制恢復(fù)跳過壞頁，就可以跳過校驗，然后重啟就是正常啟動了。通過這種臨時方式可以避免崩潰恢復(fù)后非常耗時的表空間校驗過程，快速啟動 MySQL，個人目前暫時未發(fā)現(xiàn)有什么隱患。2. 使用共享表空間替代獨立表空間這樣就不需要打開 N 個 ibd 文件了，只需要打開一個 ibdata 文件即可，大大節(jié)省了校驗時間。自從聽了姜老師講過使用共享表空間替代獨立表空間解決 drop 大表時性能抖動的原理后，感覺共享表空間在很多業(yè)務(wù)環(huán)境下，反而更有優(yōu)勢。
臨時冒出另外一種解決想法，即用 GDB 調(diào)試崩潰恢復(fù)，通過臨時修改 validate 變量值讓 MySQL 跳過表空間驗證過程，然后讓 MySQL 正常關(guān)閉，重新啟動就可以正常啟動了。但是實際測試發(fā)現(xiàn)，如果以 debug 模式運行，確實可以臨時修改 validate 變量，跳過表空間驗證過程，但是 debug 模式下代碼運行效率大打折扣，反而耗時更長。而以非 debug 模式運行，則無法修改 validate 變量，想法破滅。
問題
我們有一個 SQL，用于找到?jīng)]有主鍵 / 唯一鍵的表，但是在 MySQL 5.7 上運行特別慢，怎么辦？
實驗
我們搭建一個 MySQL 5.7 的環(huán)境，此處省略搭建步驟。
寫個簡單的腳本，制造一批帶主鍵和不帶主鍵的表：
執(zhí)行一下腳本：
現(xiàn)在執(zhí)行以下 SQL 看看效果：
...
執(zhí)行了 16.80s，感覺是非常慢了。
現(xiàn)在用一下 DBA 三板斧，看看執(zhí)行計劃：
感覺有點慘，由于 information_schema.columns 是元數(shù)據(jù)表，沒有必要的統(tǒng)計信息。
那我們來 show warnings 看看 MySQL 改寫后的 SQL：
我們格式化一下 SQL：
可以看到 MySQL 將
select from A where A.x not in (select x from B) //非關(guān)聯(lián)子查詢
轉(zhuǎn)換成了
select from A where not exists (select 1 from B where B.x = a.x) //關(guān)聯(lián)子查詢
如果我們自己是 MySQL，在執(zhí)行非關(guān)聯(lián)子查詢時，可以使用很簡單的策略：
select from A where A.x not in (select x from B where ...) //非關(guān)聯(lián)子查詢:1. 掃描 B 表中的所有記錄，找到滿足條件的記錄，存放在臨時表 C 中，建好索引2. 掃描 A 表中的記錄，與臨時表 C 中的記錄進行比對，直接在索引里比對，
而關(guān)聯(lián)子查詢就需要循環(huán)迭代：
select from A where not exists (select 1 from B where B.x = a.x and ...) //關(guān)聯(lián)子查詢掃描 A 表的每一條記錄 rA： ? ? 掃描 B 表，找到其中的第一條滿足 rA 條件的記錄。
顯然，關(guān)聯(lián)子查詢的掃描成本會高于非關(guān)聯(lián)子查詢。
我們希望 MySQL 能先"緩存"子查詢的結(jié)果（緩存這一步叫物化，MATERIALIZATION），但MySQL 認為不緩存更快，我們就需要給予 MySQL 一定指導(dǎo)。
...
可以看到執(zhí)行時間變成了 0.67s。
整理
我們診斷的關(guān)鍵點如下：
\1. 對于 information_schema 中的元數(shù)據(jù)表，執(zhí)行計劃不能提供有效信息。
\2. 通過查看 MySQL 改寫后的 SQL，我們猜測了優(yōu)化器發(fā)生了誤判。
\3. 我們增加了 hint，指導(dǎo) MySQL 正確進行優(yōu)化判斷。
但目前我們的實驗僅限于猜測，猜中了萬事大吉，猜不中就無法做出好的診斷。
重慶分公司
重慶分公司
