1、什麼是分庫分表
就是把原本存儲於一個庫的數據分塊存儲到多個庫上，把原本存儲於一個表的數據分塊存儲到多個表上。
2、爲什麼分庫分表
數據庫中的數據量不一定是可控的，在未進行分庫分表的情況下，隨着時間和業務的發展，庫中的表會越來越多，表中的數據量也會越來越大，相應地，數據操作，增刪改查的開銷也會越來越大；另外，由於無法進行分佈式式部署，而一臺服務器的資源（CPU、磁盤、內存、IO等）是有限的，最終數據庫所能承載的數據量、數據處理能力都將遭遇瓶頸。
3、分庫分表的實施策略
分庫分表有垂直切分和水平切分兩種。
垂直切分，即將表按照功能模塊、關係密切程度劃分出來，部署到不同的庫上。例如，我們會建立定義數據庫workDB、商品數據庫payDB、用戶數據庫userDB等，分別用於存儲項目數據定義表、商品定義表、用戶數據表等。
水平切分，當一個表中的數據量過大時，我們可以把該表的數據按照某種規則，例如userID散列，進行劃分，然後存儲到多個結構相同的表，和不同的庫上。例如，我們的userDB中的用戶數據表中，每一個表的數據量都很大，就可以把userDB切分爲結構相同的多個userDB：part0DB、part1DB等，再將userDB上的用戶數據表userTable，切分爲很多userTable：userTable0、userTable1等，然後將這些表按照一定的規則存儲到多個userDB上。
應該使用哪一種方式來實施數據庫分庫分表，這要看數據庫中數據量的瓶頸所在，並綜合項目的業務類型進行考慮。
如果數據庫是因爲表太多而造成海量數據，並且項目的各項業務邏輯劃分清晰、低耦合，那麼規則簡單明瞭、容易實施的垂直切分必是首選。
而如果數據庫中的表並不多，但單表的數據量很大、或數據熱度很高，這種情況之下就應該選擇水平切分，水平切分比垂直切分要複雜一些，它將原本邏輯上屬於一體的數據進行了物理分割，除了在分割時要對分割的粒度做好評估，考慮數據平均和負載平均，後期也將對項目人員及應用程序產生額外的數據管理負擔。
面對數據遞增，解決方案通常是分庫分表，冷熱數據分離
垂直拆分——主要是字段的拆分
水平拆分——表結構不變，數據分表
4、分庫分表常用的原理策略
結合兩種原理策略，主要講解分別使用上述原理的兩個框架
Mycat
mycat是一箇中間件代理層，對研發無感知
1、一個徹底開源的，面向企業應用開發的大數據庫集羣
2、支持事務、ACID、可以替代MySQL的加強版數據庫
3、一個可以視爲MySQL集羣的企業級數據庫，用來替代昂貴的Oracle集羣
4、一個融合內存緩存技術、NoSQL技術、HDFS大數據的新型SQL Server
5、結合傳統數據庫和新型分佈式數據倉庫的新一代企業級數據庫產品
6、一個新穎的數據庫中間件產品
優點：
1、開發無感知
2、增刪節點程序不需要重啓
3、跨語言（java 、php）
缺點：
1、性能下降沒因爲多了一層
2、不支持跨數據庫
MyCat經典實用場景
單純的讀寫分離，此時配置最爲簡單，支持讀寫分離，主從切換
分表分庫，對於超過1000 萬的表進行分片，最大支持1000 億的單表分片
多租戶應用，每個應用一個庫，但應用程序只連接Mycat，從而不改造程序本身，實現多租戶化
報表系統，藉助於Mycat的分表能力，處理大規模報表的統計
替代Hbase，分析大數據作爲海量數據實時查詢的一種簡單有效方案，比如100 億條頻繁查詢的記錄需要在3 秒內查詢出來結果，
除了基於主鍵的查詢，還可能存在範圍查詢或其他屬性查詢，此時Mycat 可能是最簡單有效的選擇
mycat的使用對研發是無感知的，但是運維成本較大，涉及到一些概念
邏輯庫(sehema)，邏輯表(table)，配置分片（dataNode），配置物理庫分片映射（dataHost）
我們需要了解一點，集中式的Proxy其實現非常複雜，這要從MySQL處理SQL語句的原理說起，因爲不是本文要論述的重點，因此只是簡單的提及幾點：
-
SQL語句要被Parser解析成抽象語法樹
-
SQL要被優化器解析出執行計劃
-
SQL語句完成解析後，發給存儲引擎
只要有解析的過程，其性能損耗就是比較可觀的，我們也可以認爲這是一種重量級的解決方案。
ShardingJdbc
官網 http://shardingsphere.apache.org/index_zh.html
定位爲輕量級Java框架，在Java的JDBC層提供的額外服務。 它使用客戶端直連數據庫，以jar包形式提供服務，無需額外部署和依賴，可理解爲增強版的JDBC驅動，完全兼容JDBC和各種ORM框架。
1、適用於任何基於JDBC的ORM框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC。
2、支持任何第三方的數據庫連接池，如：DBCP, C3P0, BoneCP, Druid, HikariCP等。
3、支持任意實現JDBC規範的數據庫。目前支持MySQL，Oracle，SQLServer，PostgreSQL以及任何遵循SQL92標準的數據庫。
優點：
1、性能很好的
2、支持跨數據庫jdbc
缺點：
1、增加了開發難度
2、不支持跨語言（java）
ShardingJdbc是ShardingSphere中關於jdbc增強方式的一種，而且ShardingSphere已經孵化爲apache頂級項目
每一個服務都持有一個Sharing-JDBC，這個JDBC以Jar包的形式提供，基本上可以認爲是一個增強版的jdbc驅動，需要一些分庫分表的配置，業務開發人員不需要去對代碼進行任何的修改。可以很輕鬆的移植到SpringBoot，ORM等框架上
但是這個結構也不是完美的，每一個服務持有一個proxy意味着會在MySQL服務端新建大量的連接，維持連接會增加MySQL服務器的負載，雖然這種負載提升一般無法察覺。
shardingjdbc中涉及到基礎概念
邏輯表、真實表、數據節點——每張真實表
邏輯表
即水平拆分的表的總稱。比如訂單業務會被拆分成t_order0，t_order1兩張表，但是他們同屬於一個邏輯表：t_order
綁定表
分片規則一直的主表和子表。比如還是上面的t_order表，其分片鍵是order_id，其子表t_order_item的分片鍵也是order_id。在規則配置時將兩個表配置成綁定關係，就不會在查詢時出現笛卡爾積。
廣播表
有一些表是沒有分片的必要的，比如省份信息表，全國也就30多條數據，這種表在每一個節點上都是一樣的，這種表叫做廣播表。
簡單來說
1）mycat是一箇中間件的第三方應用，sharding-jdbc是一個jar包
2）使用mycat時不需要改代碼，而使用sharding-jdbc時需要修改代碼
5、關於分表策略通常分爲三種
1、取模
2、範圍分表-通常是時間
3、城市-有明顯業務特徵的分表
時間範圍策略通常用於冷熱數據分離，例如美團限查近3個月的訂單，量體比較大，而且歷史數據使用相對較少
城市這種分表策略，類似於多租戶的概念，業務處理場景一樣，但是數據獨立
總結
主要是簡單介紹下什麼是分庫分表，分庫分表的實施策略，以及分庫分表通用原理。研究這些內容，主要是公司業務數據增長速度過快，單表數據過於龐大，而且如果只做冷熱數據分離不夠友好，而且不能解決目前業務的發展問題，打算利用分表來實現，而且結合自身業務以及兩種框架原理，本着符合業務場景，可靠度高，接入成本低，具有良好的文檔，活躍的社區的原則，打算採用shardingJdbc，涉及到分表策略選擇使用城市的維度。