本篇文章給大家帶來了關于mysql的相關知識，其中主要介紹了關于索引大幅優化某PHP應用性能的相關內容，下面一起來看一下，希望對大家有幫助。

起因

前兩個月某朋友要做一個項目，本著快速上線推廣的目的，直接購買了某公司的源碼并讓賣家部署上線。看到源碼后，我直接對朋友說：算是被小坑了，這個源碼質量有點差，用戶數起來后可能會有比較嚴重的性能問題。

做出這樣的評價，我是有依據的：

• 作為近乎實時應用，核心代碼用PHP編寫，通過數據庫表記錄控制許多場景的并發和重復請求；

• PHP開發不是問題，但對方工程師似乎不知道有CLI模式，而是通過計劃任務(crontab)達到程序不停運轉，于是乎浩浩蕩蕩幾十條curl計劃任務每分鐘執行；

• 代碼中有不少 class1.php， class1-1.php這樣復制備份的文件，一眼看過去很難知曉其存在目的；

• 存在不少for循環讀取數據庫的代碼，命名規則混亂。

當然，能賺錢的代碼才是好代碼(對方就通過這些代碼賺錢了)，我也沒多去糾結。最初的想法是，4核8G的配置，跑1萬個客戶應該很難，跑5000就可以了。

轉折

就在這周，忽然頻繁接到 阿里云 的報警短信和郵件，說CPU占用過高。心想市場推廣很順利，用戶大增嗎？一問朋友，才不到300個用戶！

這時才意識到，這套代碼實際表現比我想想中的更差，有嚴重的性能問題。按照這個資源消耗速度，升級硬件是無底洞，性能優化才是正途。

性能優化

拿到代碼兩個月了，閑暇時間偶爾會看一下，已經大體知道其結構和主要功能。現在出現了嚴重性能問題，是時候嘗試做一些性能優化了。

鑒于幾十個計劃任務不停運行，其不斷驅動系統運轉，因此計劃任務的相關功能是最先被了解的。根據自己的理解，首先暫停了二十多個已經不需要的計劃任務。暫停無用計劃任務后，系統總體CPU使用率下降到了60%多，煩人的提醒短信和郵件終于消停了。等待了一天，朋友也沒有反饋有功能受影響，說明思路和出手點都正確。

但是200多個用戶就這么消耗資源，一定還有什么地方不對勁。今天有空又登錄服務器，執行top命令，發現MySQL進程一直占據200%多的CPU資源。看過源碼的我知道MySQL占用高是有原因的并且是可能的，但還是想看看為什么這么耗資源。

登錄MySQL服務器，查看是否開啟了slow log：show variables like '%slow%';，發現開啟了慢查詢日志：

接著查看日志，查到某條sql語句一直出現在日志中：

可以看到，執行這條sql語句掃描了38萬多行記錄。語句涉及到的兩張表一張有600多條記錄，另一張4萬多條記錄，相當于全表掃描了4萬多的表好幾次，怪不得特別慢。

接著檢查兩張表的索引，除了自增id作為主鍵外，沒有創建其他索引。使用explain執行語句，顯示沒有使用任何索引：

接下來，在兩張表上分別就查詢條件的uid、session_id列上創建索引。索引創建完成后，肉眼可見的CPU占用率和系統負載都降下來了。再次使用explain執行查詢語句，索引信息已經用上了，掃描行數大大減少：

經過上面的優化，目前應用的總體CPU占用率在5%左右，MySQL的CPU占用率大約為15%，系統負載從4降到了0.3。終于暫時不用擔心性能問題了，即使服務器配置降到1核CPU也能撐得住。

進一步查看代碼并結合日志，創建索引和修改部分查詢語句，CPU占用率降到6%左右，終于暫時不用擔心性能問題了

總結

工程師在開發工程中，不僅要寫出“能用”的代碼，更要寫出“好用”的代碼。本例中通過創建兩個索引就能大幅提升系統性能，便是讓代碼從“能用”轉到“好用”。

本文提到的性能優化偏運維，代碼中的性能優化暫時還未觸碰。但一個總體的原則是不會錯的：多使用緩存，盡可能的減少慢IO設備的同步讀取。

推薦學習：《mysql視頻教程》、《PHP視頻教程》