一、 減少數據訪問
1、創建並使用正確的索引
2、只通過索引訪問數據
3、優化SQL執行計劃
二、返回更少的數據
1、數據分頁處理
(1)客戶端（應用程序或瀏覽器）分頁
(2) 應用服務器分頁
(3) 數據庫SQL分頁：rowid比rownum需要的IO少
2、只返回需要的字段
三、減少交互次數
1、batch DML
採用batch操作一般不會減少很多數據庫服務器的物理IO，但是會大大減少客戶端與服務端的交互次數，從而減少了多次發起的網絡延遲開銷，同時也會降低數據庫的CPU開銷。
2、IN List
例：用ID IN LIST：
select * from mytable where id in(:id1,id2…idn);
通過這樣處理可以大大減少SQL請求的數據，從而提高性能。
3、設置Fetch Size
如果我們要從服務端一次取大量數據時，可以加大fetch_size，這樣可以減少結果傳輸的交互次數及服務器數據準備時間，提高性能。
4、使用存儲過程
5、優化業務邏輯
6、使用Resultset遊標處理記錄
採用resultset遊標處理記錄時，應該將遊標的打開方式設置爲FORWARD_READONLY模式，否則會把結果緩存在JVM裏，造成JVM Out of Memory問題。
四、減少數據庫服務器CPU運算
1、使用綁定變量
綁定變量優點：①防止sql注入②提高SQL可讀性③提高SQL解析性能
不使用綁定變量一般稱爲硬解析，使用綁定變量我們稱爲軟解析。
綁定變量是指sql中對變化的值採用變量參數的形式提交，而不是在sql中直接拼寫對應的值。
非綁定變量寫法：select * from employee where id = 123;
綁定變量寫法：select * from employee where id = ? Prepare statement.set Int(1,123)
2、合理使用排序
3、減少比較操作
4、大量複雜運算在客戶端處理
五、利用更多的資源
1、客戶端多進程並行訪問，前提是數據庫主機資源有空間
2、數據庫並行處理
六、主體思想保證服務器到不了併發瓶頸，在這個前提下，嘗試優化
七、常用的優化策略首選索引，其次是交互次數和分頁技術的使用
八、在數據量極其龐大的前提下，首選分佈式處理方式
設置並行數的建議：
- 如果瓶頸在服務器主機，但是主機還有空閒資源，那麼最大並行數取主機cpu核數和主機提供數據服務的磁盤數兩個參數中的最小值，同時要保證主機有資源做其它任務。
- 如果瓶頸在客戶端處理，但是客戶端還有空閒資源，那建議不要增加sql的並行，而是用一個進程取回數據後在客戶端起多個進程處理即可，進程數根據客戶端cpu核數計算。
- 如果瓶頸在客戶端網絡，那建議做數據壓縮或者增加多個客戶端，採用map reduce的架構處理。
- 如果瓶頸在服務器網絡，那需要增加服務器的網絡帶寬或者在服務端將數據壓縮後再處理了。