有一定資料規模的公司一般都有分庫分表的策略，本文記錄本人在工作遇過的分庫分表策略，分庫和分表的邏輯差不多，所以在本文我們認為分庫和分表是乙個概念。
按照業務垂直劃分
比如我是一家酒店ota，對外提供酒店預定服務。顯而易見，在資料庫中存著房間的狀態資訊。我們可以想象得到一線城市檢視率、預訂率和交易額佔比是非常大的。在這種情況下，我們就可以根據業務把熱門的城市資料放在不同的分片裡。熱門城市各自單獨分片，冷門城市放在乙個分片裡。資料庫看起來像這樣，hotel_shenzhen,hotel_beijing
好處：在專案啟動的時候一般都會做一些預熱處理，以達到快速響應的目的。這樣做的好處，根據地區進行分庫，省去了其他地區的查詢條件，在做索引重建，資料錄入等操作的時候邏輯簡單，效率高。
適合場景：這種方法適合業務可以垂直拆分的場景，耦合度低。
水平拆分
酒店的訂單中心擁有龐大的資料量，但是訂單無法進行業務垂直拆分。這種情況可以進行水平拆分，拆分可以以訂單的流水號為依據，比如根據id範圍劃分，根據id雜湊劃分。最終資料庫看起來像這樣：db1.tb1，db1.tb2,db2.tb1，db2.tb2......
關於事務
分庫分表對事務的支援會變得很難，xa事務實現起來也是有一定效能代價的。所以為了保證資料一致性，要根據具體情況具體分析了。有零事務的、有二段式提交的。
關於跨庫跨表查詢
首先說明一點，博主是在網際網路行業工作，所以平時幾乎不寫聯合查詢sql，所以本節的前提是假定為單錶查詢。
跨庫跨表查詢都要根據shard_id進行資料定位。所以有點規模的公司都會有自己的中介軟體，做資料的組裝。
總結資料庫拆分分為垂直拆分和水平拆分。垂直拆分大多是業務層次的拆分，而水平拆分則為同一業務的水平擴充套件。在大多數的情況下應該是這樣：先垂直拆分業務，然後再對業務進行水平拆分。
資料庫分片
隨著網際網路的發展，資料的量級也是指數的增長，從 gb 到tb到 pb。對資料的各種操作也是愈加的困難，傳統的關係性資料庫已經無法滿足快速查詢與插入資料的需求。這個時候 nosql 的出現暫時解決了這一危機。它通過降低資料的安全性，減少對事務的支援，減少對複雜查詢的支援，來獲取效能上的提公升。但是，...
資料庫分片
引用 分片 sharding 是一種與水平切分 horizontal partitioning 相關的資料庫架構模式 將乙個表裡面的行，分成多個不同的表的做法 稱為分割槽 每個區都具有相同的模式和列，但每個表有完全不同的行。同樣，每個分割槽中儲存的資料都是唯一的，並且與其他分割槽中儲存的資料無關。從...
資料庫分片技術
假如您有乙個應用程式，隨著業務越來越有起色，系統所牽涉到的資料量也就越來越大，此時您要涉及到對系統進行伸縮 scale 的問題了。一種典型的擴充套件方法叫做 向上伸縮 scale up 它的意思是通過使用更好的硬體來提高系統的效能引數。而另一種方法則叫做 向外伸縮 scale out 它是指通過增加...