分庫分表方案（一）

當活躍連接配接數量接近或者達到資料庫可以承載的連接配接數量門檻值時将會出現io瓶頸和cpu性能瓶頸，進而導緻上層業務系統的并發量、吞吐量出現問題，甚至導緻系統崩潰。下面我先來說一下造成io瓶頸和cpu性能瓶頸的原因。

cpu瓶頸

當sql語句中含有 join、group by 、 order by 以及非索引字段條件查詢時cpu運算的操作就會增加。除了這種原因外，另一個造成cpu瓶頸的原因是單表資料太多，每次查詢時掃描的資料行太多。

io瓶頸

造成io瓶頸的原因有兩種，一種是熱點資料太多，資料庫緩存太小無法放下，每次查詢都會産生大量磁盤io。一次請求的資料量太大，造成出現大量的網絡io。

水準分表

當系統絕對并發量沒有上來但是單表的資料量太多造成sql效率底下加重cpu負擔，以至于成為瓶頸。這時以字段為依據按照一定政策，将一個表中的資料拆分到多個表中。拆分之後每個表的結構都一樣，但是資料都不一樣沒有交集，表的并集是全量資料。

水準分庫

當系統絕對并發量上來了，并且分表難以根本上解決問題，而且還沒有明顯的業務歸屬。這時就以字段為依據，按照一定政策将一個庫中的資料拆分到多個庫中。拆分之後每個庫的結構都一樣；但是每個庫的資料都不一樣沒有交集，庫的并集是全量資料。

垂直分庫

當系統絕對并發量上來了，而且可以抽象出單獨的業務子產品以表為依據，按照業務歸屬不同，将不同的表拆分到不同的庫中。 拆分之後每個庫的結構都一樣；但是每個庫的資料都不一樣沒有交集，庫的并集是全量資料。

垂直分表

當系統絕對并發量并沒有上來，表的記錄并不多，但是字段多，并且熱點資料和非熱點資料在一起，單行資料所需的存儲空間較大以字段為依據，這時按照字段的活躍性，将表中字段拆到不同的中。拆分之後每個表的結構都不一樣，每個表的資料也不一樣，每個表的字段至少有一列交集，一般是主鍵，用于關聯資料；所有表的并集是全量資料。

這裡先簡單的講解了分庫分表的方案，下一篇文章将詳細講解具體的操作。