問(wèn)題
成都創(chuàng)新互聯(lián)2013年開(kāi)創(chuàng)至今，先為醴陵等服務(wù)建站，醴陵等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為醴陵企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問(wèn)題。
我們有一個(gè) SQL，用于找到?jīng)]有主鍵 / 唯一鍵的表，但是在 MySQL 5.7 上運(yùn)行特別慢，怎么辦？
實(shí)驗(yàn)
我們搭建一個(gè) MySQL 5.7 的環(huán)境，此處省略搭建步驟。
寫(xiě)個(gè)簡(jiǎn)單的腳本，制造一批帶主鍵和不帶主鍵的表：
執(zhí)行一下腳本：
現(xiàn)在執(zhí)行以下 SQL 看看效果：
...
執(zhí)行了 16.80s，感覺(jué)是非常慢了。
現(xiàn)在用一下 DBA 三板斧，看看執(zhí)行計(jì)劃：
感覺(jué)有點(diǎn)慘，由于 information_schema.columns 是元數(shù)據(jù)表，沒(méi)有必要的統(tǒng)計(jì)信息。
那我們來(lái) show warnings 看看 MySQL 改寫(xiě)后的 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)子查詢時(shí)，可以使用很簡(jiǎn)單的策略：
select from A where A.x not in (select x from B where ...) //非關(guān)聯(lián)子查詢:1. 掃描 B 表中的所有記錄，找到滿足條件的記錄，存放在臨時(shí)表 C 中，建好索引2. 掃描 A 表中的記錄，與臨時(shí)表 C 中的記錄進(jìn)行比對(duì)，直接在索引里比對(duì)，
而關(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)子查詢的掃描成本會(huì)高于非關(guān)聯(lián)子查詢。
我們希望 MySQL 能先"緩存"子查詢的結(jié)果（緩存這一步叫物化，MATERIALIZATION），但MySQL 認(rèn)為不緩存更快，我們就需要給予 MySQL 一定指導(dǎo)。
...
可以看到執(zhí)行時(shí)間變成了 0.67s。
整理
我們?cè)\斷的關(guān)鍵點(diǎn)如下：
\1. 對(duì)于 information_schema 中的元數(shù)據(jù)表，執(zhí)行計(jì)劃不能提供有效信息。
\2. 通過(guò)查看 MySQL 改寫(xiě)后的 SQL，我們猜測(cè)了優(yōu)化器發(fā)生了誤判。
\3. 我們?cè)黾恿?hint，指導(dǎo) MySQL 正確進(jìn)行優(yōu)化判斷。
但目前我們的實(shí)驗(yàn)僅限于猜測(cè)，猜中了萬(wàn)事大吉，猜不中就無(wú)法做出好的診斷。
一、檢查系統(tǒng)的狀態(tài)
通過(guò)操作系統(tǒng)的一些工具檢查系統(tǒng)的狀態(tài)，比如CPU、內(nèi)存、交換、磁盤(pán)的利用率，根據(jù)經(jīng)驗(yàn)或與系統(tǒng)正常時(shí)的狀態(tài)相比對(duì)，有時(shí)系統(tǒng)表面上看起來(lái)看空閑，這也可能不是一個(gè)正常的狀態(tài)，因?yàn)閏pu可能正等待IO的完成。除此之外，還應(yīng)觀注那些占用系統(tǒng)資源(cpu、內(nèi)存)的進(jìn)程。
1.使用sar來(lái)檢查操作系統(tǒng)是否存在IO問(wèn)題
#sar-u210—
即每隔2秒檢察一次，共執(zhí)行20次。
結(jié)果示例：
注：在redhat下，%system就是所謂的%wio。
Linux2.4.21-20.ELsmp
(YY075)05/19/2005
10:36:07AMCPU%user%nice%system%idle
10:36:09AMall0.000.000.1399.87
10:36:11AMall0.000.000.00100.00
10:36:13AMall0.250.000.2599.49
10:36:15AMall0.130.000.1399.75
10:36:17AMall0.000.000.00100.00
其中：
%usr指的是用戶進(jìn)程使用的cpu資源的百分比;
%sys指的是系統(tǒng)資源使用cpu資源的百分比;
%wio指的是等待io完成的百分比，這是值得觀注的一項(xiàng);
%idle即空閑的百分比。
如果wio列的值很大，如在35%以上，說(shuō)明系統(tǒng)的IO存在瓶頸，CPU花費(fèi)了很大的時(shí)間去等待I/O的完成。Idle很小說(shuō)明系統(tǒng)CPU很忙。像以上的示例，可以看到wio平均值為11，說(shuō)明I/O沒(méi)什么特別的問(wèn)題，而idle值為零，說(shuō)明cpu已經(jīng)滿負(fù)荷運(yùn)行了。
2.使用vmstat監(jiān)控內(nèi)存
cpu資源
[root@mysql1
~]#
vmstat
procs
———–memory———-—swap–
—–io—-–system–
—–cpu——
r
b
swpd
free
buff
cache
si
so
bi
bo
in
cs
us
sy
id
wa
st
72
25428
54712672264
14
43
53
59
1
198
vmstat
的輸出那些信息值得關(guān)注?
io
bo:
磁盤(pán)寫(xiě)的數(shù)據(jù)量稍大，如果是大文件的寫(xiě)，10M以內(nèi)基本不用擔(dān)心，如果是小文件寫(xiě)2M以內(nèi)基本正常
①
CPU問(wèn)題
下面幾列需要被察看，以確定cpu是否有問(wèn)題
Processesinthe
run
queue
(procs
r)
Usertime
(cpu
us)
System
time
(cpu
sy)
Idle
time
(cpu
id)
問(wèn)題情況:
如果processes
in
run
queue
(procs
r)的數(shù)量遠(yuǎn)大于系統(tǒng)中cpu的數(shù)量，將會(huì)使系統(tǒng)便慢。
如果這個(gè)數(shù)量是cpu的4倍的話，說(shuō)明系統(tǒng)正面臨cpu能力短缺,這將使系統(tǒng)運(yùn)行速度大幅度降低
如果cpu的idle時(shí)間經(jīng)常為0的話，或者系統(tǒng)占用時(shí)間(cpu
sy)是用戶占用時(shí)間(cpu
us)兩輩的話，系統(tǒng)面臨缺少cpu資源
解決方案
:
解決這些情況，涉及到調(diào)整應(yīng)用程序，使其能更有效的使用cpu，同時(shí)增加cpu的能力或數(shù)量
②內(nèi)存問(wèn)題
主要查看頁(yè)導(dǎo)入的數(shù)值(swap中的si)，如果該值比較大就要考慮內(nèi)存，大概方法如下：
最簡(jiǎn)單的，加大RAM
減少RAM的需求
3.磁盤(pán)IO問(wèn)題
處理方式：做raid10提高性能
4.網(wǎng)絡(luò)問(wèn)題
telnet一下MySQL對(duì)外開(kāi)放的端口，如果不通的話，看看防火墻是否正確設(shè)置了。另外，看看MySQL是不是開(kāi)啟了skip-networking的選項(xiàng)，如果開(kāi)啟請(qǐng)關(guān)閉。
MySQL 在崩潰恢復(fù)時(shí)，會(huì)遍歷打開(kāi)所有 ibd 文件的 header page 驗(yàn)證數(shù)據(jù)字典的準(zhǔn)確性，如果 MySQL 中包含了大量表，這個(gè)校驗(yàn)過(guò)程就會(huì)比較耗時(shí)。 MySQL 下崩潰恢復(fù)確實(shí)和表數(shù)量有關(guān)，表總數(shù)越大，崩潰恢復(fù)時(shí)間越長(zhǎng)。另外磁盤(pán) IOPS 也會(huì)影響崩潰恢復(fù)時(shí)間，像這里開(kāi)發(fā)庫(kù)的 HDD IOPS 較低，因此面對(duì)大量的表空間，校驗(yàn)速度就非常緩慢。另外一個(gè)發(fā)現(xiàn)，MySQL 8 下正常啟用時(shí)居然也會(huì)進(jìn)行表空間校驗(yàn)，而故障恢復(fù)時(shí)則會(huì)額外再進(jìn)行一次表空間校驗(yàn)，等于校驗(yàn)了 2 遍。不過(guò) MySQL 8.0 里多了一個(gè)特性，即表數(shù)量超過(guò) 5W 時(shí)，會(huì)啟用多線程掃描，加快表空間校驗(yàn)過(guò)程。
如何跳過(guò)校驗(yàn)MySQL 5.7 下有方法可以跳過(guò)崩潰恢復(fù)時(shí)的表空間校驗(yàn)過(guò)程嘛？查閱了資料，方法主要有兩種：
1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳過(guò)表空間校驗(yàn)。實(shí)際測(cè)試的時(shí)候設(shè)置 innodb_force_recovery =1，也就是強(qiáng)制恢復(fù)跳過(guò)壞頁(yè)，就可以跳過(guò)校驗(yàn)，然后重啟就是正常啟動(dòng)了。通過(guò)這種臨時(shí)方式可以避免崩潰恢復(fù)后非常耗時(shí)的表空間校驗(yàn)過(guò)程，快速啟動(dòng) MySQL，個(gè)人目前暫時(shí)未發(fā)現(xiàn)有什么隱患。2. 使用共享表空間替代獨(dú)立表空間這樣就不需要打開(kāi) N 個(gè) ibd 文件了，只需要打開(kāi)一個(gè) ibdata 文件即可，大大節(jié)省了校驗(yàn)時(shí)間。自從聽(tīng)了姜老師講過(guò)使用共享表空間替代獨(dú)立表空間解決 drop 大表時(shí)性能抖動(dòng)的原理后，感覺(jué)共享表空間在很多業(yè)務(wù)環(huán)境下，反而更有優(yōu)勢(shì)。
臨時(shí)冒出另外一種解決想法，即用 GDB 調(diào)試崩潰恢復(fù)，通過(guò)臨時(shí)修改 validate 變量值讓 MySQL 跳過(guò)表空間驗(yàn)證過(guò)程，然后讓 MySQL 正常關(guān)閉，重新啟動(dòng)就可以正常啟動(dòng)了。但是實(shí)際測(cè)試發(fā)現(xiàn)，如果以 debug 模式運(yùn)行，確實(shí)可以臨時(shí)修改 validate 變量，跳過(guò)表空間驗(yàn)證過(guò)程，但是 debug 模式下代碼運(yùn)行效率大打折扣，反而耗時(shí)更長(zhǎng)。而以非 debug 模式運(yùn)行，則無(wú)法修改 validate 變量，想法破滅。
MySQL 在崩潰恢復(fù)時(shí)，會(huì)遍歷打開(kāi)所有 ibd 文件的 header page 驗(yàn)證數(shù)據(jù)字典的準(zhǔn)確性，如果 MySQL 中包含了大量表，這個(gè)校驗(yàn)過(guò)程就會(huì)比較耗時(shí)。 MySQL 下崩潰恢復(fù)確實(shí)和表數(shù)量有關(guān)，表總數(shù)越大，崩潰恢復(fù)時(shí)間越長(zhǎng)。另外磁盤(pán) IOPS 也會(huì)影響崩潰恢復(fù)時(shí)間，像這里開(kāi)發(fā)庫(kù)的 HDD IOPS 較低，因此面對(duì)大量的表空間，校驗(yàn)速度就非常緩慢。另外一個(gè)發(fā)現(xiàn)，MySQL 8 下正常啟用時(shí)居然也會(huì)進(jìn)行表空間校驗(yàn)，而故障恢復(fù)時(shí)則會(huì)額外再進(jìn)行一次表空間校驗(yàn)，等于校驗(yàn)了 2 遍。不過(guò) MySQL 8.0 里多了一個(gè)特性，即表數(shù)量超過(guò) 5W 時(shí)，會(huì)啟用多線程掃描，加快表空間校驗(yàn)過(guò)程。
如何跳過(guò)校驗(yàn)MySQL 5.7 下有方法可以跳過(guò)崩潰恢復(fù)時(shí)的表空間校驗(yàn)過(guò)程嘛？查閱了資料，方法主要有兩種：
1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳過(guò)表空間校驗(yàn)。實(shí)際測(cè)試的時(shí)候設(shè)置 innodb_force_recovery =1，也就是強(qiáng)制恢復(fù)跳過(guò)壞頁(yè)，就可以跳過(guò)校驗(yàn)，然后重啟就是正常啟動(dòng)了。通過(guò)這種臨時(shí)方式可以避免崩潰恢復(fù)后非常耗時(shí)的表空間校驗(yàn)過(guò)程，快速啟動(dòng) MySQL，個(gè)人目前暫時(shí)未發(fā)現(xiàn)有什么隱患。2. 使用共享表空間替代獨(dú)立表空間這樣就不需要打開(kāi) N 個(gè) ibd 文件了，只需要打開(kāi)一個(gè) ibdata 文件即可，大大節(jié)省了校驗(yàn)時(shí)間。自從聽(tīng)了姜老師講過(guò)使用共享表空間替代獨(dú)立表空間解決 drop 大表時(shí)性能抖動(dòng)的原理后，感覺(jué)共享表空間在很多業(yè)務(wù)環(huán)境下，反而更有優(yōu)勢(shì)。
臨時(shí)冒出另外一種解決想法，即用 GDB 調(diào)試崩潰恢復(fù)，通過(guò)臨時(shí)修改 validate 變量值讓 MySQL 跳過(guò)表空間驗(yàn)證過(guò)程，然后讓 MySQL 正常關(guān)閉，重新啟動(dòng)就可以正常啟動(dòng)了。但是實(shí)際測(cè)試發(fā)現(xiàn)，如果以 debug 模式運(yùn)行，確實(shí)可以臨時(shí)修改 validate 變量，跳過(guò)表空間驗(yàn)證過(guò)程，但是 debug 模式下代碼運(yùn)行效率大打折扣，反而耗時(shí)更長(zhǎng)。而以非 debug 模式運(yùn)行，則無(wú)法修改 validate 變量，想法破滅。
1.當(dāng)我們請(qǐng)求mysql服務(wù)器的時(shí)候,MySQL前端會(huì)有一個(gè)監(jiān)聽(tīng),請(qǐng)求到了之后,服務(wù)器得到相關(guān)的SQL語(yǔ)句,執(zhí)行之前(虛線部分為執(zhí)行),還會(huì)做權(quán)限的判斷
2.通過(guò)權(quán)限之后,SQL就到MySQL內(nèi)部,他會(huì)在查詢緩存中,看該SQL有沒(méi)有執(zhí)行過(guò),如果有查詢過(guò),則把緩存結(jié)果返回,說(shuō)明在MySQL內(nèi)部,也有一個(gè)查詢緩存.但是這個(gè)查詢緩存,默認(rèn)是不開(kāi)啟的,這個(gè)查詢緩存,和我們的Hibernate，Mybatis的查詢緩存是一樣的,因?yàn)椴樵兙彺嬉骃QL和參數(shù)都要一樣,所以這個(gè)命中率是非常低的（沒(méi)什么卵用的意思）。
3.如果我們沒(méi)有開(kāi)啟查詢緩存,或者緩存中沒(méi)有找到對(duì)應(yīng)的結(jié)果,那么就到了解析器,解析器主要對(duì)SQL語(yǔ)法進(jìn)行解析
4.解析結(jié)束后就變成一顆解析樹(shù),這個(gè)解析樹(shù)其實(shí)在Hibernate里面也是有的,大家回憶一下,在以前做過(guò)Hibernate項(xiàng)目的時(shí)候,是不是有個(gè)一個(gè)antlr.jar。這個(gè)就是專(zhuān)門(mén)做語(yǔ)法解析的工具.因?yàn)樵贖ibernate里面有HQL，它就是通過(guò)這個(gè)工具轉(zhuǎn)換成SQL的,我們編程語(yǔ)言之所以有很多規(guī)范、語(yǔ)法,其實(shí)就是為了便于這個(gè)解析器解析,這個(gè)學(xué)過(guò)編譯原理的應(yīng)該知道.
5.得到解析樹(shù)之后,不能馬上執(zhí)行,這還需要對(duì)這棵樹(shù)進(jìn)行預(yù)處理,也就是說(shuō),這棵樹(shù),我沒(méi)有經(jīng)過(guò)任何優(yōu)化的樹(shù),預(yù)處理器會(huì)這這棵樹(shù)進(jìn)行一些預(yù)處理,比如常量放在什么地方,如果有計(jì)算的東西,把計(jì)算的結(jié)果算出來(lái)等等...
6.預(yù)處理完畢之后,此時(shí)得到一棵比較規(guī)范的樹(shù),這棵樹(shù)就是要拿去馬上做執(zhí)行的樹(shù),比起之前的那棵樹(shù),這棵得到了一些優(yōu)化
7.查詢優(yōu)化器，是MySQL里面最關(guān)鍵的東西,我們寫(xiě)任何一條SQL,比如SELECT * FROM USER WHERE USERNAME = toby AND PASSWORD = 1,它會(huì)怎么去執(zhí)行?它是先執(zhí)行username = toby還是password = 1?每一條SQL的執(zhí)行順序查詢優(yōu)化器就是根據(jù)MySQL對(duì)數(shù)據(jù)統(tǒng)計(jì)表的一些信息,比如索引,比如表一共有多少數(shù)據(jù),MySQL都是有緩存起來(lái)的,在真正執(zhí)行SQL之前,他會(huì)根據(jù)自己的這些數(shù)據(jù),進(jìn)行一個(gè)綜合的判定,判斷這一次在多種執(zhí)行方式里面,到底選哪一種執(zhí)行方式,可能運(yùn)行的最快.這一步是MySQL性能中,最關(guān)鍵的核心點(diǎn),也是我們的優(yōu)化原則.我們平時(shí)所講的優(yōu)化SQL,其實(shí)說(shuō)白了,就是想讓查詢優(yōu)化器,按照我們的想法,幫我們選擇最優(yōu)的執(zhí)行方案,因?yàn)槲覀儽萂ySQL更懂我們的數(shù)據(jù).MySQL看數(shù)據(jù),僅僅只是自己收集到的信息,這些信息可能是不準(zhǔn)確的,MySQL根據(jù)這些信息選了一個(gè)它自認(rèn)為最優(yōu)的方案,但是這個(gè)方案可能和我們想象的不一樣.
8.這里的查詢執(zhí)行計(jì)劃,也就是MySQL查詢中的執(zhí)行計(jì)劃,比如要先執(zhí)行username = toby還是password = 1
9.這個(gè)執(zhí)行計(jì)劃會(huì)傳給查詢執(zhí)行引擎,執(zhí)行引擎選擇存儲(chǔ)引擎來(lái)執(zhí)行這一份傳過(guò)來(lái)的計(jì)劃,到磁盤(pán)中的文件中去查詢,這個(gè)時(shí)候重點(diǎn)來(lái)了,影響這個(gè)查詢性能最根本的原因是什么?就是硬盤(pán)的機(jī)械運(yùn)動(dòng),也就是我們平時(shí)熟悉的IO,所以一條查詢語(yǔ)句是快還是慢,就是根據(jù)這個(gè)時(shí)間的IO來(lái)確定的.那怎么執(zhí)行IO又是什么來(lái)確定的?就是傳過(guò)來(lái)的這一份執(zhí)行計(jì)劃.(優(yōu)化就是制定一個(gè)我們認(rèn)為最快的執(zhí)行方案,最節(jié)省IO,和執(zhí)行最快)
10.如果開(kāi)了查詢緩存,則返回結(jié)果給客戶端,并且查詢緩存也放一份。
我們先來(lái)看第一個(gè)階段，MySQL慢的診斷思路，一般我們會(huì)從三個(gè)方向來(lái)做：
第一個(gè)方向是MySQL內(nèi)部的觀測(cè)
第二個(gè)方向是外部資源的觀測(cè)
第三個(gè)方向是外部需求的改造
1.1 MySQL 內(nèi)部觀測(cè)
我們來(lái)看MySQL內(nèi)部的觀測(cè)，常用的觀測(cè)手段是這樣的，從上往下看，第一部分是Processlist，看一下哪個(gè)SQL壓力不太正常，第二步是explain，解釋一下它的執(zhí)行計(jì)劃，第三步我們要做Profilling，如果這個(gè)SQL能再執(zhí)行一次的話, 就做一個(gè)Profilling，然后高級(jí)的DBA會(huì)直接動(dòng)用performance_schema ，MySQL 5.7 以后直接動(dòng)用sys_schema，sys_schema是一個(gè)視圖，里面有便捷的各類(lèi)信息，幫助大家來(lái)診斷性能。再高級(jí)一點(diǎn)，我們會(huì)動(dòng)用innodb_metrics進(jìn)行一個(gè)對(duì)引擎的診斷。
除了這些手段以外，大家還提出了一些亂七八糟的手段，我就不列在這了，這些是常規(guī)的一個(gè)MySQL的內(nèi)部的狀態(tài)觀測(cè)的思路。除了這些以外，MySQL還陸陸續(xù)續(xù)提供了一些暴露自己狀態(tài)的方案，但是這些方案并沒(méi)有在實(shí)踐中形成套路，原因是學(xué)習(xí)成本比較高。
1.2 外部資源觀測(cè)
外部資源觀測(cè)這部分，我引用了一篇文章，這篇文章的二維碼我貼在上面了。這篇文章是國(guó)外的一個(gè)神寫(xiě)的，標(biāo)題是：60秒的快速巡檢，我們來(lái)看一下它在60秒之內(nèi)對(duì)服務(wù)器到底做了一個(gè)什么樣的巡檢。一共十條命令，這是前五條，我們一條一條來(lái)看。
1.uptime，uptime告訴我們這個(gè)機(jī)器活了多久，以及它的平均的負(fù)載是多少。
2.dmesg -T | tail，告訴我們系統(tǒng)日志里邊有沒(méi)有什么報(bào)錯(cuò)。
3.vmstat 1，告訴我們虛擬內(nèi)存的狀態(tài)，頁(yè)的換進(jìn)換出有沒(méi)有問(wèn)題，swap有沒(méi)有使用。
4. mpstat -P ALL，告訴我們CPU壓力在各個(gè)核上是不是均勻的。
5.pidstat 1，告訴我們各個(gè)進(jìn)程的對(duì)資源的占用大概是什么樣子。
我們來(lái)看一下后五條：
首先是iostat-xz 1，查看IO的問(wèn)題，然后是free-m內(nèi)存使用率，之后兩個(gè)sar，按設(shè)備網(wǎng)卡設(shè)備的維度，看一下網(wǎng)絡(luò)的消耗狀態(tài)，以及總體看TCP的使用率和錯(cuò)誤率是多少。最后一條命令top，看一下大概的進(jìn)程和線程的問(wèn)題。
這個(gè)就是對(duì)于外部資源的診斷，這十條命令揭示了應(yīng)該去診斷哪些外部資源。
1.3 外部需求改造
第三個(gè)診斷思路是外部的需求改造，我在這里引用了一篇文檔，這篇文檔是MySQL的官方文檔中的一章，這一章叫Examples of Common Queries，文檔中介紹了常規(guī)的SQL怎么寫(xiě), 給出了一些例子。文章的鏈接二維碼在slide上。
我們來(lái)看一下它其中提到的一個(gè)例子。
它做的事情是從一個(gè)表里邊去選取，這張表有三列，article、dealer、price，選取每個(gè)作者的最貴的商品列在結(jié)果集中，這是它的最原始的SQL，非常符合業(yè)務(wù)的寫(xiě)法，但是它是個(gè)關(guān)聯(lián)子查詢。
關(guān)聯(lián)子查詢成本是很貴的，所以上面的文檔會(huì)教你快速地把它轉(zhuǎn)成一個(gè)非關(guān)聯(lián)子查詢，大家可以看到中間的子查詢和外邊的查詢之間是沒(méi)有關(guān)聯(lián)性的。
第三步，會(huì)教大家直接把子查詢拿掉，然后轉(zhuǎn)成這樣一個(gè)SQL，這個(gè)就叫業(yè)務(wù)改造，前后三個(gè)SQL的成本都不一樣，把關(guān)聯(lián)子查詢拆掉的成本，拆掉以后SQL會(huì)跑得非常好，但這個(gè)SQL已經(jīng)不能良好表義了，只有在診斷到SQL成本比較高的情況下才建議大家使用這種方式。
為什么它能夠把一個(gè)關(guān)聯(lián)子查詢拆掉呢？
這背后的原理是關(guān)系代數(shù)，所有的SQL都可以被表達(dá)成等價(jià)的關(guān)系代數(shù)式，關(guān)系代數(shù)式之間有等價(jià)關(guān)系，這個(gè)等價(jià)關(guān)系通過(guò)變換可以把關(guān)聯(lián)子查詢拆掉。
上面的這篇文檔是一個(gè)大學(xué)的教材，它從頭教了關(guān)于代數(shù)和SQL之間的關(guān)系。然后一步步推導(dǎo)怎么去簡(jiǎn)化這句SQL。
第一，MySQL本身提供了很多命令來(lái)觀察MySQL自身的各類(lèi)狀態(tài)，大家從上往下檢一般能檢到SQL的問(wèn)題或者服務(wù)器的問(wèn)題。
第二，從服務(wù)器的角度，我們從巡檢的腳本角度入手，服務(wù)器的資源就這幾種，觀測(cè)手法也就那么幾種，我們把服務(wù)器的資源全部都觀察一圈就可以了。
第三，如果實(shí)在搞不定，需求方一定要按照數(shù)據(jù)庫(kù)容易接受的方式去寫(xiě)SQL，這個(gè)成本會(huì)下降的非常快，這個(gè)是常規(guī)的MySQL慢的診斷思路。
重慶分公司
重慶分公司
