經常混跡於技術社區，頻繁看到這個題目，今天干脆在自己博客重複一遍解決辦法：
針對mysql，sqlserver等關係型數據庫單表數據過大的處理方式
如果不是阿里雲的分佈式數據庫 DRDS 那種多機器集羣方案的話： 先考慮表分區 ；然後考慮分表 ；然後考慮分庫。
這個題目是我所經歷過的，我做的是GPS應用，早期版本就是選用的關係型數據庫Sql Server。當時我選取的方案就是第一種：表分區。 表分區的優勢是，如果表結構合理，可以不涉及到程序修改。也就是說，對程序來講依然是單表讀寫的效果！
所有軌跡數據存入到一個巨大的表裏。有多大呢？
最大存儲量超過10億行。具體數值應該是12億多點，由於系統設計爲只存儲30天軌跡，所以線上期間最大存儲只到這個數，再後來採用雲架構，上雲替換成非關係性數據庫，獲得了更高的寫入性能和存儲壓縮能力。
每日寫入量就超過1500萬行。上下班交通高峯時候每秒寫入量平均超過500行。也就是500iops，距離系統設計的壓測指標3000還有一大截
這張大型單表設計要點：（一個聚集索引用於寫入，一個聯合索引用於查詢，沒有主鍵，使用表分區）
明確主鍵用途：
真的需要查詢單行數據時候才需要主鍵！
我採用無主鍵設計，用於避免寫入時候浪費維護插入數據的性能。最早使用聚集的類似自增的id主鍵，壓測寫入超過5億行的時候，寫入性能縮減一半
準確適用聚集：
寫入的數據在硬盤物理順序上是追加，而不是插入！
我把時間戳字段設置爲聚集索引，用於聚集寫入目的設計。保證硬盤上的物理寫入順序，不浪費性能用於插入數據
職責足夠單一：
用於精準索引！
使用時間+設備聯合索引，保證這張表只有一個查詢用途。保證系統只有一種查詢目的：按照設備號，查詢一個時間段的數據。
精確的表分區：
要求查詢時候限定最大量或者最大取值範圍！
按天進行表分區，實現大數據量下的高效查詢。這裏是本文重點，按照聚集索引進行，可以讓目標數據侷限在更小的範圍進行，雖然單表數據上億，但是查詢基本上只在某一天的的幾千萬裏進行索引查詢
每張表會有各自的特點，不可生搬硬套，總結下我這張表的特點：
只增，不刪，不改！
關於不刪除中：每天使用作業刪除超過30天的那個分區數據除外，因爲要清空舊的表分區，騰出新的表分區！
只有一個業務查詢：只按照設備編碼查詢某個時間段
只有一個運維刪除：刪除舊的分區數據
這張表，是我技術生涯中進步的一個大階梯，讓我我體會到了系統架構的意義。
雖然我的這張舉行表看似只有4個關鍵點，但是這四個非常精準的關鍵點設計，耗費了我一個月之久！正是這麼足夠精準的表結構設計，才撐起了後來壓測併發量超過3000的併發寫入量！壓測的指標跟數據庫所在的硬盤有直接關係，當時選取的硬盤是4塊10000轉的SAS盤做了Raid10的環境
關於後來爲什麼沒有更高的實際應用數值，是因爲系統後來改版爲雲架構，使用了阿里雲，更改爲寫入性能更高的非關係型數據庫MongoDB存儲軌跡數據。所以雖然距離壓測指標還差很遠，但是也沒有實際跑到這個數據！單機應用再怎麼改造，每次升級都是一件麻煩事，所以應當儘可能將瓶頸點提高，甚至消除，雲架構的意義就在於彈性擴展，雖然我在數據庫方面還沒有這方面的成功案例可分享，但是這種架構的意義很明白：將來面對更大的壓力，只需要增加服務器數量！
最後提一句， 很多人覺得SSD就足夠高的性能了，但是對於雲服務器，ssd的性能纔跟傳統物理機的iops相持平，這是由於虛擬化層面的損失導致的！
原文地址： https://www.opengps.cn/Blog/View.aspx?id=284 文章的更新編輯依此鏈接爲準。歡迎關注源站原創文章！