mysql，sqlserver數據庫單表數據過大的處理方式

常常混跡於技術社區，頻繁看到這個題目，今天干脆在本身博客重複一遍解決辦法：

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