水平分庫：當資料量巨大時，將資料放到不同的表中，比如表1，表2，表3，...；
垂直分庫：當一張表的字段太多，可拆分出一張或多張分表，根據主鍵唯一標示；
新理解：
垂直分庫：當一張表中字段不多，當某些字段長度過長，表占用空間很大，檢索表的時候需要執行大量的io（資料庫檢索的本質是對硬碟中的檔案進行io訪問），
此時可以考慮對長度較長的字段進行拆分，單獨成表，用原表主鍵進行唯一標示。
相反：當資料庫記錄數不多，但字段較多，可對部分字段進行整合，比如使用者的資訊（**，手機號...），以json字串的形式儲存到資料庫，這樣一目了然，代價就是service層中要對json進行但多解析。
如何取捨，看專案需求。
2017.05.25
補充：垂直拆分：以某些標準，將單個表拆分成多個表.
水平拆分：水平拆分行，行資料拆分到不同表中， 垂直拆分列，表資料拆分到不同表中.
以上所謂的概念標準都只是一種描述，其實更多的是一種思想，千萬不能被以上概念影響，理解教條化.
什麼是垂直分庫分表，水平分庫分表
垂直分片 按照業務拆分的方式稱為垂直分片，又稱為縱向拆分，它的核心理念是專庫專用。在拆分之前，乙個資料庫由多個資料表構成，每個表對應著不同的業務。而拆分之後，則是按照業務將表進行歸類，分布到不同的資料庫中，從而將壓力分散至不同的資料庫。下圖展示了根據業務需要，將使用者表和訂單表垂直分片到不同的資料庫...
資料庫水平分庫的一些個人理解
說實話我以前還從未接觸過資料庫分庫這一類的知識，以前我所做的一些 都是一些訪問量較小，無需分庫的那一類。但是最近在公司實習，需要改版乙個以前的專案，由於使用者量較大因此必須用到分庫。我自己在往上查了一下關於水平分庫的一些資料，但大多都是一些講什麼是水平分庫，以及它的一些好處，至於如何具體分庫倒沒怎麼...
資料庫之分庫分表 垂直？水平？
原文 資料庫之分庫分表 垂直？水平？不管是io瓶頸，還是cpu瓶頸，最終都會導致資料庫的活躍連線數增加，進而逼近甚至達到資料庫可承載活躍連線數的閾值。在業務service來看就是，可用資料庫連線少甚至無連線可用。接下來就可以想象了吧 併發量 吞吐量 崩潰 第一種 磁碟讀io瓶頸，熱點資料太多，資料庫...