MySQL 查詢慢的問題

問題

在晉安等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場(chǎng)前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都網(wǎng)站建設(shè)、成都做網(wǎng)站 網(wǎng)站設(shè)計(jì)制作定制開發(fā),公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),高端網(wǎng)站設(shè)計(jì),成都全網(wǎng)營(yíng)銷推廣,成都外貿(mào)網(wǎng)站制作,晉安網(wǎng)站建設(shè)費(fèi)用合理。

我們有一個(gè) SQL，用于找到?jīng)]有主鍵 / 唯一鍵的表，但是在 MySQL 5.7 上運(yùn)行特別慢，怎么辦？

實(shí)驗(yàn)

我們搭建一個(gè) MySQL 5.7 的環(huán)境，此處省略搭建步驟。

寫個(gè)簡(jiǎn)單的腳本，制造一批帶主鍵和不帶主鍵的表：

執(zhí)行一下腳本：

現(xiàn)在執(zhí)行以下 SQL 看看效果：

...

執(zhí)行了 16.80s，感覺是非常慢了。

現(xiàn)在用一下 DBA 三板斧，看看執(zhí)行計(jì)劃：

感覺有點(diǎn)慘，由于 information_schema.columns 是元數(shù)據(jù)表，沒有必要的統(tǒng)計(jì)信息。

那我們來 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)子查詢時(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. 通過查看 MySQL 改寫后的 SQL，我們猜測(cè)了優(yōu)化器發(fā)生了誤判。

\3. 我們?cè)黾恿?hint，指導(dǎo) MySQL 正確進(jìn)行優(yōu)化判斷。

但目前我們的實(shí)驗(yàn)僅限于猜測(cè)，猜中了萬事大吉，猜不中就無法做出好的診斷。

MySQL數(shù)據(jù)庫(kù)服務(wù)器逐漸變慢 該怎么分析與解決

我們先來看第一個(gè)階段，MySQL慢的診斷思路，一般我們會(huì)從三個(gè)方向來做：

第一個(gè)方向是MySQL內(nèi)部的觀測(cè)

第二個(gè)方向是外部資源的觀測(cè)

第三個(gè)方向是外部需求的改造

1.1 MySQL 內(nèi)部觀測(cè)

我們來看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è)視圖，里面有便捷的各類信息，幫助大家來診斷性能。再高級(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)的方案，但是這些方案并沒有在實(shí)踐中形成套路，原因是學(xué)習(xí)成本比較高。

1.2 外部資源觀測(cè)

外部資源觀測(cè)這部分，我引用了一篇文章，這篇文章的二維碼我貼在上面了。這篇文章是國(guó)外的一個(gè)神寫的，標(biāo)題是：60秒的快速巡檢，我們來看一下它在60秒之內(nèi)對(duì)服務(wù)器到底做了一個(gè)什么樣的巡檢。一共十條命令，這是前五條，我們一條一條來看。

1.uptime，uptime告訴我們這個(gè)機(jī)器活了多久，以及它的平均的負(fù)載是多少。

2.dmesg -T | tail，告訴我們系統(tǒng)日志里邊有沒有什么報(bào)錯(cuò)。

3.vmstat 1，告訴我們虛擬內(nèi)存的狀態(tài)，頁的換進(jìn)換出有沒有問題，swap有沒有使用。

4. mpstat -P ALL，告訴我們CPU壓力在各個(gè)核上是不是均勻的。

5.pidstat 1，告訴我們各個(gè)進(jìn)程的對(duì)資源的占用大概是什么樣子。

我們來看一下后五條：

首先是iostat-xz 1，查看IO的問題，然后是free-m內(nèi)存使用率，之后兩個(gè)sar，按設(shè)備網(wǎng)卡設(shè)備的維度，看一下網(wǎng)絡(luò)的消耗狀態(tài)，以及總體看TCP的使用率和錯(cuò)誤率是多少。最后一條命令top，看一下大概的進(jìn)程和線程的問題。

這個(gè)就是對(duì)于外部資源的診斷，這十條命令揭示了應(yīng)該去診斷哪些外部資源。

1.3 外部需求改造

第三個(gè)診斷思路是外部的需求改造，我在這里引用了一篇文檔，這篇文檔是MySQL的官方文檔中的一章，這一章叫Examples of Common Queries，文檔中介紹了常規(guī)的SQL怎么寫, 給出了一些例子。文章的鏈接二維碼在slide上。

我們來看一下它其中提到的一個(gè)例子。

它做的事情是從一個(gè)表里邊去選取，這張表有三列，article、dealer、price，選取每個(gè)作者的最貴的商品列在結(jié)果集中，這是它的最原始的SQL，非常符合業(yè)務(wù)的寫法，但是它是個(gè)關(guān)聯(lián)子查詢。

關(guān)聯(lián)子查詢成本是很貴的，所以上面的文檔會(huì)教你快速地把它轉(zhuǎn)成一個(gè)非關(guān)聯(lián)子查詢，大家可以看到中間的子查詢和外邊的查詢之間是沒有關(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ān)聯(lián)子查詢拆掉。

上面的這篇文檔是一個(gè)大學(xué)的教材，它從頭教了關(guān)于代數(shù)和SQL之間的關(guān)系。然后一步步推導(dǎo)怎么去簡(jiǎn)化這句SQL。

第一，MySQL本身提供了很多命令來觀察MySQL自身的各類狀態(tài)，大家從上往下檢一般能檢到SQL的問題或者服務(wù)器的問題。

第二，從服務(wù)器的角度，我們從巡檢的腳本角度入手，服務(wù)器的資源就這幾種，觀測(cè)手法也就那么幾種，我們把服務(wù)器的資源全部都觀察一圈就可以了。

第三，如果實(shí)在搞不定，需求方一定要按照數(shù)據(jù)庫(kù)容易接受的方式去寫SQL，這個(gè)成本會(huì)下降的非常快，這個(gè)是常規(guī)的MySQL慢的診斷思路。

如何檢查MySQL數(shù)據(jù)庫(kù)的主從延時(shí)？

MySQL數(shù)據(jù)庫(kù)主從延時(shí)如何去判斷呢？本文我們介紹了兩種判斷方法：1. Seconds_Behind_Master vs 2. mk-heartbeat，接下來我們就分別介紹這些內(nèi)容。 日常工作中，對(duì)于MySQL主從復(fù)制檢查，一方面我們要保證復(fù)制的整體結(jié)構(gòu)是否正常，另一方面需要檢查主從數(shù)據(jù)是否保持一致。對(duì)于前者我們可以通過監(jiān)控復(fù)制線程是否工作正常以及主從延時(shí)是否在容忍范圍內(nèi)，對(duì)于后者則可以通過分別校驗(yàn)主從表中數(shù)據(jù)的md5碼是否一致，來保證數(shù)據(jù)一致，可以使用Maatkit工具包中的mk-table- checksum工具去檢查。 方法1： 通過監(jiān)控show slave status\G命令輸出的Seconds_Behind_Master參數(shù)的值來判斷，是否有發(fā)生主從延時(shí)。其值有這么幾種： NULL — 表示io_thread或是sql_thread有任何一個(gè)發(fā)生故障，也就是該線程的Running狀態(tài)是No，而非Yes。 0 — 該值為零，是我們極為渴望看到的情況，表示主從復(fù)制良好，可以認(rèn)為lag不存在。 正值— 表示主從已經(jīng)出現(xiàn)延時(shí)，數(shù)字越大表示從庫(kù)落后主庫(kù)越多。 負(fù)值— 幾乎很少見，我只是聽一些資深的DBA說見過，其實(shí)，這是一個(gè)BUG值，該參數(shù)是不支持負(fù)值的，也就是不應(yīng)該出現(xiàn)。 show slave status\G，該命令的輸出結(jié)果非常豐厚，給我們的監(jiān)控提供了很多有意義的參數(shù)，比如：Slave_IO_Running該參數(shù)可作為 io_thread的監(jiān)控項(xiàng)，Yes表示io_thread的和主庫(kù)連接正常并能實(shí)施復(fù)制工作，No則說明與主庫(kù)通訊異常，多數(shù)情況是由主從間網(wǎng)絡(luò)引起的問題；Slave_SQL_Running該參數(shù)代表sql_thread是否正常，具體就是語句是否執(zhí)行通過，常會(huì)遇到主鍵重復(fù)或是某個(gè)表不存在。下面就說到今天的重點(diǎn)Seconds_Behind_Master，該值作為判斷主從延時(shí)的指標(biāo)，那么它又是怎么得到這個(gè)值的呢，同時(shí)，它為什么又受到很多人的質(zhì)疑？ Seconds_Behind_Master是通過比較sql_thread執(zhí)行的event的timestamp和 io_thread復(fù)制好的event的timestamp（簡(jiǎn)寫為ts）進(jìn)行比較，而得到的這么一個(gè)差值。我們都知道的relay-log和主庫(kù)的 bin-log里面的內(nèi)容完全一樣，在記錄sql語句的同時(shí)會(huì)被記錄上當(dāng)時(shí)的ts，所以比較參考的值來自于binlog，其實(shí)主從沒有必要與NTP進(jìn)行同步，也就是說無需保證主從時(shí)鐘的一致。 你也會(huì)發(fā)現(xiàn)，其實(shí)比較真正是發(fā)生在io_thread與sql_thread之間，而io_thread才真正與主庫(kù)有關(guān)聯(lián)，于是，問題就出來了，當(dāng)主庫(kù)I/O負(fù)載很大或是網(wǎng)絡(luò)阻塞，io_thread不能及時(shí)復(fù)制binlog（沒有中斷，也在復(fù)制），而 sql_thread一直都能跟上io_thread的腳本，這時(shí)Seconds_Behind_Master的值是0，也就是我們認(rèn)為的無延時(shí)，但是，實(shí)際上不是，你懂得。這也就是為什么大家要批判用這個(gè)參數(shù)來監(jiān)控?cái)?shù)據(jù)庫(kù)是否發(fā)生延時(shí)不準(zhǔn)的原因，但是這個(gè)值并不是總是不準(zhǔn)，如果當(dāng)io_thread與 master網(wǎng)絡(luò)很好的情況下，那么該值也是很有價(jià)值的。 之前，提到Seconds_Behind_Master這個(gè)參數(shù)會(huì)有負(fù)值出現(xiàn)，我們已經(jīng)知道該值是io_thread的最近跟新的ts與sql_thread執(zhí)行到的ts差值，前者始終是大于后者的，唯一的肯能就是某個(gè)event的ts發(fā)生了錯(cuò)誤，比之前的小了，那么當(dāng)這種情況發(fā)生時(shí)，負(fù)值出現(xiàn)就成為可能。 方法2： mk-heartbeat，Maatkit萬能工具包中的一個(gè)工具，被認(rèn)為可以準(zhǔn)確判斷復(fù)制延時(shí)的方法。 mk-heartbeat的實(shí)現(xiàn)也是借助timestmp的比較實(shí)現(xiàn)的，它首先需要保證主從服務(wù)器必須要保持一致，通過與相同的一個(gè)NTP server同步時(shí)鐘。它需要在主庫(kù)上創(chuàng)建一個(gè)heartbeat的表，里面至少有id與ts兩個(gè)字段，id為server_id，ts就是當(dāng)前的時(shí)間戳 now()，該結(jié)構(gòu)也會(huì)被復(fù)制到從庫(kù)上。 表建好以后，會(huì)在主庫(kù)上以后臺(tái)進(jìn)程的模式去執(zhí)行一行更新操作的命令，定期去向表中的插入數(shù)據(jù)，這個(gè)周期默認(rèn)為1 秒，同時(shí)從庫(kù)也會(huì)在后臺(tái)執(zhí)行一個(gè)監(jiān)控命令，與主庫(kù)保持一致的周期去比較，復(fù)制過來記錄的ts值與主庫(kù)上的同一條ts值，差值為0表示無延時(shí)，差值越大表示延時(shí)的秒數(shù)越多。 我們都知道復(fù)制是異步的ts不肯完全一致，所以該工具允許半秒的差距，在這之內(nèi)的差異都可忽略認(rèn)為無延時(shí)。這個(gè)工具就是通過實(shí)打?qū)嵉膹?fù)制，巧妙的借用timestamp來檢查延時(shí)，非常好用！ 關(guān)于檢查MySQL數(shù)據(jù)庫(kù)的主從延時(shí)的兩種方法就介紹到這里了，希望本次的介紹能夠?qū)δ兴斋@！