今天和一個朋友在討論怎么樣應對單表數據量過大，比如一些交易數據，每天都有10W的交易量。沒有多久該表的查詢，插入速度將變慢，最終將不可用。

對于關系數據庫來說，應對單表數據量過大的策略大體上有兩種。

• 1，分表。
• 2，歸檔歷史數據。

1，分表

在一些場景下可以將不同年份的數據放至不同的表格中。比如2004年的數據放至Table-2004，而2005年的數據放至Table-2005中。或者自定義一些其它規則。

總體是思想是通過規則，將數據分別放至不同的表中，以證單表數據量不會太大。

應用此技術時，可以通過一些中間手段將這些中間表的細節隱藏起來，比如SQL Server中的分布式視圖。

?

2，歸檔歷史數據

還有一種策略是定期Archive歷史數據，比如每年的年底，將上一年Production DB的數據Archive至History DB中。

比如在2004年的年底，我們將2002年的數據Archive至History DB；

在2005年的年底時將2003年的數據Archive至History DB。

總體思想是定期Archive數據，保證當時表格中的數據量在一定范圍。以此來保證Production DB的速度，同時也可以查詢/更新History DB的數據（查詢/更新的速度可能很慢）。

應用此技術時，可以通過一些數據庫重定向技術。在Production DB查詢更新/失敗時，去History DB進行查詢/更新。

?

適用場景

1，分表操作適用于數據量巨大，但查詢更新分布很平均。比如身份證系統，每個人可能被查到的概率大致相等。

2，歸檔歷史數據適用于數據量巨大，但查詢分布有規律——最近的數據最常被使用。比如我們的生產數據，5年前的數據基本不用，即使是用了只涉及到查詢。這樣我們就可以將5年前的數據歸檔至History DB中并進行查詢的優化。

轉載于:https://www.cnblogs.com/Jerry-Chou/archive/2010/06/15/1758613.html

總結

以上是生活随笔為你收集整理的单表数据量过大处理策略的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。