首先為了防止某些專業(yè)挑刺人士無限制發(fā)揮，先聲明幾個前提

1：索引優(yōu)化是基礎(chǔ)工作，沒做好這個其他的不用提，但本文不展開此內(nèi)容。

2：優(yōu)化數(shù)據(jù)庫查詢有非常多的分支，減少SQL請求只是其中一個領(lǐng)域，其他分支本文不涉及。

3：在部分場景下，甚至需要增加SQL以解決諸如分布式或其他問題，本文不涉及。

4：運維優(yōu)化和其他優(yōu)化手段本文不涉及。

5：產(chǎn)品業(yè)務(wù)邏輯優(yōu)化本文不涉及。

6：其他本文沒提到的內(nèi)容歡迎自行聯(lián)想，技術(shù)水準高超者請忽略本文。

*** 查詢請求的分析和裁剪

線上系統(tǒng)，出現(xiàn)請求較多，數(shù)據(jù)壓力較大（索引優(yōu)化到位的前提下），我會讓程序員輸出一段時間的查詢請求。（通常數(shù)據(jù)庫操作有封裝對象，直接記錄日志即可，建議寫入/dev/shm 以減少i/o壓力，如果請求頻次實在很高，可以取一定比例寫入日志），然后基于日志分析。

1、完全一致的查詢請求有多少，平均每秒會出現(xiàn)多少這樣的查詢。

比如常見的，所有頁面都加載系統(tǒng)信息 select * from systeminfo;

2、基于同一數(shù)據(jù)表同一主鍵的查詢有多少，平均每秒會出現(xiàn)多少這樣的查詢

比如 select name from userinfo where uid=10134;  select email from userinfo where uid=10134;

這兩種請求，是可以通過建立緩存機制來優(yōu)化的，

而且做了這個分析，會有一個很好的數(shù)據(jù)認知

當(dāng)前數(shù)據(jù)庫每秒處理多少查詢請求，其中可優(yōu)化的冗余請求有多少，如果建立緩存可以減少多少請求。提升系統(tǒng)支撐性多少？

對于一些不是特別出色的開源系統(tǒng)，分析一下會發(fā)現(xiàn)，可裁剪的查詢請求是非常巨大的。

第二 更新請求的分析和裁剪

更新請求也可以優(yōu)化，

我們一般用mysql的情況下，是先解開binlog文件，還原為文本文件，然后分析

基于同一數(shù)據(jù)表，同一主鍵的更新請求有多少，平均每個時間段出現(xiàn)多少這樣的請求

舉例1：

update user set lastacttime=.... where uid=10314; 經(jīng)常更新***活躍時間

舉例2：

update posts set views=views+1 where pid=10004211; 更新同一個帖子顯示數(shù)字

如果這樣的請求較多，那么可以有針對性的建立隊列，定時異步更新。

在異步更新過程中

范例1 多條請求只要記住同一主鍵***一條即可；

范例2 多條請求可以在程序中合并，對數(shù)據(jù)庫操作只進行一次。

這樣更新請求頻次就極大下降了。

如果線上有實時性要求，線上可以保持一個內(nèi)存數(shù)據(jù)做同步更新。

方法其實很簡單，但是很有效

簡單總結(jié)

***，要隨時了解自己的讀寫請求頻次情況

第二，一定時間范圍內(nèi)針對同數(shù)據(jù)表，同主鍵的讀寫請求，均是可優(yōu)化，可裁剪的，但是也要考慮當(dāng)時的系統(tǒng)負載構(gòu)成和請求頻次、影響度，抓大放小，解決主要問題即可。

就這樣，其他方面，參見前提說明。

原文鏈接：http://hi.baidu.com/ncaoz/item/600fd0daecef622939f6f7ca

【編輯推薦】