資料量千萬級一下的資料表不一定需要上來就要分庫分表，一旦表被拆分，開發、統計、運維的複雜度會直線上公升。
mysql中幾百萬級別的表，先考慮優化（除非併發太大，單表單庫扛不住）。
mysql在5.1之後才有的，可以看做是水平拆分，分割槽表需要在建表的需要加上分割槽引數，使用者需要在建表的時候加上分割槽引數。
分割槽表底層由多個物理子表組成，但是對於**來說，分割槽表是透明的。sql中的條件中最好能帶上分割槽條件的列，這樣可以定位到少量的分割槽上，否則就會掃瞄全部分割槽。
盡量使用索引，不要因為錯誤的sql寫法導致索引失效。使用explain驗證是否使用索引。
有一些場景統計類、日誌類、弱結構化的資料，可以拋棄mysql等關係型資料庫。
把乙個欄位較多的表，拆分成多個欄位較少的表。單錶的字段不宜過多，一般來說，mysql單錶的字段最好不要超過二三十個。
分表，解決了單錶資料過大的問題，但是畢竟還在同一臺資料庫伺服器上，所以io、cpu、網路方面的壓力，並不會得到徹底的緩解，這個可以通過分庫來解決。
分庫可以利用多台資料庫伺服器的資源，提高了系統的負載能力。當然也會讓邏輯會變得複雜，跨節點的資料關聯效能差，維護難度大（特別是擴容的時候）。
自動增長列
優點：資料庫自帶功能，有序，效能佳。
缺點：單庫單錶無妨，分庫分表時如果沒有規劃，id可能重複。可通過設定自增偏移和步長解決。
## 假設總共有 10 個分表
## 級別可選: session(會話級), global(全域性)
set @@session.auto_increment_offset = 1; ## 起始值, 分別取值為 1~10
set @@session.auto_increment_increment = 10; ## 步長增量
在全域性 redis 中為每張資料表建立乙個 id 的鍵，記錄該錶當前最大 id；
每次申請 id 時，都自增 1 並返回給應用；
redis 要定期持久至全域性資料庫。
uuid
uuid 由4個連字型大小(-)將32個位元組長的字串分隔後生成的字串，總共36個位元組長。
uuid 是個標準，其實現有幾種，最常用的是微軟的 guid(globals unique identifiers)。
優點：簡單，全球唯一；
缺點：儲存和傳輸空間大，無序，效能欠佳。
comb(組合)
組合 guid(10位元組) 和時間(6位元組)，達到有序的效果，提高索引效能。
snowflake(雪花) 演算法
snowflake 是 twitter 開源的分布式 id 生成演算法，其結果為 long(64bit) 的數值。
連續分片
根據特定字段(比如使用者id、訂單時間)的範圍，值在該區間的，劃分到特定節點。
優點：集群擴容後，指定新的範圍落在新節點即可，無需進行資料遷移。
缺點：如果按時間劃分，資料熱點分布不均(歷史數冷當前資料熱)，導致節點負荷不均。
id取模分片
缺點：擴容後需要遷移資料。
一致性hash演算法
優點：擴容後無需遷移資料。
snowflake 分片
優點：擴容後無需遷移資料。
資料庫分表
create table table1 id int 10 unsigned not null auto increment,name varchar 45 primary key id engine myisam create table table2 like table1 建立總表 creat...
資料庫分表策略
1 垂直劃分 將資料表中的某些字段提出，組成新的資料表。將群組id，id，id提出 組成gzm資料表，而將 群組，的詳細資訊單獨放在其他資料表中 在求取索引 關係時，運算元據庫效率更高。2 水平劃分 2.1物理上的水平切分 即將資料分配到不同的db伺服器上。降低單點機器的負載。2.2邏輯上的水平劃分...
資料庫分庫分表
1 基本思想之什麼是分庫分表？從字面上簡單理解，就是把原本儲存於乙個庫的資料分塊儲存到多個庫上，把原本儲存於乙個表的資料分塊儲存到多個表上。2 基本思想之為什麼要分庫分表？資料庫中的資料量不一定是可控的，在未進行分庫分表的情況下，隨著時間和業務的發展，庫中的表會越來越多，表中的資料量也會越來越大，相...