上篇文章講解了傳統數據庫的一些設計注意點。
本篇為第二篇，在大數據量的情況下，如何去提前設計這個表結構，來達到一個比較好的效果。對于團隊，對于后續的維護和擴展都帶來更大的便利。

自增id

自增id還是可以有，但是不是必須的了。但是建議還是每張表中有一個自增id。 為什么，還是那句話，做數據查詢，遷移，排序的時候，有著天然的一些優勢。

唯一標識

這個標識無論是token，還是其他例如訂單的訂單號或者其他唯一標識都行。 重點是唯一，不只是在單系統中唯一，而是需要在并發的情況，也能夠保持唯一。

關于分布式id的生成方案，網上已經有很多了，這里就不重復了。谷歌搜索搜索，自己看下原理，跑跑demo，能夠滿足自己業務的最大并發情況下的唯一即可。

比如說你未來幾年的最大并發也就是100，搞個能支持在幾千并發下不會出現標識重復的實現方案即可，并發幾萬，幾十萬，真的需要嗎？

后續如果真的能夠達到幾萬并發，那說明什么？說明業務火爆了啊。難道還抽不出時間，抽不出人來做一個id生成方案的改造？這里有比較重要的一點，不要太過超前設計，沒必要，也沒那個時間。

創建時間&修改時間

創建時間和修改時間還是要有的，而且建議時間精確到毫秒級別，在上一篇，我沒有說精確多少，那是因為并發不高，秒級完全夠了。但是在大數據量的情況下，可能一秒有幾十、幾百、上千、上萬的數據新增都是有可能的。那么秒級在這種情況下完全就不夠看了，選擇毫秒級別是一個比較好的選擇。

分庫分表

前面的唯一標識/創建時間可以說就是為了這步準備的。

但是怎么來設計分庫分表，選擇什么方式，范圍還是hash，選擇哪個字段，還是選擇幾個字段。平滑遷移還是停機遷移。

這些都沒有唯一答案。只能是根據場景來區分不同的情況。下面舉幾個例子來進行一個講解，不是標準答案，同一個場景為了滿足不同的需求，也可能有不同的一個設計。

1：支付訂單的場景

例如，訂單每日新增千萬級，那么在這個情況下。我們還需要區分一下。

1.1 訂單號包含了時間戳

那么強烈建議按照時間維度進行分庫分表。 也強烈建議在訂單號中將時間戳放進去。
優點：

• 單表的大小是可以預知的，一天多少訂單量，一個月多少訂單量
  非常便于水平擴展，后期如果想對整個分片集群擴容時，只需要添加庫表即可，不需要對已經存在的分片數據進行遷移。使用訂單號進行范圍查找時，可以快速定位查詢，避免了跨片查詢的問題。

缺點：

• 最近的訂單會存在著熱點數據，可以通過其他方式進行解決，例如緩存等

1.2 訂單號不包含時間戳

不包含時間戳，你可以選擇創建時間來做范圍分片。 或者使用訂單號來做hash分片，也就是取模運算分片。

hash分片的缺點就是后期擴容會涉及到老數據的遷移，但是現在有一種方案可以避免該缺點，那就是使用虛節點，先占位，但不使用，需要的節點需要是2的次方個才行。大家可以去網上了解一下，這里就不展開了。 另外一個缺點就是跨片查詢的性能問題，當查詢條件中沒有訂單號的時候，會無法定位到數據庫表，所以會遍歷所有的庫表，進行查詢，再在內存中合并數據，取最小集返回，在這種情況下，分庫分表反而會成為累贅。

其他一些分庫分表帶來的事務問題大家可以看看現在的一些分布式事務解決方案，都還挺不錯的。阿里的Seata可以了解一下。

最后，分庫分表，并不是一定要分庫的，也可以只分表，這樣很多分庫分表的問題就不存在了。 分庫分表還是要跟進實際的數據增長速度來評估，比如說，每年數據才幾十萬或者百萬，那么沒有必要進行一個過渡設計，單表即可。等數據庫到了瓶頸，可以再考慮優化。

很多時候，瓶頸也不一定是在數據庫。

性能優化

在這里，對于性能優化提一句，因為自己也剛完成一個性能優化的需求不久，提升性能2倍左右。這次優化完全沒有動數據庫。 主要優化點在：同步方法異步調用第三方服務、計算異步處理、批量單次調用、部分不變數據緩存 重點：拿資源（空間、線程）換時間

總結

當數據量大了之后，其實很多設計和傳統的數據庫還是沒有很大變化的。

主要是要考慮到數據量大之后，該表如果分庫分表，那么怎么設計更加合理一點，也許當下不需要分庫分表，但是可以給以后少埋點坑。

但是注意，還是那句話，不要過度設計，也不要不去設計。簡單的說，可以預估到以后的業務每日數據量新增是萬級幾十萬以上的，就可以考慮下以后的分表，但是當期并不需要做。 但如果是日增百萬千萬級別，那么這個分庫分表肯定是當期就需要進行的。 假如是日增幾百幾千的表，那么就不要花過多時間去考慮什么分庫分表的方案了，真的用不上。

建議的一個提前思考時間，1年左右的思考維度設計比較好。即不會超前，也不會因為迭代了一兩次業務就有人提出，不知道哪個**設計的結構，又得重新來設計。

最后，能夠在技術方案時就明確的事情，絕不留到寫代碼的時候再去明確！ 技術方案越清晰（注意：不是說超前設計，這里面有個度，只可意會不可言傳），寫代碼越輕松，團隊協作越流暢。

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的设计大数据量表结构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。