本篇文章給大家?guī)?lái)了關(guān)于mysql的相關(guān)知識(shí)，其中主要介紹了關(guān)于索引大幅優(yōu)化某PHP應(yīng)用性能的相關(guān)內(nèi)容，下面一起來(lái)看一下，希望對(duì)大家有幫助。

起因

前兩個(gè)月某朋友要做一個(gè)項(xiàng)目，本著快速上線推廣的目的，直接購(gòu)買了某公司的源碼并讓賣家部署上線?？吹皆创a后，我直接對(duì)朋友說(shuō)：算是被小坑了，這個(gè)源碼質(zhì)量有點(diǎn)差，用戶數(shù)起來(lái)后可能會(huì)有比較嚴(yán)重的性能問(wèn)題。

做出這樣的評(píng)價(jià)，我是有依據(jù)的：

• 作為近乎實(shí)時(shí)應(yīng)用，核心代碼用PHP編寫，通過(guò)數(shù)據(jù)庫(kù)表記錄控制許多場(chǎng)景的并發(fā)和重復(fù)請(qǐng)求；

• PHP開發(fā)不是問(wèn)題，但對(duì)方工程師似乎不知道有CLI模式，而是通過(guò)計(jì)劃任務(wù)(crontab)達(dá)到程序不停運(yùn)轉(zhuǎn)，于是乎浩浩蕩蕩幾十條curl計(jì)劃任務(wù)每分鐘執(zhí)行；

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

• 存在不少for循環(huán)讀取數(shù)據(jù)庫(kù)的代碼，命名規(guī)則混亂。

當(dāng)然，能賺錢的代碼才是好代碼(對(duì)方就通過(guò)這些代碼賺錢了)，我也沒多去糾結(jié)。最初的想法是，4核8G的配置，跑1萬(wàn)個(gè)客戶應(yīng)該很難，跑5000就可以了。

轉(zhuǎn)折

就在這周，忽然頻繁接到 阿里云 的報(bào)警短信和郵件，說(shuō)CPU占用過(guò)高。心想市場(chǎng)推廣很順利，用戶大增嗎？一問(wèn)朋友，才不到300個(gè)用戶！

這時(shí)才意識(shí)到，這套代碼實(shí)際表現(xiàn)比我想想中的更差，有嚴(yán)重的性能問(wèn)題。按照這個(gè)資源消耗速度，升級(jí)硬件是無(wú)底洞，性能優(yōu)化才是正途。

性能優(yōu)化

拿到代碼兩個(gè)月了，閑暇時(shí)間偶爾會(huì)看一下，已經(jīng)大體知道其結(jié)構(gòu)和主要功能。現(xiàn)在出現(xiàn)了嚴(yán)重性能問(wèn)題，是時(shí)候嘗試做一些性能優(yōu)化了。

鑒于幾十個(gè)計(jì)劃任務(wù)不停運(yùn)行，其不斷驅(qū)動(dòng)系統(tǒng)運(yùn)轉(zhuǎn)，因此計(jì)劃任務(wù)的相關(guān)功能是最先被了解的。根據(jù)自己的理解，首先暫停了二十多個(gè)已經(jīng)不需要的計(jì)劃任務(wù)。暫停無(wú)用計(jì)劃任務(wù)后，系統(tǒng)總體CPU使用率下降到了60%多，煩人的提醒短信和郵件終于消停了。等待了一天，朋友也沒有反饋有功能受影響，說(shuō)明思路和出手點(diǎn)都正確。

但是200多個(gè)用戶就這么消耗資源，一定還有什么地方不對(duì)勁。今天有空又登錄服務(wù)器，執(zhí)行top命令，發(fā)現(xiàn)MySQL進(jìn)程一直占據(jù)200%多的CPU資源?？催^(guò)源碼的我知道MySQL占用高是有原因的并且是可能的，但還是想看看為什么這么耗資源。

登錄MySQL服務(wù)器，查看是否開啟了slow log：show variables like '%slow%';，發(fā)現(xiàn)開啟了慢查詢?nèi)罩荆?/p>

接著查看日志，查到某條sql語(yǔ)句一直出現(xiàn)在日志中：

可以看到，執(zhí)行這條sql語(yǔ)句掃描了38萬(wàn)多行記錄。語(yǔ)句涉及到的兩張表一張有600多條記錄，另一張4萬(wàn)多條記錄，相當(dāng)于全表掃描了4萬(wàn)多的表好幾次，怪不得特別慢。

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

接下來(lái)，在兩張表上分別就查詢條件的uid、session_id列上創(chuàng)建索引。索引創(chuàng)建完成后，肉眼可見的CPU占用率和系統(tǒng)負(fù)載都降下來(lái)了。再次使用explain執(zhí)行查詢語(yǔ)句，索引信息已經(jīng)用上了，掃描行數(shù)大大減少：

經(jīng)過(guò)上面的優(yōu)化，目前應(yīng)用的總體CPU占用率在5%左右，MySQL的CPU占用率大約為15%，系統(tǒng)負(fù)載從4降到了0.3。終于暫時(shí)不用擔(dān)心性能問(wèn)題了，即使服務(wù)器配置降到1核CPU也能撐得住。

進(jìn)一步查看代碼并結(jié)合日志，創(chuàng)建索引和修改部分查詢語(yǔ)句，CPU占用率降到6%左右，終于暫時(shí)不用擔(dān)心性能問(wèn)題了

總結(jié)

工程師在開發(fā)工程中，不僅要寫出“能用”的代碼，更要寫出“好用”的代碼。本例中通過(guò)創(chuàng)建兩個(gè)索引就能大幅提升系統(tǒng)性能，便是讓代碼從“能用”轉(zhuǎn)到“好用”。

本文提到的性能優(yōu)化偏運(yùn)維，代碼中的性能優(yōu)化暫時(shí)還未觸碰。但一個(gè)總體的原則是不會(huì)錯(cuò)的：多使用緩存，盡可能的減少慢IO設(shè)備的同步讀取。

推薦學(xué)習(xí)：《mysql視頻教程》、《PHP視頻教程》