PHP訪問MySQL你用對了么？

美好生活谷 2019-04-11

展開全文

大家都知道，slow query系統(tǒng)做的好不好，直接決定了解決slow query問題的效率。一個數(shù)據(jù)庫管理平臺，擁有一個好的slow query系統(tǒng)，基本上就擁有了解鎖性能問題的鑰匙。但是今天主要分享的并不是平臺，而是在平臺中看到的奇葩指數(shù)五顆星的slow issue。

好了，關(guān)子賣完，直接進入正題。

癥狀

數(shù)據(jù)庫的慢SQL日志中發(fā)現(xiàn)了一堆如下慢查詢：

從我們的監(jiān)控圖上可以看到，每天不定時間段的slow query 總數(shù)在攀升，但是卻看不到任何query 語句，這是我接觸到的slow query優(yōu)化案例中從來沒有過的情況，比較好奇，也比較興奮，至此決心要好好看看這個問題。

排查

要解決這個問題，首先想到的是，如何復(fù)現(xiàn)這個問題，如何模擬復(fù)現(xiàn)這個癥狀。

MySQL客戶端模擬prepare

perl 模擬prepare

結(jié)論：跟MySQL客戶端一樣，同樣是看不到administrator command: Prepare

PHP 模擬 prepare

PHP 模擬得到的slow結(jié)果

結(jié)論：通過php代碼，我們成功模擬出了想要的結(jié)果

那順藤摸瓜，抓取下這段時間有相同session id的整個sql執(zhí)行過程。

MySQL開啟slow=0的抓包模式

結(jié)論：我們發(fā)現(xiàn)，prepare時間的確很長，但是sql語句卻執(zhí)行的很快，這就很尷尬了

本來是想通過抓包，看看是否能夠驗證我們的猜想： prepare的語句非常大，或者條件非常復(fù)雜，從而導(dǎo)致prepare在服務(wù)器端很慢，結(jié)果發(fā)現(xiàn)query語句也都非常簡單。那么既然如此，我們就找了業(yè)務(wù)方，將對應(yīng)業(yè)務(wù)的prepare方法一起看看，結(jié)果發(fā)現(xiàn)，業(yè)務(wù)使用的是php-pdo的方式，所以我們就又有了如下發(fā)現(xiàn)：

php-pdo 兩種prepare模式

1.本地prepare $dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES,true)；不會發(fā)送給MySQL Server

2.服務(wù)器端prepare $dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES,false；發(fā)送給MySQL Server

官網(wǎng)說明： http:///manual/zh/pdo.prepare.php

驗證兩種prepare模式

服務(wù)端prepare模式( ATTR_EMULATE_PREPARES = false)

strace -s200 -f php mysql1.php 跟蹤如下圖

這個模式下，prepare的時候是將query+占位符發(fā)送給服務(wù)端的。

本地prepare模式 (ATTR_EMULATE_PREPARES=true )

strace -s200 -f php mysql1.php 跟蹤如下圖

這個模式下，prepare的時候是不會將query發(fā)送給服務(wù)端的，只有execute的時候才會發(fā)送。跟業(yè)務(wù)方確認后，他們使用的是后者，也就是修改了默認值，他們原本是想提升數(shù)據(jù)庫的性能，因為預(yù)處理后只需要傳參數(shù)就好了，但是對于我們的業(yè)務(wù)場景并不適合，我們的場景是頻繁打開關(guān)閉連接，也就是預(yù)處理基本就用不到。

另外文檔上面也明確指出prepared statements 性能會不好。