時序資料從分表到分庫
這裡的時序資料泛指一切隨時間推移而不斷增長的資料，比如通話記錄、銀行交易記錄等。
對於資料庫來講，時序資料並沒有什麼特殊性，可以和普通資料一樣放在資料表中。不過，因為不斷增長，積累時間較長後，這種資料的量常常都會很大。一個物理表的資料量太大時，就會影響查詢和計算的效能。
現代資料庫一般都提供有表分割槽（PARTITION）的機制，就是把一個大表縱向（按行）分成若干區段，分割槽規則由資料庫管理員來設定，對應用程式設計師來講是透明的，可以和不分割槽的表一樣訪問，資料庫會自動根據查詢條件決定讀取哪些分割槽的資料，這樣的介面體驗非常好。
不過，在實戰中，分割槽表的效果在某些場景下並不好，而且使用時也有些約束條件，並不總好用且能用的。結果，在實際業務中，我們常常會看到對於這種大資料採用手工物理分表的方案。
所謂物理分表，就是人為將一個大表分成若干較小的物理資料表。因為時序資料的結構中一定會有一個欄位來表示事件發生的時刻，而事件發生的數量一般來講也會按時間段相對平均分佈（大多數情況會緩慢增長，但討論時可以忽略），所以最常用的方案就是按時間段來做分表，比如一個月資料對應一個分表，這種方式在金融、電信行業比較普遍。
物理分表並不是資料庫自動支援的方案，不能對應用程式做到透明，需要應用程式自己處理。在查詢資料時一般都會有時間段引數，應用程式可以根據這個引數計算出該查詢涉及哪些分表，然後將這些分表UNION起來拼到SQL語句的FROM後面。查詢不涉及的時間段對應的分表不會被拼進來，這樣就可以有效減少資料遍歷的範圍，從而提高效能。
這個方案在單個數據庫時沒啥毛病，但是不是能推廣到多個數據庫的情況呢？
資料量再大下去，一個數據庫也無法承受了，而某些場景下又不允許我們上一套分散式資料庫系統，畢竟分散式資料庫是個沉重的工程，不僅造價高，而且維護管理都要複雜不少。這時候，我們可以擺多個數據庫分別儲存資料，類似物理分表的方案，也按時間段把資料分拆到各個資料庫中，比如一年資料放入一個數據庫中（一般來講多個庫會部署到多臺機器上），這樣就能分攤查詢壓力了。