首先為了防止某些專業(yè)挑刺人士無限制發(fā)揮，先聲明幾個前提
1：索引優(yōu)化是基礎工作，沒做好這個其他的不用提，但本文不展開此內容。
2：優(yōu)化數據庫查詢有非常多的分支，減少SQL請求只是其中一個領域，其他分支本文不涉及。
3：在部分場景下，甚至需要增加SQL以解決諸如分布式或其他問題，本文不涉及。
4：運維優(yōu)化和其他優(yōu)化手段本文不涉及。
5：產品業(yè)務邏輯優(yōu)化本文不涉及。
6：其他本文沒提到的內容歡迎自行聯(lián)想，技術水準高超者請忽略本文。
第一、查詢請求的分析和裁剪
線上系統(tǒng)，出現請求較多，數據壓力較大（索引優(yōu)化到位的前提下），我會讓程序員輸出一段時間的查詢請求。（通常數據庫操作有封裝對象，直接記錄日志即可，建議寫入/dev/shm 以減少i/o壓力，如果請求頻次實在很高，可以取一定比例寫入日志），然后基于日志分析。
1、完全一致的查詢請求有多少，平均每秒會出現多少這樣的查詢。
比如常見的，所有頁面都加載系統(tǒng)信息 select * from systeminfo;
2、基于同一數據表同一主鍵的查詢有多少，平均每秒會出現多少這樣的查詢
比如 select name from userinfo where uid=10134; select email from userinfo where uid=10134;
這兩種請求，是可以通過建立緩存機制來優(yōu)化的，
而且做了這個分析，會有一個很好的數據認知
當前數據庫每秒處理多少查詢請求，其中可優(yōu)化的冗余請求有多少，如果建立緩存可以減少多少請求。提升系統(tǒng)支撐性多少？
對于一些不是特別出色的開源系統(tǒng)，分析一下會發(fā)現，可裁剪的查詢請求是非常巨大的。
第二、更新請求的分析和裁剪
更新請求也可以優(yōu)化，
我們一般用mysql的情況下，是先解開binlog文件，還原為文本文件，然后分析
基于同一數據表，同一主鍵的更新請求有多少，平均每個時間段出現多少這樣的請求
舉例1：
update user set lastacttime=.... where uid=10314; 經常更新最后活躍時間
舉例2：
update posts set views=views+1 where pid=10004211; 更新同一個帖子顯示數字
如果這樣的請求較多，那么可以有針對性的建立隊列，定時異步更新。
在異步更新過程中
范例1 多條請求只要記住同一主鍵最后一條即可；
范例2 多條請求可以在程序中合并，對數據庫操作只進行一次。
這樣更新請求頻次就極大下降了。
如果線上有實時性要求，線上可以保持一個內存數據做同步更新。
方法其實很簡單，但是很有效
簡單總結
第一，要隨時了解自己的讀寫請求頻次情況
第二，一定時間范圍內針對同數據表，同主鍵的讀寫請求，均是可優(yōu)化，可裁剪的，但是也要考慮當時的系統(tǒng)負載構成和請求頻次、影響度，抓大放小，解決主要問題即可。
就這樣，其他方面，參見前提說明。