今天和一個(gè)朋友在討論怎么樣應(yīng)對(duì)單表數(shù)據(jù)量過(guò)大，比如一些交易數(shù)據(jù)，每天都有10W的交易量。沒(méi)有多久該表的查詢，插入速度將變慢，最終將不可用。

對(duì)于關(guān)系數(shù)據(jù)庫(kù)來(lái)說(shuō)，應(yīng)對(duì)單表數(shù)據(jù)量過(guò)大的策略大體上有兩種。

• 1，分表。
• 2，歸檔歷史數(shù)據(jù)。

1，分表

在一些場(chǎng)景下可以將不同年份的數(shù)據(jù)放至不同的表格中。比如2004年的數(shù)據(jù)放至Table-2004，而2005年的數(shù)據(jù)放至Table-2005中。或者自定義一些其它規(guī)則。

總體是思想是通過(guò)規(guī)則，將數(shù)據(jù)分別放至不同的表中，以證單表數(shù)據(jù)量不會(huì)太大。

應(yīng)用此技術(shù)時(shí)，可以通過(guò)一些中間手段將這些中間表的細(xì)節(jié)隱藏起來(lái)，比如SQL Server中的分布式視圖。

?

2，歸檔歷史數(shù)據(jù)

還有一種策略是定期Archive歷史數(shù)據(jù)，比如每年的年底，將上一年P(guān)roduction DB的數(shù)據(jù)Archive至History DB中。

比如在2004年的年底，我們將2002年的數(shù)據(jù)Archive至History DB；

在2005年的年底時(shí)將2003年的數(shù)據(jù)Archive至History DB。

總體思想是定期Archive數(shù)據(jù)，保證當(dāng)時(shí)表格中的數(shù)據(jù)量在一定范圍。以此來(lái)保證Production DB的速度，同時(shí)也可以查詢/更新History DB的數(shù)據(jù)（查詢/更新的速度可能很慢）。

應(yīng)用此技術(shù)時(shí)，可以通過(guò)一些數(shù)據(jù)庫(kù)重定向技術(shù)。在Production DB查詢更新/失敗時(shí)，去History DB進(jìn)行查詢/更新。

?

適用場(chǎng)景

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

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

轉(zhuǎn)載于:https://www.cnblogs.com/Jerry-Chou/archive/2010/06/15/1758613.html

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。