本文介紹一些關於提高系統性能方面的知識，列分割，行分割，實例分割，物理存儲分割等技術。
這篇主要講解一下數據庫的設計，因爲一個好的數據結構，對整體系統的運作太重要了，請看看本文的內容。
提到程序性能，大家都知道時間複雜度的公式O(f(n))。在提高性能的這個迷局中，很多人都會想盡辦法降低算法函數f的複雜度，或者是提高函數f的運行 速度。但是這些都是沒有辦法的辦法，是捨本求末的辦法。如果基數n巨大，這類方法都不會有很好的效果，因爲問題的本身在於基數 n。千方百計減少基數n的數量才能獲取質的提高。
如何才能達到降低基數n的效果呢？假設你一個雜貨店的老闆，你有一個雜誌貨櫃。可是雜誌的種類越來越多，貨櫃放不下了，這時你會怎麼做？是延長貨櫃的長度 還是把雜誌分類後，再增加一個貨櫃？我更願意增加一個貨櫃，而不是無限制的延長原來的貨櫃。從雜貨店貨櫃的啓示，我覺得降低基數 n的數量的有效辦法是分而治之：
一、 列分割
通常，隨着開發過程的推進，系統中主表的字段數會越來越多。但是一個表的字段個數，是受數據庫規範和性能限制的。例如，SQL Server 數據庫中一個表最多可以包含1024個字段，而實際應用中一般不能超過246個字段，每行數據可以存儲8060字節。（參見 http://msdn.microsoft.com/zh-cn/library/ms143432.aspx）
另外，對於大數據表來說，列的數量直接影響存取速度。數據的存儲結構對行的存取更加優化，而不是列的存取。下面，提出幾種分割存儲列的情形。
1、 列數太多時。
我在2004年曾經做過一個失敗的項目。在設計一個5年的採購計劃表時，我把每個月的採購計劃設計成列，這樣表的列說增加了60 列，這張表最終達到120個列。這種設計導致的結果是，當表有100萬條記錄時，採購計劃的計算要花費2.5小時。改進方案是把列改成行存儲，增加一個計 劃年份字段，這樣，總的列數減少了近40%，表的行數增加了增加到了500萬條，但是存取速度提高了很多，使採購計劃的計算時間降低到0.5小時。
所以，我給出的意見是
l 表的列數最好不要超過80個
l 行存儲比列存儲的存取速度更快
2、 表中列的數據相對較大或不經常用到時
表中存在下面的字段時需要隔離出去：
l 圖片對象
l 附件（文件等）
l 大量的備註信息
l 幾乎不被查詢的列
3、 表中的字段，可以按照業務邏輯分類時。
按照數據庫的設計規範，一個同一個對象的屬性應該屬於一張表。可是，實際情況是，如果按照業務邏輯來劃分表，能獲得更好的性能。
二、行分割
對於記錄行數巨大的表來說，最好的辦法是按分類進行行分割，讓數據存儲在多個表內。自然界有一個放之四海皆準的“二八”定律，把它應用到數據上，就可以這樣解釋：在所有的數據中有20%的數據是可以滿足我們80%的需求的。“
根據這個原理，通常有兩種分類方法：
1、 按時間分類
如果數據的時效性很強，我們可以認爲所有數據中，20%近期更新的數據能夠滿足業務80%的需求。例如，如果我們有5年的歷史數據，那麼就可以認爲 其中在1年內（20%）更新過的數據（也可以是1年內創建的數據），能滿足80%的業務需求；所以我們可以把這張表拆成兩個表，分別存儲20%和80%的 數據，以達到提高效率的目的。如果兩張表仍然沒有有效的提高性能，還可以利用“二八”定律再次分割。
實效性數據量和使用量關係：
2、 按索引分類
當數據的時效性不明顯時，可以按索引分類數據。所謂索引可以是任何可以用於分類的字段，比如部門編號，員工編號，工藝編號等等。我們可以這樣假設， 表中存儲了所有零件的信息，但是在80%的情況下，1號生產車間只會存取自己部門用到的零件。於是，我們可以按照部門編號，把表分成多個。
三、數據庫實例分割
一般情況下，開發人員習慣於給每個項目配置一個數據庫。但是實際上我們可以給一個應用程序更多的數據庫實例。比如，在一個網絡遊戲服務器中，經常會 有賬戶數據庫（用於認證）、存儲數據庫（用於存儲狀態）、日誌數據庫（用於存儲監控狀態）、地圖數據庫(用於存儲地圖狀態)等等。類比到ERP系統中，我 們可以把許多項目共同的部分抽象出來，分別存儲在不同的數據庫實例中。例如，用戶信息、部門信息、系統日誌信息等可以定製成通用的數據庫，每個軟件項目都 可以去使用。
四、數據庫實例物理部署的分割
表分割、數據庫實例的分割，爲物理部署帶來了靈活性。例如，我們對物料表按照不同的品目，進行了表分割；又對這些表部署在了不同的數據庫實例中；這 樣我們就有條件把這些數據庫實例分別部署在不同的物理數據庫服務器上。這種部署給我們帶來的好處是，物料計算時，我們可以指令所有的數據庫服務器分佈式計 算，大大提高運算速度。