l 日誌表應該以時間做分區，方便清理 一般應用都會有一些表用來記錄用戶操作日誌，數據變更記錄，交易流水等日誌型的庫表。這些表最好按時間欄位做分區，這樣在遷移或者清理歷史記錄時會比較方便，藉助oracle的分區交換清理特性，效率比delete高很多。 l 頻繁訪問的sequece應該增加cache O ...
l 日誌表應該以時間做分區，方便清理
一般應用都會有一些表用來記錄用戶操作日誌，數據變更記錄，交易流水等日誌型的庫表。這些表最好按時間欄位做分區，這樣在遷移或者清理歷史記錄時會比較方便，藉助oracle的分區交換清理特性，效率比delete高很多。
l 頻繁訪問的sequece應該增加cache
Oracle在創建序列可以指定cache參數，如果打開這個參數，Oracle就可以預先生成一些sequece，這樣應用獲取sequece相互爭用數據塊的概率就會減少，加快獲取sequece速度。
l 隊列表也應該做分區，減少出現高水位問題
有時我們會使用資料庫表存放待處理的信息，處理完後把記錄刪除，像是消息隊列一樣。這種我們稱之為隊列表。這種表經常會出現高水位的問題，即某一瞬間突然涌入了很多數據，等系統把表裡面記錄處理完，刪除後整個表訪問速度還是很慢（因為高水位被上移後沒恢復）。這時如果庫表有分區，則不容易出現這種問題。
l 減少外鍵使用
在設計庫表時我們一般要使用外鍵以輔助表示不同庫表數據的關聯，但在實際部署時最好不要把外鍵加上。一個原因是外鍵會影響數據插入刪除效率，更重要的原因是加了外鍵的庫表在數據清理，修複時會帶來許多麻煩。
l 減少存儲過程
有些程式員喜歡使用存儲過程封裝業務邏輯，雖然這樣處理數據速度快，但把壓力都留給了資料庫伺服器。而資料庫伺服器資源往往是比較有限的，而且比較難擴展。而應用伺服器資源相對會豐富一些，也好擴展。所以建議儘量少使用存儲過程，即使用也不要放太多業務邏輯。
l 使用綁定變數
儘可能使用綁定變數代替拼sql，這樣一是減少sql註入風險，另外一個是讓資料庫可以復用執行計劃（sql文本相同的才有可能復用），減少資料庫生成執行計劃的消耗。
l 使用並行
Oracle提供並行技術，可以把一個sql涉及的數據集拆分成多份，交由不同進程處理，以加快數據處理速度。對於OLAP系統，可以考慮使用此技巧提高sql運行速度。
l 使用hint避免數據量變化過大的表
有時候我們的應用會出現一些數據變化比較大的表，有時表裡面只有幾十條數據，有時可能有幾萬，幾十萬條。對於這種表的訪問最好使用hint強制資料庫在任何情況都使用索引訪問，因為在數據量小時資料庫生成的執行計劃可能是使用全表掃描，到後面數據發生變化時由於sql沒有變，執行計劃也沒變，這時使用全表掃描效率就會很低。
l 使用tt 共用記憶體等
當一個會話需要訪問一個數據塊，而這個數據塊正在被另一個用戶從磁碟讀取到記憶體中或者這個數據塊正在被另一個會話修改時，當前的會話就需要等待，就會產生一個buffer busy waits等待，也伴隨著Latch爭用。如果太多的會話去訪問相同的數據塊導致長時間的buffer busy waits等待，通常表現形式為CPU使用率很高，但吞吐量很低。造成熱快的原因可能是資料庫設置導致或者重覆執行的SQL 頻繁訪問一些相同的數據塊導致。
l 兩個大表關聯查詢儘量走hash join
雖然oracle提供了很多種表關聯演算法，但是經過實驗，對兩個數據量大的表連接還是使用hash連接效率最高。
l 儘量少用業務要素作為主鍵
不使用業務要素作為主鍵，可以為系統提供很多便利性。一是避免需求變更，原來。二是
l 合理使用縱表和橫表設計
所謂橫表就是指把一個實體的所有特性存儲在一行記錄，形成（ID，屬性1，屬性2，。。。，屬性N）的庫表。
而縱表則是把實體屬性分開多條記錄存儲，設計成（ID，屬性名稱，屬性值）這樣的庫表。
下麵是一個橫表和縱表的例子：
使用橫表好處：
1 比較直觀，查詢比較方便
2 屬性值可以根據屬性內容設計，例如年齡用number類型存儲，職業用varchar2存儲
使用縱表好處：
1 避免單表欄位不停擴展，oracle是行存儲資料庫，記錄欄位越多，記錄掃描時消耗的IO就會更多
2 增加屬性比較方便
建議：對於頻繁使用的屬性放橫表，對於不頻繁使用的屬性（例如住址），或者只有少部分記錄有的屬性（例如博客）放縱表。
l 頻繁使用的小表可以考慮設置cache參數
設置了cache後，oracle會儘量讓這個表的數據保持在記憶體，提高訪問速度。我碰到過把操作員和菜單信息表加了cache參數，大幅提高登錄速度的情況。
l 物化視圖
普通視圖只是用於簡化複雜查詢，對於效率提升不大。Oracle提供了一種叫物化視圖的特殊對象，可以把視圖查詢的結果集存起來，並且支持在基礎數據變化時自動刷新。不過物化視圖bug多，使用需要謹慎。
l 使用rac集群的資料庫，最好分業務使用不同優先節點
由於oracle訪問數據塊時要求先把數據裝載到記憶體，如果有某個數據塊頻繁被不同實例節點訪問，會導致rac集群頻繁地把數據從一個節點機器傳輸到另一個節點，這樣會很消耗時間。所以建議不同業務優先訪問不同rac節點，這樣可以減少數據爭搶的概率。
l 善用函數索引解決狀態欄位查詢，少用點陣圖索引
使用。點陣圖索引容易造成數據塊爭用，建議在OLTP系統少用。
l 悲觀鎖和樂觀鎖
悲觀鎖思想認為，數據被併發修改的幾率比較大，需要在修改之前藉助於資料庫鎖機制,先對數據進行加鎖。樂觀鎖思想認為，數據一般是不會造成衝突的。所以在一般先將數據查出來但不加鎖，在修改回資料庫時檢查數據有沒有發生過變化，如果有則認為更新失敗。業務場景允許失敗重試的情況，建議多考慮使用悲觀鎖，減少鎖資源對資料庫的消耗。
l 一致讀
Oracle的數據塊被修改之前會把數據塊備份到undo表空間，這樣可以保證sql查詢過程中，數據被修改不會影響查詢結果。而且還可以使用“閃回查詢”的技術，指定查詢庫表某個時間點的數據。
l 使用with as改寫複雜的關聯查詢
這樣好處一是簡化sql邏輯，二是有必要時還可以使用hint：materialize先把with as的內容實體化，減少重覆查詢。
l 索引要合理（基數過小的欄位不適合建索引）
有些程式員在性別列上面都建了索引，以為查詢時至少可以省一半時間，其實是錯的。因為對於這種選擇性不高的查詢，先使用索引查詢再回表查會導致很多隨機讀寫，速度反而不如直接全表掃描快。
l 大量數據遷移時加快入庫速度的方法：
commit nowait
append
alter table nologging
刪除索引
使用交換分區
l 最好對資料庫api進行封裝，以便在日誌裡面輸出使用的sql
系統做複雜後，新手想完全瞭解系統業務很困難。如果可以設置在日誌裡面輸出訪問資料庫使用的sql，可以更方便我們進行系統運維。
更多資料庫開發經驗見：
https://www.cnblogs.com/kingstarer/p/9613626.html 《oracle資料庫應用性能優化經驗（培訓講義）》
https://www.cnblogs.com/kingstarer/p/11968247.html 《Oracle Proc編程性能優化經驗》
