針對數據的訪問量過大和數據的動態交互過多的時候，造成服務器的內存和Cpu的使用率都是高居不下的問題我個人的一點看法。
一：數據庫優化
1、數據和日誌文件分開放在不同磁盤上
數據文件和日誌文件的操作會產生大量的I/O。在可能的條件下，日誌文件應該存放在一個與數據和索引所在的數據文件不同的硬盤上以分散I/O，同時還有利於數據庫的災難恢復。
2、優化表分區，索引分區
表分區原因：
當表中的數據量不斷增大，查詢數據的速度就會變慢，應用程序的性能就會下降，此時將這個表一分爲二或者更多分，表還是這個表，只是將其內容存儲分開，這樣讀取就快了N倍了
原理：表數據是無法放在文件中的，但是文件組可以放在文件中，表可以放在文件組中，這樣就間接實現了表數據存放在不同的文件中。
表分區的優缺點 :
優點：
改善查詢性能，對分區對象的查詢可以僅搜索自己關係的分區，提高檢索數據
增強可用性，如果表的某個分區出現故障，表在其他分區的數據仍可用
維護方便：如果表的某個分區出現故障，需要修復數據，只修復該分區即可；
均衡I/O：可以把不同的分區映射到磁盤以平衡I/O，改善整個系統性能。
缺點：
分區表相關：已經存在的表沒有方法可以直接轉化爲分區表。不過 Oracle 提供了在線重定義表的功能。
使用場景：
1、 表的大小超過2GB
2、 表中包含歷史數據，新的數據北增加到新的分區表中
當一個表裏的數據很多時，可以將其分拆到多個的表裏,因爲要掃描的數據變得更少 ,查詢可以更快地運行,這樣操作大大提高了性能,表進行分區後，邏輯上表仍然是一張完整的表，只是將表中的數據在物理上存放到多個表空間(物理文件上)，這樣查詢數據時，不至於每次都掃描整張表
實現：
(1)、創建分區函數
CREATE PARTITION FUNCTION xx1(int)
AS RANGE LEFT FOR VALUES (10000, 20000);
註釋：創建分區函數：myRangePF2，以INT類型分區，分三個區間，10000以內在A 區，1W-2W在B區，2W以上在C區.
(2)、創建分區架構
CREATE PARTITION SCHEME myRangePS2
AS PARTITION xx1
TO (a, b, c);
註釋：在分區函數XX1上創建分區架構：myRangePS2，分別爲A,B,C三個區間
A,B,C分別爲三個文件組的名稱，而且必須三個NDF隸屬於這三個組，文件所屬文件組一旦創建就不能修改
(3)、對錶進行分區
常用數據規範–數據空間類型修改爲：分區方案，然後選擇分區方案名稱和分區列列表，結果如圖所示：
也可以用sql語句生成
CREATE TABLE [dbo].[AvCache](
[AVNote] varchar NULL,
[bb] [int] IDENTITY(1,1)
) ON myRangePS2;
–注意這裏使用[myRangePS2]架構，根據bb分區
(4)、查詢表分區
SELECT *, $PARTITION.myRangePF2 FROM dbo.AVCache
這樣就可以清楚的看到表數據是如何分區的了
(5)、創建索引分區
3、分佈式數據庫設計
分佈式數據庫系統是在集中式數據庫系統的基礎上發展起來的，理解起來也很簡單，就是將整體的數據庫分開，分佈到各個地方，就其本質而言，分佈式數據庫系統分爲兩種：
A .數據在邏輯上是統一的，而在物理上卻是分散的，一個分佈式數據庫在邏輯上是一個統一的整體，在物理上則是分別存儲在不同的物理節點上，我們通常說的分佈式數據庫都是這種
B.邏輯是分佈的，物理上也是分佈的，這種也成聯邦式分佈數據庫，由於組成聯邦的各個子數據庫系統是相對“自治”的，這種系統可以容納多種不同用途的、差異較大的數據庫，比較適宜於大範圍內數據庫的集成。
二：數據表優化
1、設計規範化表，消除數據冗餘
2、“三少原則”
①：數據庫的表越少越好
②：表的字段越少越好
③：字段中的組合主鍵、組合索引越少越好
3、字段設計原則
A、數據類型儘量用數字型，數字型的比較比字符型的快很多。
B、 數據類型儘量小，這裏的儘量小是指在滿足可以預見的未來需求的前提下的。
C、 儘量不要允許NULL，除非必要，可以用NOT NULL+DEFAULT代替。
D、少用TEXT和IMAGE，二進制字段的讀寫是比較慢的，而且，讀取的方法也不多，大部分情況下最好不用。
E、 自增字段要慎用，不利於數據遷移
4、表與表之間依賴關係建議物理依賴
三：SQL優化
1、儘量避免模糊匹配、in、not in、or、having 、避免全表掃描
2、在WHERE 語句中，儘量避免對索引字段進行計算操作
3、減少數據庫訪問次數
4、使用DECODE函數可以避免重複掃描相同記錄或重複連接相同的表。
5、在可以使用UNION ALL的語句裏，使用了UNION
UNION 因爲會將各查詢子集的記錄做比較，故比起UNION ALL ，通常速度都會慢上許多。一般來說，如果使用UNION ALL能滿足要求的話，務必使用UNION ALL。還有一種情況大家可能會忽略掉，就是雖然要求幾個子集的並集需要過濾掉重複記錄，但由於腳本的特殊性，不可能存在重複記錄，這時便應該使用UNION ALL，如xx模塊的某個查詢程序就曾經存在這種情況，見，由於語句的特殊性，在這個腳本中幾個子集的記錄絕對不可能重複，故可以改用UNION ALL）
6、帶有DISTINCT,UNION,MINUS,INTERSECT,ORDER BY的SQL語句會啓動SQL引擎執行，耗費資源的排序(SORT)功能. DISTINCT需要一次排序操作, 而其他的至少需要執行兩次排序