摘要：經常混跡于技術社區，頻繁看到這個題目，今天干脆在自己博客重復一遍解決辦法針對，等關系型數據庫單表數據過大的處理方式如果不是阿里云的分布式數據庫那種多機器集群方案的話先考慮表分區然后考慮分表然后考慮分庫。

經常混跡于技術社區，頻繁看到這個題目，今天干脆在自己博客重復一遍解決辦法：

針對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?文章的更新編輯依此鏈接為準。歡迎關注源站原創文章！