Asp.Net 網(wǎng)站優(yōu)化系列之數(shù)據(jù)庫優(yōu)化措施使用主從庫（全）

更新時間：2010年06月09日 20:34:22 作者：

網(wǎng)站規(guī)模到了一定程度之后，該分的也分了，該優(yōu)化的也做了優(yōu)化，但是還是不能滿足業(yè)務上對性能的要求；這時候我們可以考慮使用主從庫。

主從庫是兩臺服務器上的兩個數(shù)據(jù)庫，主庫以最快的速度做增刪改操作+最新數(shù)據(jù)的查詢操作；從庫負責查詢較舊數(shù)據(jù)，做一些對實效性要求較小的分析，報表生成的工作。這樣做將數(shù)據(jù)庫的壓力分擔到兩臺服務器上從而保證整個系統(tǒng)響應的及時性。

SQL Server提供了復制機制來幫我們實現(xiàn)主從庫的機制。我們看下如何在sql server 2005中實踐：

實踐前需要新創(chuàng)建一個Test的數(shù)據(jù)庫，這個庫中建一個測試表。

1. 打開sql server企業(yè)管理器，在對象資源管理器里面選擇復制à本地發(fā)布，右鍵選擇新建發(fā)布

2. 打開新建發(fā)布向導，點下一步，選擇發(fā)布數(shù)據(jù)的數(shù)據(jù)庫

3. 我們選擇Test數(shù)據(jù)庫，并點擊下一步，選擇發(fā)布類型

這里我們選擇的是事務性發(fā)布，事務性發(fā)布保證數(shù)據(jù)在做更新之后盡可能快的分發(fā)到訂閱服務器上。有關其他幾種發(fā)布類型的使用場景請參考msdn
4. 點擊下一步，選擇要發(fā)布的對象，這里我們只對表進行發(fā)布

5. 點擊下一步進入篩選數(shù)據(jù)設置，這里我們要復制表的所有數(shù)據(jù)所以不做設置

6. 點擊下一步，指定何時運行快照，我們選擇初始話數(shù)據(jù)，并選擇默認的運行快照頻率

7. 繼續(xù)下一步，設置快照代理的運行賬戶，我們選擇sql server agent賬戶

8. 點擊下一步選擇創(chuàng)建發(fā)布，再次點擊下一步設置發(fā)布的名稱

9. 點擊完成，完成發(fā)布的設置，并創(chuàng)建發(fā)布，現(xiàn)在在本地發(fā)布出新添加了我們創(chuàng)建的發(fā)布

現(xiàn)在成功創(chuàng)建了發(fā)布，我們還需要創(chuàng)建訂閱：在本地訂閱文件夾上右擊新建訂閱，通過向導可以很容易的創(chuàng)建訂閱，創(chuàng)建訂閱時可以選擇以發(fā)布者推送或者訂閱者主動的方式創(chuàng)建。具體步驟如下：
1. 通過右鍵菜單打開新建訂閱，點擊下一步，選擇我們剛剛創(chuàng)建的發(fā)布作為訂閱源

2. 選擇是以推送還是以主動請求的方式同步數(shù)據(jù)，我們選擇主動訂閱

3. 設置執(zhí)行分發(fā)代理的賬戶

4. 設置代理請求同步的頻率

5. 設定是否立即做數(shù)據(jù)的初始化操作

6. 完成創(chuàng)建訂閱

創(chuàng)建完成之后，我們可以通過在主庫表中插入n條數(shù)據(jù)，然后在從庫中查詢的方式驗證復制是否成功。

在Sql server2005中的復制創(chuàng)建起來很簡單，我們需要根據(jù)業(yè)務需要設定復制的類型和同步的頻率，下面我們談談如何有效的在程序中使用主從庫。

主從庫之間是一種發(fā)布訂閱的關系，發(fā)布者和訂閱者之間并非實時同步的，通常會有幾分鐘的延時，更有甚者會有幾個小時的延時。所以我們需要通過合理的使用來避開有延時這個問題。

我們希望主庫盡可能的少參與查詢，來提高寫的及時性；同時要讓從庫在不影響讀出數(shù)據(jù)的準確及時的前提下盡可能的分擔主庫的壓力。

主從兩個庫需要在配置文件中配置兩個連接字符串，CONN_Master和CONN_Slave。我們需要設定一些規(guī)則決定當前的查詢應該從主庫查還是需要從從庫查。這個規(guī)則沒有定式，只能根據(jù)業(yè)務需要來確定。下面我舉幾個例子來說明：

1. 以豆瓣讀書書的詳細頁為假定場景，你可以點擊這里看下頁面的結構（我不是豆瓣的技術，在這里只是拿這個頁面舉例）
我們來分析呈現(xiàn)這個頁面需要的數(shù)據(jù)和這些數(shù)據(jù)的實效性要求
1）書的詳細信息時效性要求：要求及時
2）豆瓣成員的常用標簽實效性：不需要很及時
3）喜歡讀這本書的人也喜歡讀的書屬于分析數(shù)據(jù)，不需要很及時
4）最新書評要求及時
5）讀這本書的幾個用戶及時性不高
6）喜歡這本書的人常去的小組屬于分析數(shù)據(jù)不需要很及時
從上面的分析可以看出只有1），4）兩項數(shù)據(jù)需要從主庫讀，而2），3），5），6）為非及時數(shù)據(jù)從從庫讀取即可。當然我們可以對這些實效性不高的數(shù)據(jù)做緩存處理。

2. 以論壇帖子列表頁面為假定場景，玩論壇的人都喜歡頂貼，把自己的帖子頂?shù)降谝豁撟尭嗟娜岁P注，而對于50頁之后的帖子則反讀的人很少；我們可以根據(jù)這個業(yè)務邏輯特征來決定在用戶訪問前50頁帖子列表數(shù)據(jù)時從主庫讀，而當用戶訪問超過50頁之后的數(shù)據(jù)時則從從庫進行查詢。

3. 以訂單為例，通常超過三個月的訂單就不會再有變化了，假定我們把訂單號設計為日期格式時，根據(jù)訂單號去查詢訂單時就可以根據(jù)訂單號來決定該訪問主庫還是從庫。

舉了幾個適用的場景，我們以第三個場景為例，寫一段簡單的示意代碼看下

復制代碼代碼如下:

 
//orderNo 的格式為 20100528120105000001 即yyyyMMddHHmmss + 序號 
public OrderInfo GetOrder(string orderNo) { 
string connString = ConnStringGetter.GetForOrder(orderNo); 
using (SqlConnection conn = new SqlConnection(connString)) 
{ 
... 
} 
} 

public class ConnStringGetter 
{ 
public static string GetForOrder(string orderNo) { 
int year = int.Parse(orderNo.Substring(0,4)); 
int money = int.Parse(orderNo.Substring(4,2)); 
int date = int.Parse(orderNo.Substring(6,2)); 
DateTime orderTime = new DateTime(year, money, date); 

TimeSpan ts = DateTime.Now - orderTime; 
//根據(jù)訂單的時間決定使用主庫還是從庫 
if (ts.TotalDays > 30) return ConfigurationManager.ConnectionStrings["CONN_Slave"].ConnectionString; 
return ConfigurationManager.ConnectionStrings["CONN_Master"].ConnectionString; 
} 
} 