小白鼠條件：以常見的樹形結構樹為例：有兩張結構相同的表table1（1w資料），table2 (2w資料)，需要對比資料差異。表結構如下： id , parent_id, col1, col2, col3 常規做法是： 常規思想： 迴圈table1，一、充分利用緩衝效果；作業系統的快取、磁碟緩衝等等，都是利用混存技術來提高系統響應速度。充分利用緩衝可以大幅提高系統的回應時間。口說無憑，還是找一個小白鼠來看看： 現有系統中有很多地方有“重新整理”的菜單，這個就是為了重新整理快取資料預留。一個現實的案例就是一個報表系統最佳化後，採用資料緩衝後。用4-5小時不能出現的資料，現在用幾十分鐘就能出所有的資料了。 單獨使用dt.Select(conditinos) 進行資料過濾時，並不能成為效能的瓶頸，但是如何頻繁調用 dt.Select(condtions) 則需要注意對效能的影響了。曾經遇到過這樣的資料， 由於其他原因，需要把當前合格資料全部讀取出來（10w 左右的資料），由於資料結構中已經設定了 tree 的模型，所以需要把datatable 轉換成 tree ，這樣需要不斷的迴圈遞迴尋找所有子節點，類似如下：Demo： Foreach (DataRow parent in dt.Rows){String conditions = String.Format(“parent_id = {0}”, parent[“id”].ToString());DataRow[] rowsChild = dt.Select(conditions);Foreach(DataRow child in rowsChild){// do any thing you want.
}
} 你會發現，此處代碼將嚴重影響效能。解決辦法，直接在外面用 緩衝，建立一個 Hashtable <parent_id, DataRow> 於是內層的迴圈就可以直接在 Hashtable 中找資料，這樣可以大大提高相應的速度。 二、進行預先處理過程；觀察後續處理過程，增加預先處理過程，將頻繁處理的資料進行預先處理。理論同上。三、大資料量分“頁”處理來源於網頁製作過程中的思想。現在系統中有很多地方有它的影子，作業系統裡的頁，資料庫的事物處理過程，都是將大化小，小化了。四、瞭解程式設計語言細節差異五、良好的架構對於系統中的設計，需要盡量避免UI層去瞭解資料結構方面的問題。比如：設計一：良好的設計Public class Item{Private int mID = 0; /// Just for Business layer Public Item(DataRow row){This.mID = ((IConvertible)row[“id”]).ToInt32(null);
} Public int ID{Get{Return this.mID;
}Set{This.mID = value;
}
}
} 設計二：Public class Item{Private DataRow mData= 0; /// Just for Business layer Public Item(DataRow row){This.mData = row;
} Public int Data{Get{Return This.mData
}Set{This.mData = value;
}
}
} 這裡推薦使用一，在二種，已經暴露了資料庫實現的細節問題了。在 UI 層操作使用的時候必須知道每個 Data 裡面所對應的表結構，否則就會出現問題。而一中可以建立對應關係，一個 Column一個屬性，這樣直接操作 Item.ID 就可以了。而且以後使用時也比較方便。 Ps: 設計 二 也可以引起效能問題：Public int Layer{Get{Return mData.IsNull(“Layer”) ? 0 : Convert.ToInt32(mData[“layer”]);
}
} 雖然一個簡單的 Item.Layer 也可能造成系統效能的瓶頸。調用次數少則可以，但是如何調用這個屬性進行判斷時候需要達到 100w 或則達到了 1000w 呢？ 任何一個小的效能改進就會被無限放大。
