問題描述

如果一張表數(shù)據(jù)很大，將分表拆分數(shù)據(jù)，或者預估數(shù)據(jù)量很大，會預先生成很多分表，那么，日后要改字段，豈不是每張表都是執(zhí)行同樣的 sql 改字段？

MySQL 還有分區(qū)的概念，就是解決一張表數(shù)據(jù)量過大的，為什么現(xiàn)實開發(fā)中還是普遍使用分表的方式？

問題解答

我認為不管是數(shù)據(jù)庫還是編程的各種模式，并不是說0耦合就是最好的。適當?shù)娜哂嗫梢蕴岣咝阅埽涂勺x、維護性。

個人愚見，分區(qū)是你指定規(guī)則進行分表，比較死板。分表可以在業(yè)務邏輯層上進行靈活的熱點數(shù)據(jù)分表。

一個表的容量還是有限的，數(shù)據(jù)越多插入性能就會受影響，每次插入都要去尋找對應分區(qū)，還有索引，都會大大降低插入速度。

至于分表的壞處，當然就是你說的如果需要修改字段，那就要每張表都去執(zhí)行，但這種可能性小，況且之前的數(shù)據(jù)都已成為歷史數(shù)據(jù)了，而如果你把數(shù)據(jù)都放一張表里，改表結構不就把表鎖住了？從這個方面來看，分表還可以做到讀寫分離。另一個壞處就是查詢需要union分表，需要用while去拼接sql，這是有點繁瑣的，恰恰分區(qū)不用拼接。。。

因此實際中，分表和分區(qū)常常是結合的，各自互補。