一.資料庫瓶頸
1.1io瓶頸
第一種：磁碟讀io瓶頸，熱點資料太多，資料庫快取放不下，每次查詢時會產生大量的io -> 分庫和垂直分表
第二種：網路io瓶頸，請求的資料太多，網路頻寬不夠 -> 分庫
1.2cpu瓶頸
第一種：sql問題，如sql中包含join，group by，order by，非索引字段條件查詢等，增加cpu運算的操作 -> sql優化，建立合適的索引，在業務service層進行業務計算。
第二種：單錶資料量太大，查詢時掃瞄的行太多，sql效率低，cpu率先出現瓶頸 -> 水直分表。
二.分表分庫
2.1水平分庫
1. 以字段為依據，按照一定策略(hash、range等)，將乙個庫中的資料拆分到多個庫中。
2. 結果：
每個庫的結構都一樣；
每個庫的資料都不一樣，沒有交集；
所有庫的並集是全量資料；
3.場景：系統絕對併發量上來了，分表難以根本上解決問題，並且還沒有明顯的業務歸屬來垂直分庫。
4.分析：庫多了，io和cpu的壓力自然可以成倍緩解。
2.2水平分表
1.概念：以字段為依據，按照一定策略(hash、range等)，將乙個表中的資料拆分到多個表中。
2.結果：
每個表的結構都一樣；
每個表的資料都不一樣，沒有交集；
所有表的並集是全量資料；
3.場景：系統絕對併發量並沒有上來，只是單錶的資料量太多，影響了sql效率，加重了cpu負擔，以至於成為瓶頸。
4.分析：表的資料量少了，單次sql執行效率高，自然減輕了cpu的負擔。
2.3垂直分庫
1.概念：以表為依據，按照業務歸屬不同，將不同的表拆分到不同的庫中。
2.結果：
每個庫的結構都不一樣；
每個庫的資料也不一樣，沒有交集；
所有庫的並集是全量資料；
3.場景：系統絕對併發量上來了，並且可以抽象出單獨的業務模組。
4.分析：到這一步，基本上就可以服務化了。例如，隨著業務的發展一些公用的配置表、字典表等越來越多，這時可以將這些表拆到單獨的庫中，甚至可以服務化。再有，隨著業務的發展孵化出了一套業務模式，這時可以將相關的表拆到單獨的庫中，甚至可以服務化。
2.3垂直分表
1.概念：以字段為依據，按照欄位的活躍性，將表中字段拆到不同的表(主表和擴充套件表)中。
2.結果：
每個表的結構都不一樣；
每個表的資料也不一樣，一般來說，每個表的字段至少有一列交集，一般是主鍵，用於關聯資料；
所有表的並集是全量資料；
3.場景：系統絕對併發量並沒有上來，表的記錄並不多，但是欄位多，並且熱點資料和非熱點資料在一起，單行資料所需的儲存空間較大。以至於資料庫快取的資料行減少，查詢時會去讀磁碟資料產生大量的隨機讀io，產生io瓶頸。
4.分析：可以用列表頁和詳情頁來幫助理解。垂直分表的拆分原則是將熱點資料(可能會冗餘經常一起查詢的資料)放在一起作為主表，非熱點資料放在一起作為擴充套件表。這樣更多的熱點資料就能被快取下來，進而減少了隨機讀io。拆了之後，要想獲得全部資料就需要關聯兩個表來取資料。但記住，千萬別用join，因為join不僅會增加cpu負擔並且會講兩個表耦合在一起(必須在乙個資料庫例項上)。關聯資料，應該在業務service層做文章，分別獲取主表和擴充套件表資料然後用關聯字段關聯得到全部資料。
三.分表分庫的工具
sharding-sphere：jar，前身是sharding-jdbc；
tddl：jar，taobao distribute data layer；
mycat：中介軟體。
本文只介紹mycat工具。
3.1mycat簡介
mycat的配置檔案都在conf目錄裡面，這裡介紹幾個常用的檔案：
mycat的架構其實很好理解，mycat是**，mycat後面就是物理資料庫。和web伺服器的nginx類似。對於使用者來說，訪問的都是mycat，不會接觸到後端的資料庫。
我們現在做乙個主從、讀寫分離，簡單分表的示例。結構如下圖：
schema.xml是最主要的配置項，首先看我的配置檔案。
select user();
select user();
說明：
資料庫分表分庫：
配置如下：
select user();
select user();
我在192.168.0.3、192.168.0.4均有資料庫lunch。
lunchmenu、restaurant、userlunch、users這些表都只寫入節點dn1，也就是192.168.0.3這個服務，而dictionary寫入了dn1、dn2兩個節點，也就是192.168.0.3、192.168.0.4這兩台伺服器。分片的規則為：mod-long。
主要關注rule屬性，rule屬性的內容**於rule.xml這個檔案，mycat支援10種分表分庫的規則，基本能滿足你所需要的要求，這個必須贊乙個，其他資料庫中介軟體好像都沒有這麼多。
table中的rule屬性對應的就是rule.xml檔案中tablerule的name,具體有哪些分表和分庫的實現，建議還是看下文件。我這裡選擇的mod-long就是將資料平均拆分。因為我後端是兩台物理庫，所以rule.xml中mod-long對應的function count為2，見下面部分**：
idmod-long
資料庫讀寫分離
select user();
3.2my的使用
##啟動
mycat start
##停止
mycat stop
##重啟
mycat restart
MySQL範圍分表分庫 mysql 分表分庫策略
唯一id的生成 下面列舉幾種常見的唯一id生成方案，需要滿足兩大核心需求 1.全域性唯一 2趨勢有序 1.用資料庫的auto increment 自增id 來生成，每次通過寫入資料庫一條記錄，利用資料庫id自增的特性獲取唯一，有序的id。優點 使用資料庫原有的功能，相對簡單 能夠保證唯一 能夠保證遞...
mysql 分庫分表實戰 MySQL分庫分表實戰
為什麼要分庫分表 在大型 中，當使用者量以及使用者產生的業務資料量達到單庫單錶效能極限時，為了支撐業務可持續發展，對於重要的核心業務必然要進行分庫分表來儲存業務資料。對於非核心業務產生的大量資料，例如爬蟲爬取的資訊，論壇產生的資料等，可以考慮把資料儲存在像mongodb這樣的nosql儲存裡面，這些...
mysql分庫分表備份 mysql分庫分表備份
一 單獨備份資料庫 mysqldump uroot poldboy oldboy opt oldboy.sql 最簡單的備份 1 mysql基於myisam引擎 mysqldump uroot poldboy b x f oldboy gzip opt oldboy.sql.gz 2 5.5以後預設...