零、概述
當活躍連線數量接近或者達到資料庫可以承載的連線數量閾值時將會出現io瓶頸和cpu效能瓶頸，進而導致上層業務系統的併發量、吞吐量出現問題，甚至導致系統崩潰。下面我先來說一下造成io瓶頸和cpu效能瓶頸的原因。
cpu瓶頸
當sql語句中含有 join、group by 、 order by 以及非索引字段條件查詢時cpu運算的操作就會增加。除了這種原因外，另乙個造成cpu瓶頸的原因是單錶資料太多，每次查詢時掃瞄的資料行太多。
io瓶頸
造成io瓶頸的原因有兩種，一種是熱點資料太多，資料庫快取太小無法放下，每次查詢都會產生大量磁碟io。一次請求的資料量太大，造成出現大量的網路io。
一、分庫方案
水平分表
當系統絕對併發量沒有上來但是單錶的資料量太多造成sql效率底下加重cpu負擔，以至於成為瓶頸。這時以字段為依據按照一定策略，將乙個表中的資料拆分到多個表中。拆分之後每個表的結構都一樣，但是資料都不一樣沒有交集，表的並集是全量資料。
水平分庫
當系統絕對併發量上來了，並且分表難以根本上解決問題，而且還沒有明顯的業務歸屬。這時就以字段為依據，按照一定策略將乙個庫中的資料拆分到多個庫中。拆分之後每個庫的結構都一樣；但是每個庫的資料都不一樣沒有交集，庫的並集是全量資料。
垂直分庫
當系統絕對併發量上來了，而且可以抽象出單獨的業務模組以表為依據，按照業務歸屬不同，將不同的表拆分到不同的庫中。 拆分之後每個庫的結構都一樣；但是每個庫的資料都不一樣沒有交集，庫的並集是全量資料。
垂直分表
當系統絕對併發量並沒有上來，表的記錄並不多，但是欄位多，並且熱點資料和非熱點資料在一起，單行資料所需的儲存空間較大以字段為依據，這時按照欄位的活躍性，將表中字段拆到不同的中。拆分之後每個表的結構都不一樣，每個表的資料也不一樣，每個表的字段至少有一列交集，一般是主鍵，用於關聯資料；所有表的並集是全量資料。
二、總結
Mysql分庫分表方案
1.為什麼要分表 當一張表的資料達到幾千萬時，你查詢一次所花的時間會變多，如果有聯合查詢的話，我想有可能會死在那兒了。分表的目的就在於此，減小資料庫的負擔，縮短查詢時間。mysql中有一種機制是表鎖定和行鎖定，是為了保證資料的完整性。表鎖定表示你們都不能對這張表進行操作，必須等我對錶操作完才行。行鎖...
mysql分庫分表方案
分庫分表的幾種方式 1 把乙個例項中的多個資料庫拆分到不同的例項 2 把乙個庫中的表分離到不同的資料庫中 3 對乙個庫中的相關表進行水平拆分到不同的例項資料庫中 如何選擇分割槽鍵 1 分割槽鍵要能盡量避免跨分片查詢的發生 2 分割槽鍵要能盡量使各個分片中的資料平均 如何儲存無需分片的表 1 每個分片...
MySQL分庫分表方案
不管是io瓶頸，還是cpu瓶頸，最終都會導致資料庫的活躍連線數增加，進而逼近甚至達到資料庫可承載活躍連線數的閾值。在業務service來看就是，可用資料庫連線少甚至無連線可用。接下來就可以想象了吧 併發量 吞吐量 崩潰 1 io瓶頸 第一種 磁碟讀io瓶頸，熱點資料太多，資料庫快取放不下，每次查詢時...