從字面上看，就是簡單地把原來存儲在壹個庫中的數據存儲到多個庫中，把原來存儲在壹個表中的數據存儲到多個表中。
2為什麽要把基本思想分為庫和表？
數數
根據庫中的數據不壹定是可控的，在沒有子庫和子表的情況下，隨著時間和業務的發展，庫中的表會越來越多，表中的數據量也會越來越大。相應的，數據操作也會增加。
刪除和修改搜索的成本也會增加；此外，由於無法分配部署，以及服務器的資源(CPU、磁盤、內存、IO等。)是有限的，最終數據庫可以承載的數據量，
數據處理能力將遇到瓶頸。
3子數據庫和子表的實現策略
子數據庫和子表有兩種:縱向分割和橫向分割。
3.1
什麽是垂直細分？它意味著將表劃分為功能模塊和緊密關系，並將它們部署到不同的庫中。比如我們會建立定義數據庫workDB，商品數據庫payDB，用戶數據。
庫userDB和日誌數據庫logDB分別用於存儲項目數據定義表、商品定義表、用戶數據表和日誌數據表。
3.2
什麽是橫向分段？當壹個表的數據量過大時，我們可以按照壹定的規則，比如userID hash，對表的數據進行劃分，然後存儲在多個結構相同、庫不同的表中。
走吧。比如我們的userDB中的用戶數據表，每個表的數據量都很大，所以我們可以把userDB分成幾個結構相同的userDB:part 0 db，
Part1DB等。，然後把userDB上的用戶數據表userTable分成很多userTable:userTable0，userTable1等。
然後這些表按照壹定的規則存儲在多個userDB上。
3.3數據庫子數據庫和子表應該用哪種方法實現取決於數據庫中數據量的瓶頸和項目的業務類型。
如果數據庫中的表太多，項目的業務邏輯劃分清晰、耦合性差，那麽規則簡單、易於實現的垂直分段壹定是首選。
但是
如果數據庫中的表不多，但是單個表的數據量很大或者數據比較熱，這種情況下，應該選擇水平分段。橫向分割比縱向分割更復雜，邏輯上會屬於壹個。
除了評估分段的粒度，考慮數據平均和負載平均，還會在後期給項目人員和應用帶來額外的數據管理負擔。
在現實項目中，往往是這兩種情況都有，需要權衡，甚至是縱向分割和橫向分割。我們的遊戲項目使用垂直和水平分段的組合。我們先對數據庫進行垂直分段，然後對壹些表進行水平分段，通常是用戶數據表。
4.子數據庫和子表存在的問題。
4.1交易問題。
子數據庫和子表實現後，由於數據存儲在不同的數據庫中，數據庫事務管理比較困難。如果依靠數據庫本身的分布式事務管理功能來執行事務，將會付出很高的性能代價；如果應用程序輔助控制，就會形成程序的邏輯事務，也會造成編程的負擔。
4.2跨數據庫跨表連接問題。
實行分庫分表後，很難避免將邏輯相關性強的數據劃分到不同的表和不同的庫中。這時候表的關聯操作就會受到限制，不能連接位於不同子數據庫的表，也不能連接不同粒度的表。因此，壹次查詢即可完成的業務可能需要多次查詢。
4.3額外的數據管理負擔和數據操作壓力。
額
外部數據管理負擔，最明顯的是數據定位和重復執行數據添加、刪除和查詢的問題，這些都可以通過應用程序來解決，但必然會導致額外的邏輯操作，例如，對於
壹個記錄用戶成績的用戶數據表userTable，業務要求找出最好的100位，分表前只需要壹個訂單。
By語句可以完成，但是在表被劃分後，就需要N個order。
通過語句，找出每個子表的前100個用戶數據，然後將這些數據組合起來得到結果。