| mysql 優(yōu)化心得一點點 2007-03-20 23:23:26 最近網(wǎng)站數(shù)據(jù)量節(jié)節(jié)攀升，據(jù)BD方面通報短期內(nèi)UV還要上升30%-50%。當(dāng)前最突出的問題是后臺內(nèi)容審核系統(tǒng)壓力太大，已經(jīng)逐漸力不從心。盡管加了一些硬件但效果并不是太理想，主要還是前一段時間把工作重點都放在前端模塊上了。內(nèi)容管理平臺的部分代碼沒有仔細(xì)斟酌。接下來一段時間集中精力優(yōu)化后臺。 首先將多表連查的SQL拿出來，拆分成單表查詢。將查詢出來的數(shù)據(jù)返回到頁面上再用ajax得到附表中的數(shù)據(jù)。這樣雖然增加了請求次數(shù)，但數(shù)據(jù)庫的slow query不見了。 使用 EXPLAIN 命令逐條檢查SQL語句。發(fā)現(xiàn)了很多 using sortfile 。說明這些地方是需要重點優(yōu)化的。檢查where 條件后面的字段，建立聯(lián)合索引。使用 use index(`index_name`) 告訴mysql使用哪個索引進(jìn)行檢索 order by / group by 子句是產(chǎn)生slow query 的多發(fā)區(qū)。一定要檢查 排序字段是否建立了索引，并且要使用 use index(`index_name`) 強(qiáng)制使用這個索引。 終于達(dá)到了理想的效果。以前一個分頁查詢要執(zhí)行8秒，現(xiàn)在不到0.1秒。但是mysql中文關(guān)鍵字查詢一直是優(yōu)化工作的最后絆腳石。 后臺內(nèi)容審核工作比較特殊，他要求數(shù)據(jù)不能緩存，檢索條件較多，并且需要精準(zhǔn)匹配，因此使用Lucene作后臺檢索是早就被否定的方案。而mysql官方版本又不支持 中文全文檢索（主要是沒有解決中文分詞問題）。一旦碰到標(biāo)題或內(nèi)容關(guān)鍵字檢索就要使用like ‘%xxxx%‘ ，這種方式數(shù)據(jù)量小的時候還可以接受，但上了幾十萬數(shù)據(jù)后就明顯體力不支了。 最后確定了兩套可行的方案待選。 1、在需要中文關(guān)鍵字詞檢索的表中，根據(jù)要檢索的字段再增加一個字詞拆分字段并在這個字段上建立 FULLTEXT 類型索引。在數(shù)據(jù)寫入的時候，使用一個分詞算法將內(nèi)容拆分成詞并用空格分開，存入新增的拆分字段。檢索的時候 使用 match against 對這個FULLTEXT做全文檢索。 2、使用海量科技研發(fā)的mysql chinese plus 。實際上這個東東是在海量中文分詞技術(shù)的基礎(chǔ)上為mysql增加了中文字詞的全文檢索。試用版效果很不錯。很適合做后臺中文檢索工作。但是價格也不低。 總結(jié)如下： 1、要把建立索引當(dāng)成一種習(xí)慣。 2、善用EXPLAIN命令 分析SQL語句， 檢查我們建立的索引是否命中，Extro列中是否還存在 "using sortfile" 如果有的話一定要通過調(diào)整索引或修改SQL甚至修改邏輯等方法把他消滅。否則隨著數(shù)據(jù)量攀升mysql早晚會趴下。 3、要評估某字段取值在所有記錄中的數(shù)量。比如一個字段A 類型為ENUM(‘yes‘,‘no‘)，表中的100萬條記錄有99萬條記錄 A的值為‘yes‘，那么當(dāng)查詢條件為A=‘yes‘ 時，查詢效率主要取決于ORDER BY 子句后面的字段索引。反之，如果查詢條件A=‘no‘時，查詢效率主要取決于 字段本身的索引。因此在使用 USE INDEX 是要充分考慮這個問題 4、選擇合適的中文全文檢索策略，能不用like就不要用Like。 |
|
|
