[[242626]]

MySQL 慢怎么辦

如果遇到 MySQL 慢的話(huà)，你的***印象是什么，MySQL 數(shù)據(jù)庫(kù)如果性能不行，你是如何處理的？

我咨詢(xún)了一些同行, 得到了以下反饋：

• ***反應(yīng)是再試一次
• 第二個(gè)反應(yīng)是優(yōu)化一下 SQL
• 第三個(gè)反應(yīng)是調(diào)大 buffer pool，然后開(kāi)始換硬件了，換一下 SSD
• ***實(shí)在不行了找個(gè)搜索引擎搜索一下“MySQL 慢怎么辦”。

如果大家用的是國(guó)內(nèi)的搜索引擎的話(huà)，搜索引擎會(huì)推薦某某知道或者某某乎, 推薦一些 MySQL 調(diào)優(yōu)經(jīng)驗(yàn), 調(diào)大參數(shù) A, 調(diào)低參數(shù) B, 諸如此類(lèi)，類(lèi)似的網(wǎng)站能告訴你 MySQL 慢怎么辦。

我們來(lái)分析一下這些現(xiàn)象背后隱藏的意義：

• 如果再試一次能夠成功的話(huà), 意味著你可能碰到了不可復(fù)現(xiàn)的外界因素的影響，導(dǎo)致 MySQL 會(huì)慢。
• 如果優(yōu)化 SQL 能解決，就意味著 SQL 的執(zhí)行復(fù)雜度遠(yuǎn)遠(yuǎn)大于它的需求復(fù)雜度。
• 如果調(diào)大 buffer pool 能解決，就意味著 MySQL 碰到了自身的某些限制。
• 如果換 SSD 能解決，那么意味著服務(wù)器資源受到了一定的限制。
• 如果需要搜索引擎，意味著調(diào)優(yōu)這事已經(jīng)變成了玄學(xué)。

本文向大家分享我對(duì) MySQL 慢的診斷思路，以及向大家介紹系統(tǒng)觀(guān)測(cè)工具。

MySQL 慢的診斷思路

MySQL 慢的診斷思路，一般會(huì)從三個(gè)方向來(lái)做：

1. MySQL 內(nèi)部的觀(guān)測(cè)
2. 外部資源的觀(guān)測(cè)
3. 外部需求的改造

下面依次看一下這幾個(gè)思路。

MySQL 內(nèi)部觀(guān)測(cè)

常用的 MySQL 內(nèi)部觀(guān)測(cè)手段是這樣的：

• ***步是 Processlist，看一下哪個(gè) SQL 壓力不太正常；
• 第二步是 explain，解釋一下它的執(zhí)行計(jì)劃；
• 第三步要做 Profilling，如果這個(gè) SQL 能再執(zhí)行一次的話(huà), 就做一個(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ī)的 MySQL 內(nèi)部狀態(tài)觀(guān)測(cè)的思路。

外部資源觀(guān)測(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 1，告訴我們 CPU 壓力在各個(gè)核上是不是均勻的。
5. pidstat 1，告訴我們各個(gè)進(jìn)程的對(duì)資源的占用大概是什么樣子。
6. iostat-xz 1，查看 IO 的問(wèn)題。
7. free-m 內(nèi)存使用率；
8. sar-n DVE 1，
9. sar-n TCP, ETCP 1，8 和 9 兩條按設(shè)備網(wǎng)卡設(shè)備的維度，看一下網(wǎng)絡(luò)的消耗狀態(tài)，以及總體看 TCP 的使用率和錯(cuò)誤率是多少。
10. top，看一下大概的進(jìn)程和線(xiàn)程的問(wèn)題。

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

外部需求改造

第三個(gè)診斷思路是外部的需求改造，在這里引用了 MySQL 官方文檔中的一章，《Examples of Common Queries 》（ https://dev.mysql.com/doc/mysql-tutorial-excerpt/5.5/en/examples.html），文檔中介紹了常規(guī)的 SQL 怎么寫(xiě), 給出了一些例子。

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

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

關(guān)聯(lián)子查詢(xún)成本是很貴的，所以上面的文檔會(huì)教你快速地把它轉(zhuǎn)成一個(gè)非關(guān)聯(lián)子查詢(xún)，大家可以看到中間的子查詢(xún)和外邊的查詢(xún)之間是沒(méi)有關(guān)聯(lián)性的。

第三步，會(huì)教大家直接把子查詢(xún)拿掉，然后轉(zhuǎn)成這樣一個(gè) SQL，這個(gè)就叫業(yè)務(wù)改造，前后三個(gè) SQL 的成本都不一樣，把關(guān)聯(lián)子查詢(xún)拆掉的成本，拆掉以后 SQL 會(huì)跑得非常好，但這個(gè) SQL 已經(jīng)不能良好表義了，只有在診斷到 SQL 成本比較高的情況下才建議大家使用這種方式。

為什么它能夠把一個(gè)關(guān)聯(lián)子查詢(xú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)子查詢(xún)拆掉。

總結(jié)一下，對(duì)于 MySQL 慢的診斷思路如下：

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

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

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

下面重點(diǎn)介紹為大家介紹系統(tǒng)觀(guān)測(cè)工具。

系統(tǒng)觀(guān)測(cè)工具介紹

先從診斷思路的討論切換到系統(tǒng)的觀(guān)測(cè)工具，首先了解什么叫系統(tǒng)觀(guān)測(cè)工具并且看一下它的舉例，然后再回到診斷思路上，看看新的工具的引入能為我們的思路到底帶來(lái)怎樣的改變。

什么叫系統(tǒng)觀(guān)測(cè)工具

這里也參考了一篇外國(guó)人寫(xiě)的文檔：

https://jvns.ca/blog/2017/07/05/linux-tracing-systems/

把這個(gè)文檔拆開(kāi)，中間描述了三件事情：

系統(tǒng)觀(guān)測(cè)工具的數(shù)據(jù)源來(lái)自于哪里；

數(shù)據(jù)采集過(guò)程，因?yàn)椴杉氖窍到y(tǒng)的運(yùn)行狀況，所以到底如何采集這是一個(gè)難點(diǎn)；

應(yīng)該怎么看數(shù)據(jù)，是用圖來(lái)看，還是用表來(lái)看，它就叫數(shù)據(jù)處理前端。

***步，我們來(lái)看一下數(shù)據(jù)源，Linux 給我們提供的數(shù)據(jù)源包括操作系統(tǒng)內(nèi)核態(tài)提供的觀(guān)測(cè)點(diǎn)和用戶(hù)態(tài)提供的觀(guān)測(cè)點(diǎn)，MySQL 很早之前就提供了用戶(hù)態(tài)的觀(guān)測(cè)點(diǎn)。

第二步，如何把數(shù)據(jù)抽出來(lái)。以下這些工具中大家最熟悉的應(yīng)該是 perf 和 ftrace，sysdig 也有人在用，其它的可能有所耳聞，這是從操作系統(tǒng)里抽取數(shù)據(jù)的方法。

第三步，數(shù)據(jù)處理前端，前端常用的也是 perf 和 ftrace。如果大家對(duì) perf 很熟悉的話(huà)會(huì)知道 perf 出來(lái)的數(shù)據(jù)是一個(gè)樹(shù)形的數(shù)據(jù)，并可以跟這棵樹(shù)進(jìn)行交互，比如說(shuō): 查看某個(gè)函數(shù)運(yùn)行了多久，哪一個(gè)函數(shù)的時(shí)間最長(zhǎng)，這個(gè)是數(shù)據(jù)處理前端。

我們來(lái)對(duì)比一下常規(guī)的四類(lèi)系統(tǒng)觀(guān)測(cè)工具：ftrace, perf_events，eBPF 和 Systemtap，這四個(gè)工具到底有什么不同，看看 Linux 為什么提供這么多觀(guān)測(cè)工具。

ftrace：ftrace 是 sysfs 中的一個(gè)樁，通過(guò)這個(gè)樁內(nèi)核提供了一種觀(guān)測(cè)的形式——把想觀(guān)測(cè)的函數(shù)簽名打到這個(gè)樁里，然后操作系統(tǒng)就會(huì)提供這個(gè)函數(shù)運(yùn)行的狀況。ftrace 的結(jié)構(gòu)如左圖, 數(shù)據(jù)處理前端和采集端是 ftrace, 數(shù)據(jù)源是下面這一堆。

perf：常用的 perf 的原理是操作系統(tǒng)提供了一個(gè)系統(tǒng)調(diào)用可以將數(shù)據(jù)寫(xiě)到一個(gè)緩存中, 然后客戶(hù)端把這些數(shù)據(jù)端抽取出來(lái)然后呈現(xiàn)在顯示器上。

eBPF：這是本文想重點(diǎn)推薦的。以上兩種方案一種是操作系統(tǒng)提供的文件系統(tǒng)上的樁，一種是操作系統(tǒng)提供的系統(tǒng)調(diào)用，而 eBPF 是將一段代碼直接插到操作系統(tǒng)內(nèi)核某一個(gè)位置上的機(jī)制。

Systemtap：它的原理是將一段 C 的代碼編譯成一個(gè)內(nèi)核模塊，然后將這個(gè)模塊嵌到內(nèi)核里邊去，它不是由內(nèi)核提供的一個(gè)機(jī)制，而是由內(nèi)核的模塊機(jī)制提供的一種功能。

介紹了這四種觀(guān)測(cè)工具的不同，大家在選取觀(guān)測(cè)工具的時(shí)候就知道應(yīng)該怎么選。

這四種觀(guān)測(cè)工具對(duì)系統(tǒng)傷害最輕的是誰(shuí)？

對(duì)系統(tǒng)傷害最輕的是系統(tǒng)調(diào)用，這是系統(tǒng)承諾出來(lái)的服務(wù)。然后是 ftrace，這是系統(tǒng)在文件系統(tǒng)層面提供的一個(gè)口，告訴你可以通過(guò)這個(gè)口跟系統(tǒng)交互。

對(duì)系統(tǒng)侵入性***的是誰(shuí)？

對(duì)系統(tǒng)侵入性***的應(yīng)該是 eBPF，因?yàn)樗苯訉⒁桓a嵌入到系統(tǒng)里邊去做，最不穩(wěn)定的應(yīng)該是 System Tap，因?yàn)樗窍到y(tǒng)的一個(gè)模塊, 又提供了非常復(fù)雜的功能。

上圖是 eBPF 的架構(gòu)圖，eBPF 先將一段程序編譯成二進(jìn)制代碼，然后插入到操作系統(tǒng)里，操作系統(tǒng)運(yùn)行這段代碼的時(shí)候，將采集到的數(shù)據(jù)吐到操作系統(tǒng)本身的空間里，然后再做統(tǒng)一返回。

eBPF 結(jié)構(gòu)最核心的部分在于把代碼插入到操作系統(tǒng)中運(yùn)行，它需要做各種安全保護(hù)才能完成這一點(diǎn)，所以這也是這個(gè)機(jī)制復(fù)雜的地方。

下面引用一個(gè)開(kāi)源的 eBPF 腳本集 bcc, 快速看一下 eBPF 能做什么, 這些功能都是開(kāi)箱即用的。

bcc (eBPF 腳本集) 使用舉例

MySQL 的請(qǐng)求延遲分析：

一個(gè) MySQL 承擔(dān)了很多業(yè)務(wù)，上千個(gè)并發(fā)˙中，哪一個(gè) SQL 最慢，到底有哪些 SQL 在一秒以上，除了 slow log 以外，還可以用這種方法來(lái)看。

這個(gè)命令的結(jié)果分為三列，它的***列是請(qǐng)求的延遲，指數(shù)級(jí)遞增，單位是微秒，中間一列是它的***數(shù)，如果有一個(gè)請(qǐng)求***了 64-127 微秒這個(gè)區(qū)間，***數(shù)會(huì)加一，***一列是它的分布圖，它在同一個(gè)報(bào)告里提供了數(shù)值的方式和圖的方式，可以很容易看到結(jié)果。

對(duì)于這臺(tái)服務(wù)器來(lái)說(shuō)，我下了一個(gè) select 的性能壓力，它大部分的請(qǐng)求集中于 64 到 127 微秒之間。這個(gè)數(shù)據(jù)庫(kù)的性能可能還不錯(cuò)。

再來(lái)看另外一種壓力，我下了一個(gè) select+insert 的混合壓力在一個(gè)數(shù)據(jù)庫(kù)里，它的圖又變了，它呈現(xiàn)了一個(gè)非常好的雙峰圖，我將兩個(gè)峰值用另外一種顏色標(biāo)明，這兩個(gè)峰值的意思是很有可能有混合壓力在一個(gè)數(shù)據(jù)庫(kù)里，或者是上面的這部分壓力是***了某些緩存，而下面的某些壓力是由于沒(méi)有***緩存，導(dǎo)致這部分請(qǐng)求更慢一些, 形成另一個(gè)峰值，所以通過(guò)這種峰值分析可以看到數(shù)據(jù)庫(kù)大概的一個(gè)運(yùn)行狀態(tài)。

如果能做得更好，你可以抽檢自己的數(shù)據(jù)庫(kù)然后做環(huán)比圖，比如今天和昨天同樣的時(shí)間，同樣的業(yè)務(wù)壓力下對(duì)數(shù)據(jù)庫(kù)的延遲進(jìn)行分析，如果數(shù)據(jù)庫(kù)的延遲峰一直在往后延，就意味著數(shù)據(jù)庫(kù)的狀態(tài)在變得更糟糕一些。這是 bcc ***個(gè)能做的事情，需要再次強(qiáng)調(diào)的是它開(kāi)箱即用直接下載過(guò)來(lái)就可以使用。

MySQL 的慢查詢(xún)：

MySQL 本身提供很好的慢查詢(xún)，為什么還要用另外一個(gè)機(jī)制來(lái)獲取 MySQL 的慢查詢(xún)呢？

MySQL 的慢查詢(xún)可能很難做，與 MySQL 的慢日志相比, 它可以低成本地完成:

• 獲取少量慢查詢(xún)
• 獲取某種模式的慢查詢(xún)
• 獲取某個(gè)用戶(hù)的慢查詢(xún)

比如說(shuō)獲取少量的慢查詢(xún)，為什么是少量呢？因?yàn)椴淮_定現(xiàn)在的線(xiàn)上延遲是多少，慢查詢(xún)只開(kāi)一秒可能日志瞬間就被堆上去，性能就會(huì)下來(lái)，但是如果慢查詢(xún)開(kāi)個(gè)十秒左右，沒(méi)有請(qǐng)求在這個(gè)區(qū)間***，所以要一點(diǎn)一點(diǎn)的去調(diào)這個(gè)值，比如說(shuō)線(xiàn)上 1% 的最慢的查詢(xún)能夠***，但是在這個(gè)腳本里面，可以取一定區(qū)間的***的幾個(gè)查詢(xún)把它拎出來(lái)。

通過(guò)腳本還可以***某種模式的慢查詢(xún), 比如說(shuō)我們只關(guān)心 update 的慢查詢(xún), 那么獲取 select 的結(jié)果就沒(méi)有太大的意義，或者是我一定要獲取某一些特定表的相關(guān)的查詢(xún)，我都可以通過(guò)腳本來(lái)做。

第三種情況，想獲取某個(gè)用戶(hù)的慢查詢(xún)，這個(gè)一般對(duì)于多租戶(hù)系統(tǒng)，因?yàn)槎嘧鈶?hù)系統(tǒng)只想針對(duì)某一個(gè)用戶(hù)進(jìn)行慢查詢(xún)分析的時(shí)候，這種腳本就比較好用。

VFS 延遲分析：

對(duì) VFS 做延遲分析，這是對(duì)數(shù)據(jù)庫(kù)進(jìn)行了一個(gè)寫(xiě)壓力，可以明顯看到一個(gè)雙峰圖，這是寫(xiě)的兩個(gè)峰，是數(shù)據(jù)庫(kù)對(duì)于內(nèi)核的寫(xiě)壓力的反饋。

這個(gè)意味著什么呢？這個(gè)可能意味著因?yàn)檫@部分的寫(xiě)是***了操作系統(tǒng)文件系統(tǒng)的緩存，而下面這部分寫(xiě)是真正的寫(xiě)穿到設(shè)備的，所以他們倆的延遲不一樣，這是一個(gè)典型的雙峰圖，大家需要把兩個(gè)峰拆開(kāi)來(lái)去行這樣的分析。

換一個(gè)說(shuō)法，如果寫(xiě)壓力都集中在這里，而沒(méi)有第二個(gè)峰的情況下，需不需要去更換物理設(shè)備？有可能不需要，因?yàn)樗械臇|西都***了操作系統(tǒng)的緩存。

短生命周期的臨時(shí)文件檢測(cè)：

這個(gè)不一定常見(jiàn)，MySQL 會(huì)在某些情況下動(dòng)用臨時(shí)表, 如果 SQL 沒(méi)寫(xiě)好就會(huì)創(chuàng)建臨時(shí)表，這些臨時(shí)表的生命周期很短，但是量很大，所以一定要寫(xiě)文件而不能內(nèi)存里。

在這種情況下會(huì)對(duì)操作系統(tǒng)造成一些壓力，而這個(gè)壓力又不太好診斷，因?yàn)榕R時(shí)文件的生存周期短，所以這個(gè)腳本可以幫大家提供一個(gè)方案，這個(gè)方案的結(jié)果是這樣子。

我做了一個(gè)臨時(shí)表，這個(gè)臨時(shí)表活了 5.3 秒左右，于是它展現(xiàn)在了腳本的結(jié)果里。如果掃描自己的線(xiàn)上 MySQL 發(fā)現(xiàn)這里有大量的東西說(shuō)明在大量的使用臨時(shí)表，如果 IO 壓力在此時(shí)比較大, 就可能受了臨時(shí)表的影響。

短連接分析：

好一點(diǎn)的應(yīng)用都會(huì)用連接池，但是我們很多的時(shí)候沒(méi)有那么好的運(yùn)氣，老碰到那么好的應(yīng)用，所以經(jīng)常業(yè)務(wù)會(huì)扔過(guò)來(lái)大量的短連接。

這個(gè)例子中, sysbench 上了一個(gè)大并發(fā)，但是只活了 300 多毫秒，這些連接都只活了 300 多毫秒，反復(fù)運(yùn)行這個(gè) sysbench 就可以將數(shù)據(jù)庫(kù)打死，建立一千個(gè)連接，300 毫秒以后也會(huì)銷(xiāo)毀，再建立一千個(gè)連接，你的業(yè)務(wù)就會(huì)忽上忽下，通過(guò)這個(gè)腳本就可以抓到這個(gè)壓力從哪個(gè)服務(wù)器來(lái)的，哪個(gè)端口來(lái)的，然后把它搞定就可以了。

長(zhǎng)連接分析：

除了短連接分析，還有長(zhǎng)連接分析，哪一個(gè)業(yè)務(wù)端老在搞我的數(shù)據(jù)，老在往里寫(xiě)，總在往里讀，搞的網(wǎng)絡(luò)特別慢。

可以幫大家提供這樣一個(gè)視角，它有讀有寫(xiě)。

以上幾個(gè) bcc 相關(guān)的例子都是現(xiàn)成的腳本。bcc 可以觀(guān)測(cè)操作系統(tǒng)的各個(gè)方面，比如說(shuō)如果有東西被 OOM kill 掉了，內(nèi)存有泄露的也可以看，它基本上是我們這幾年發(fā)現(xiàn)的一個(gè)寶庫(kù)，大家直接調(diào)用這些腳本就可以完成很多的別人完成不了的分析，它的技術(shù)用的是 eBPF，直接在 github 上直接搜就行了。

eBPF 使用方法 / 限制

如果這里邊腳本滿(mǎn)足不了要求, 那可以自己寫(xiě)。這里介紹一下腳本的寫(xiě)法以及 eBPF 的限制。

拿上面提到過(guò)的 MySQL 延遲分析舉例，一個(gè) MySQL 上面有一千個(gè) query，這些 query 大概都落在哪個(gè)延遲時(shí)間里面那張圖，為了完成這個(gè)需求, 我需要寫(xiě)兩段程序，其中***段程序是運(yùn)行在內(nèi)核里邊的程序。

這段程序的邏輯是這樣的：

• 在 query 開(kāi)始的時(shí)候截獲一下，讓它記錄一個(gè)時(shí)間戳；
• 請(qǐng)求結(jié)束的時(shí)候再截獲一下記錄一個(gè)時(shí)間戳；
• 把兩個(gè)時(shí)間戳相減獲得一個(gè)延遲；
• 把這個(gè)延遲扔到結(jié)果集里邊去，程序就完成了。

我用結(jié)束時(shí)間減開(kāi)始時(shí)間，減一下得到一個(gè)延遲，然后把延遲扔到一個(gè)統(tǒng)計(jì)容器里面，這個(gè)事就結(jié)束了。這是我要寫(xiě)的***個(gè)程序，是嵌到內(nèi)核里的程序，但是需要一個(gè)外殼的程序負(fù)責(zé)嵌入。

這個(gè)外殼程序的邏輯也非常簡(jiǎn)單，把剛才那段內(nèi)核的程序嵌到 MySQL 的觀(guān)測(cè)點(diǎn)上，嵌到內(nèi)核里面去，然后把結(jié)果集拿出來(lái)，打印出來(lái)就結(jié)束了，這是如何寫(xiě)一個(gè) eBPF 的腳本，大家唯一需要做的事情就是這兩個(gè)程序，然后運(yùn)行一下。

這個(gè)程序的核心只有 45 行，中間忽略了負(fù)責(zé)差錯(cuò)處理的一部分。只需要把現(xiàn)在的腳本拿下來(lái)抄一抄，改一改就可以完成很多的功能了。

這么好的方法為什么很多人不知道呢？

• 操作系統(tǒng)內(nèi)核的限制，這個(gè)功能是 Linux 4.4 引進(jìn)來(lái)的，但是在 Linux 4.4 上存在統(tǒng)計(jì)的 bug，我們推薦的是 Linux 4.9+，部分好用的功能是在 4.13+ 上才開(kāi)放，這個(gè)是 eBPF ***的限制。怎么辦呢？只能祝大家長(zhǎng)壽吧！活到 Linux 4.x 內(nèi)核能在生產(chǎn)環(huán)境上使用的那一天。
• 它的第二個(gè)***的限制是 MySQL 的編譯參數(shù)，MySQL 雖然在很早的時(shí)候已經(jīng)提供了 dtrace 的觀(guān)測(cè)點(diǎn)，這些觀(guān)測(cè)點(diǎn)是公用的，但是它在默認(rèn)的編譯出來(lái)的官方發(fā)布的包里邊是不帶觀(guān)測(cè)點(diǎn)編譯的，所以在直接官方發(fā)布的二進(jìn)制的包里邊是用不了這個(gè)功能的，大家需要自己編譯一下。編譯的時(shí)候需要帶這個(gè)參數(shù)，這個(gè)可能也是屬于一個(gè)比較大的限制。

所以如果大家受到限制，再推薦換一個(gè)工具：systemtap。

Linux 2.6 就已經(jīng)有了，但是它的機(jī)制是寫(xiě)一個(gè)內(nèi)核模塊，這種機(jī)制其實(shí)不是特別穩(wěn)定，它為了解決不是特別穩(wěn)定的問(wèn)題增加了若干限制，比如說(shuō)能在內(nèi)核中使用的內(nèi)存大小有限制，采集頻率也有限制，對(duì)整個(gè)內(nèi)核性能的影響百分比也有限制，在這些限制參數(shù)都開(kāi)起來(lái)的情況下，它還是比較安全的。

但是很多觀(guān)測(cè)功能就必須要把這些限制關(guān)掉，一旦關(guān)掉內(nèi)核就不是很穩(wěn)定，所以這個(gè)工具，我沒(méi)有敢把它的缺點(diǎn)寫(xiě)在上面因?yàn)榇_實(shí)是個(gè)好的工具，我們也很難說(shuō)它的這個(gè)缺點(diǎn)是個(gè)致命的缺陷，但是不太推薦在生產(chǎn)環(huán)境上使用，但是在測(cè)試環(huán)境上確實(shí)是非常好玩的一個(gè)工具，如果大家用不了 eBPF 的話(huà)可以用 systemtap 來(lái)做一些診斷。

還有很多其他的工具：

至于如何選擇，大家直接谷歌一下有專(zhuān)門(mén)的文章教大家怎么選擇這些觀(guān)測(cè)工具。但是總的來(lái)說(shuō)沒(méi)有一個(gè)科學(xué)的思路，只有嘗試，不停的嘗試。

黃炎，愛(ài)可生研發(fā)總監(jiān)，深入鉆研分布式數(shù)據(jù)庫(kù)相關(guān)技術(shù)，擅長(zhǎng)業(yè)界相關(guān) MySQL 中間件產(chǎn)品和開(kāi)發(fā)，以及分布式中間件在企業(yè)內(nèi)部的應(yīng)用實(shí)踐。