垂直分表
垂直分表在日常開發和設計中比較常見，通俗的說法叫做「大表拆小表」，拆分是基於關係型資料庫中的「列」（字段）進行的。通常情況，某個表中的字段比較多，可以新建立一張「擴充套件表」，將不經常使用或者長度較大的字段拆分出去放到「擴充套件表」中，如下圖所示：
小結在字段很多的情況下，拆分開確實更便於開發和維護,。某種意義上也能避免「跨頁」的問題（mysql、mssql底層都是通過「資料頁」來儲存的，「跨頁」問題可能會造成額外的效能開銷
拆分欄位的操作建議在資料庫設計階段就做好。如果是在發展過程中拆分，則需要改寫以前的查詢語句，會額外帶來一定的成本和風險，建議謹慎。
垂直分庫
基本的思路就是按照業務模組來劃分出不同的資料庫，而不是像早期一樣將所有的資料表都放到同乙個資料庫中。如下圖：
小結系統層面的「服務化」拆分操作，能夠解決業務系統層面的耦合和效能瓶頸，有利於系統的擴充套件維護。而資料庫層面的拆分，道理也是相通的。與服務的「治理」和「降級」機制類似，我們也能對不同業務型別的資料進行「分級」管理、維護、監控、擴充套件等。
水平分表
水平分表也稱為橫向分表，比較容易理解，就是將表中不同的資料行按照一定規律分布到不同的資料庫表中（這些表儲存在同乙個資料庫中），這樣來降低單錶資料量，優化查詢效能。最常見的方式就是通過主鍵或者時間等字段進行hash和取模後拆分。如下圖所示：
小結水平分表，能夠降低單錶的資料量，一定程度上可以緩解查詢效能瓶頸。但本質上這些表還儲存在同乙個庫中，所以庫級別還是會有io瓶頸。所以，一般不建議採用這種做法。
水平分庫分表
水平分庫分表與上面講到的水平分表的思想相同，唯一不同的就是將這些拆分出來的表儲存在不同的資料中。這也是很多大型網際網路公司所選擇的做法。如下圖：
某種意義上來講，有些系統中使用的「冷熱資料分離」（將一些使用較少的歷史資料遷移到其他的資料庫中。而在業務功能上，通常預設只提供熱點資料的查詢），也是類似的實踐。在高併發和海量資料的場景下，分庫分表能夠有效緩解單機和單庫的效能瓶頸和壓力，突破io、連線數、硬體資源的瓶頸。當然，投入的硬體成本也會更高。同時，這也會帶來一些複雜的技術問題和挑戰（例如：跨分片的複雜查詢，跨分片事務等）
跨庫join的問題
按業務拆分資料庫之後，不可避免的就是「分布式事務」的問題。以往在**中通過spring註解簡單配置就能實現事務的，現在則需要花很大的成本去保證一致性。
oltp與olap的介紹
資料處理大致可以分成兩大類：聯機事務處理oltp（on-line transaction processing）、聯機分析處理olap（on-line analytical processing）。oltp是傳統的關係型資料庫的主要應用，主要是基本的、日常的事務處理，例如銀行交易。olap是資料倉儲系統的主要應用，支援複雜的分析操作，側重決策支援，並且提供直觀易懂的查詢結果。
oltp 系統強調資料庫記憶體效率，強調記憶體各種指標的命令率，強調繫結變數，強調併發操作； olap 系統則強調資料分析，強調sql執行市場，強調磁碟i/o，強調分割槽等。
人家的
分表和表分割槽詳解
為什麼要分表和分割槽？日常開發中我們經常會遇到大表的情況，所謂的大表是指儲存了百萬級乃至千萬級條記錄的表。這樣的表過於龐大，導致資料庫在查詢和插入的時候耗時太長，效能低下，如果涉及聯合查詢的情況，效能會更加糟糕。分表和表分割槽的目的就是減少資料庫的負擔，提高資料庫的效率，通常點來講就是提高表的增刪改...
MySQL分割槽和分表
1.分割槽的型別 1 range 把連續區間按範圍劃分 例 create table user id int 11 money int 11 unsigned not null,date datetime partition by range year date partition p2014 va...
mysql分表和表分割槽詳解
為什麼要分表和分割槽？日常開發中我們經常會遇到大表的情況，所謂的大表是指儲存了百萬級乃至千萬級條記錄的表。這樣的表過於龐大，導致資料庫在查詢和插入的時候耗時太長，效能低下，如果涉及聯合查詢的情況，效能會更加糟糕。分表和表分割槽的目的就是減少資料庫的負擔，提高資料庫的效率，通常點來講就是提高表的增刪改...