大多數的業務場景下 PHP 還沒有達到性能瓶頸，然而 MySQL 資料庫就先行駕崩了。但我們總是不分青紅皂白，一股腦的把原因歸結於是 PHP 語言不行了，每當遇到這種情形我就會感嘆到 PHP 的命真苦啊。 ...
大家好，我是碼農先森。
大多數的業務場景下 PHP 還沒有達到性能瓶頸，然而 MySQL 資料庫就先行駕崩了。但我們總是不分青紅皂白，一股腦的把原因歸結於是 PHP 語言不行了，每當遇到這種情形我就會感嘆到 PHP 的命真苦啊。PHP 作為一門優秀的開源編程語言，在編程語言界一直享有「PHP是世界上最好的語言」的美譽，它讓 PHP 靚仔們養了家糊了口過上了小康生活，但一遇到點性能問題就被瘋狂的吐槽，它真是幹了件吃力不討好的活。當然我相信這種吐槽是少數的，絕大數的人都還是會秉承理性公正的眼光來看待 PHP 語言，在碰到問題時會仔細分析緣由，找到問題的癥結並解決它，讓 PHP 綻放屬於它自己的光芒。
還記得在之前的工作經歷中，使用 ThinkPHP 框架開發公司內部的 ERP 後臺系統，很多的情況都是資料庫拖慢了用戶的訪問速度，比如開發的一些財務數據報表，這些介面往往都會聚合了好幾張數據表的數據，左連接一張表右連接一張表，動不動還搞個全連接，這能不慢嘛。不僅如此，還有在一個介面里 SQL 語句的查詢都嵌套了好幾層，各種子查詢漫天飛，這樣的代碼現狀簡直慘不忍睹，數據量小的時候尚且能用不會影響用戶的體驗，當數據量上來時介面就經常搞超時，資料庫的慢日誌都打滿了。在我印象中有個最深刻的例子，就是有一個速賣通的產品編輯功能，一個頁面需要能同時編輯幾十個產品，這就是所謂的批量編輯，而且每個產品的詳情數據特別多，還包括很多的圖片，每次載入這些數據和圖片就半天了，這個功能使用人數最多、使用次數最頻繁，同時也是被吐槽的最多的。如果有開發過類似功能的朋友，可能會有比較深刻的感觸。
還有一種用腳本跑非同步任務的場景，由於有些報表用介面是真的搞不出來了，那就用腳本的方式定時計算。但當時由於我們的數據量比較大，都是上百萬千萬級別的，單進程跑數據太慢，為了提升效率就直接幹上了 PHP 多進程。那時我們還滿心歡喜的 Fork 著進程，一啟動腳本就是併發幾十個進程，結果現實情況就是給我們當頭一棒，阿裡雲 MySQL 資料庫監控系接連報警，登上雲控制台一看傻眼了，CPU 直接乾到 100% 滿載運行，搞的 ERP 後臺系統都無法正常訪問了。還被技術老大當頭呵斥你們搞什麼飛機，嚇得我們趕緊通過 Kill 命令把腳本進程強制殺掉。說到這裡可能有些朋友會有些疑惑了，為什麼非同步腳本會影響到 ERP 後臺系統呢？原因是大多數的 PHP 靚仔們都有直接線上上環境修改代碼的習慣，當然這種事情在我們這裡也不例外了哈哈，甚至有時都變成了常態，感覺就是怎麼方便怎麼來。所有的業務都是共用一個資料庫，這不就影響到 ERP 後臺系統了嘛。
通過談我之前的經歷，可以看出並不是 PHP 不行，而是因為沒有正確的使用好 PHP 而把資料庫搞垮了，單純的責怪 PHP 語言本身沒有任何意義。很多時候性能的瓶頸，往往都是先在資料庫層面出現，比如某些查詢沒有命中索引、子查詢嵌套層數過多、長事務造成死鎖、併發大量的操作造成負載過高等等。總而言之，在我的經歷中把 PHP 語言乾出性能瓶頸的場景還是占少數，誇張點可以說幾乎沒有哈哈，可能是我資歷尚淺，不過話又說回來，大家的經歷和我的應該也差不多。最後希望大家可以在資料庫層面多花一些功夫，而不是糾結於這門語言到底行不行了，如果資料庫都不行了，那麼換什麼語言都是白瞎，願這一點大家能有相應的共識。本次的分享內容就到這裡結束了，希望對大家能有所啟發。
感謝大家閱讀，個人觀點僅供參考，歡迎在評論區發表不同觀點。
歡迎關註、分享、點贊、收藏、在看，我是微信公眾號「碼農先森」作者。
