mysql，sqlserver資料庫單表資料過大的處理方式

經常混跡於技術社群，頻繁看到這個題目，今天干脆在自己部落格重複一遍解決辦法：

針對mysql，sqlserver等關係型資料庫單表資料過大的處理方式

如果不是 的  那種多機器叢集方案的話：  先考慮表分割槽 ；然後考慮分表 ；然後考慮分庫。

這個題目是我所經歷過的，我做的是GPS應用，早期版本就是選用的關係型資料庫Sql Server。當時我選取的方案就是第一種：表分割槽。 表分割槽的優勢是，如果表結構合理，可以不涉及到程式修改。也就是說，對程式來講依然是單表讀寫的效果！

所有軌跡資料存入到一個巨大的表裡。有多大呢？

• 最大儲存量超過10億行。 具體數值應該是12億多點，由於系統設計為只儲存30天軌跡，所以線上期間最大儲存只到這個數，再後來採用雲架構，上雲替換成非關係性資料庫，獲得了更高的寫入效能和儲存壓縮能力。  

• 每日寫入量就超過1500萬行。上下班交通高峰時候每秒寫入量平均超過500行。 也就是500iops，距離系統設計的壓測指標3000還有一大截

這張大型單表設計要點： （一個聚集索引用於寫入，一個聯合索引用於查詢，沒有主鍵，使用表分割槽）

明確主鍵用途：

真的需要查詢單行資料時候才需要主鍵！

我採用無主鍵設計，用於避免寫入時候浪費維護插入資料的效能。最早使用聚集的類似自增的id主鍵，壓測寫入超過5億行的時候，寫入效能縮減一半

準確適用聚集：

寫入的資料在硬碟物理順序上是追加，而不是插入！

我把時間戳欄位設定為聚集索引，用於聚集寫入目的設計。保證硬碟上的物理寫入順序，不浪費效能用於插入資料

職責足夠單一：  

用於精準索引！

使用時間+裝置聯合索引，保證這張表只有一個查詢用途。保證系統只有一種查詢目的：按照裝置號，查詢一個時間段的資料。

精確的表分割槽：

要求查詢時候限定最大量或者最大取值範圍！

按天進行表分割槽，實現大資料量下的高效查詢。這裡是本文重點，按照聚集索引進行，可以讓目標資料侷限在更小的範圍進行，雖然單表資料上億，但是查詢基本上只在某一天的的幾千萬裡進行索引查詢

每張表會有各自的特點，不可生搬硬套，總結下我這張表的特點：

只增，不刪，不改！

關於不刪除中：每天使用作業刪除超過30天的那個分割槽資料除外，因為要清空舊的表分割槽，騰出新的表分割槽！

只有一個業務查詢：只按照裝置編碼查詢某個時間段

只有一個運維刪除：刪除舊的分割槽資料

這張表，是我技術生涯中進步的一個大階梯，讓我我體會到了系統架構的意義。

雖然我的這張舉行表看似只有4個關鍵點，但是這四個非常精準的關鍵點設計，耗費了我一個月之久！正是這麼足夠精準的表結構設計，才撐起了後來壓測併發量超過3000的併發寫入量！壓測的指標跟資料庫所在的硬碟有直接關係，當時選取的硬碟是4塊10000轉的SAS盤做了Raid10的環境

關於後來為什麼沒有更高的實際應用數值，是因為系統後來改版為雲架構，使用了 ，更改為寫入效能更高的 儲存軌跡資料。所以雖然距離壓測指標還差很遠，但是也沒有實際跑到這個資料！單機應用再怎麼改造，每次升級都是一件麻煩事，所以應當儘可能將瓶頸點提高，甚至消除，雲架構的意義就在於彈性擴充套件，雖然我在資料庫方面還沒有這方面的成功案例可分享，但是這種架構的意義很明白：將來面對更大的壓力，只需要增加伺服器數量！    

最後提一句， 很多人覺得SSD就足夠高的效能了，但是對於雲伺服器，ssd的效能才跟傳統物理機的iops相持平，這是由於虛擬化層面的損失導致的！

原文地址：   文章的更新編輯依此連結為準。歡迎關注源站原創文章！