我正在嘗試調試的 PHP 應用程序在更大的 MySQL 數據庫上運行了幾個設計不當的查詢。有幾個頁面確實很慢,結果發現是因為一些查詢。我開始一一檢查每個查詢,雖然它們很慢,但它們本身并沒有那么慢。經過進一步調試后發現,只有當應用程序將它們作為準備好的語句運行時,它們才會變慢。如果我通過 MySQL 客戶端手動運行查詢,大約需要 300 毫秒。如果我通過 MySQL 客戶端運行創建一條準備好的語句并設置參數并運行它,大約需要 300 毫秒。如果我從 PHP (mysqli) 運行簡單查詢,大約需要 300 毫秒。如果我像應用程序一樣通過mysqli預準備語句運行它,則需要 100 秒。我想也許是這樣,mysqli所以我用PDO嘗試了一下,結果是一樣的。嘗試了不同的 PHP 版本(5.6、7.2、7.3)并得到相同的結果。所以我給了最后一次機會,寫了一個小的 Go 腳本來測試,我得到了相同的結果,并且事情得到了改進?,F在,如果我從 MySQL 客戶端或 MySQL Workbench 或 PHPStorms 數據庫客戶端運行查詢的準備語句版本,速度會很快。如果我從代碼中運行查詢,速度會非???。任何關于我應該照顧什么、我應該在哪里繼續調試的幫助將不勝感激。
1 回答

人到中年有點甜
TA貢獻1895條經驗 獲得超7個贊
事實證明,這是由略有不同的執行計劃引起的。MySQL似乎純粹根據語句創建執行計劃,不包括通過mysqli
or使用預備語句時的參數值PDO
,這是有道理的。然而,當它提供完整的查詢時,在我們的例子中,它引入了對其中一個表的優化,這產生了巨大的差異。
其中一個表(有 550 萬行)Using join buffer (Block Nested Loop)
在使用非準備語句運行時有 Extra,而使用準備語句則沒有。這似乎為我們帶來了近 1000 倍的性能差異。
我仍然不確定為什么這通過 PHPStorm 或 CLImysql
客戶端沒有問題,我最好的猜測是,MySQL 中的某些 API 期望在準備語句時執行計劃完成,而其他 API 和 CLI 客戶端則不這樣做't。
- 1 回答
- 0 關注
- 119 瀏覽
添加回答
舉報
0/150
提交
取消