前言
大家都知道，slow query系統做的好不好，直接決定了解決slow query問題的效率。 一個數據庫管理平臺，擁有一個好的slow query系統，基本上就擁有了解鎖性能問題的鑰匙。但是今天主要分享的並不是平臺，而是在平臺中看到的奇葩指數五顆星的slow issue。
好了，關子賣完，直接進入正題。
症狀
數據庫的慢SQL日誌中發現了一堆如下慢查詢：
從我們的監控圖上可以看到，每天不定時間段的slow query 總數在攀升，但是卻看不到任何query 語句，這是我接觸到的slow query優化案例中從來沒有過的情況，比較好奇，也比較興奮，至此決心要好好看看這個問題。
排查
要解決這個問題，首先想到的是，如何復現這個問題，如何模擬復現這個症狀。
- MySQL客戶端模擬prepare
- perl 模擬prepare
結論：跟MySQL客戶端一樣，同樣是看不到administrator command: Prepare
- PHP 模擬 prepare
- PHP 模擬得到的slow結果
結論： 通過php代碼，我們成功模擬出了想要的結果
那順藤摸瓜，抓取下這段時間有相同session id的整個sql執行過程。
- MySQL開啟slow=0的抓包模式
結論：我們發現，prepare時間的確很長，但是sql語句卻執行的很快，這就很尷尬了
本來是想通過抓包，看看是否能夠驗證我們的猜想： prepare的語句非常大，或者條件非常複雜，從而導致prepare在服務器端很慢，結果發現query語句也都非常簡單。那麼既然如此，我們就找了業務方，將對應業務的prepare方法一起看看，結果發現，業務使用的是php-pdo的方式，所以我們就又有了如下發現：
- php-pdo 兩種prepare模式
1.本地prepare $dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES,true)；不會發送給MySQL Server
2.服務器端prepare $dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES,false；發送給MySQL Server
官網說明： http://php.net/manual/zh/pdo.prepare.php
- 驗證兩種prepare模式
服務端prepare模式( ATTR_EMULATE_PREPARES = false)
strace -s200 -f php mysql1.php 跟蹤如下圖
這個模式下，prepare的時候是將query+佔位符發送給服務端的。
本地prepare模式 (ATTR_EMULATE_PREPARES=true )
strace -s200 -f php mysql1.php 跟蹤如下圖
這個模式下，prepare的時候是不會將query發送給服務端的，只有execute的時候才會發送。跟業務方確認後，他們使用的是後者，也就是修改了默認值，他們原本是想提升數據庫的性能，因為預處理後只需要傳參數就好了，但是對於我們的業務場景並不適合，我們的場景是頻繁打開關閉連接，也就是預處理基本就用不到。
另外文檔上面也明確指出prepared statements 性能會不好。
調整和驗證
如何驗證業務方是否將prepare修改為local了呢？
通過觀察，發現這個值沒有變化，說明調整已經生效。
總結
- prepare的優點
1. 防止SQL注入
2. 特定場景下提升性能
什麼是特定場景： 就是先去服務端用佔位符佔位，後面可以直接發送請求來填空（參數值）。這樣理論上來說， 你填空的次數非常多，性能才能發揮出來。
- prepare的缺點
1. 在服務器端的prepare畢竟有消耗，當併發量大，頻繁prepare的時候，就會有性能問題。
2. 服務端的prepare模式還會帶來的另外一個問題就是，排錯和slow 優化有困難，因為大部分情況下是看不到真實query的。
3. 儘量設置php-pdo為 $pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES,true) ，在本地prepare，不要給服務器造成額外壓力。
最後的建議
1. 默認情況下，應該使用php-pdo的默認配置，採用本地prepare的方式，這樣可以做到防SQL注入的效果，性能差不到哪裡去。
2. 除非真的是有上述說的特定場景，可以考慮配置成服務器prepare模式，前提是要做好測試。
歡迎大家關注“58架構師”微信公眾號，定期分享雲計算、AI、區塊鏈、大數據、搜索、推薦、存儲、中間件、移動、前端、運維等方面的前沿技術和實踐經驗。
閱讀更多 58架構師 的文章
