Web開發系列(十一）：資料庫擴充套件
摘要：
常見的MySQL資料庫擴充套件方式有：
讀寫分離：這種情況適用於讀遠大於寫的情況，讀越多，就可以分出越多的從庫。從庫是隻讀的，主則負責所有的寫入。主和從之間
通過同步binlog完成資料同步。
分表：
當一張表的資料量非常大時，...
- 讀寫分離：這種情況適用於讀遠大於寫的情況，讀越多，就可以分出越多的從庫。從庫是隻讀的，主則負責所有的寫入。主和從之間 通過同步binlog完成資料同步。
-
分表：
- 當一張表的資料量非常大時，我們可以採取對時間，id等進行分表，對錶進行瘦身，從而達到提高讀取/寫入速度的目的，原理 是因為，表更小了，系統維護成本更低，此外對索引的維護成本也會隨之降低，但是缺點是很明顯的，即當需要對所有資料進行查詢時， 查詢的邏輯會變得複雜。這種方案適用於並不需要所有資料的情況，例如使用者的訊息，只需要儲存最近三個月的資料，則可以把三個月 以前的資料從當前表中抽走到其他備份表中。
- 此外分表還有一種方式，例如使用者可能有很多資訊，但是常用的資訊卻只有那麼多，我們可以把常用的資訊放在使用者表，其他的資訊 放在其他表，通過關係把兩個表關聯起來，這樣能加快查詢的原因是可以減少很多不必要的資料查詢，尤其是使用ORM的情況下，ORM 一般都會把所有的資料都拿出來以便進行對映，通過這種方式可以減少資料傳輸量和資料庫維護表的成本。
-
分庫：設想，當一個數據庫的寫入不堪重負時，我們該要如何處理？答案便是將一部分資料搬到另外一個數據庫去，這種方案帶來的好處 是顯而易見的：把對其中一部分的資料的讀和寫都帶走了，可以大大的降低資料庫的負載，但是缺點便是，增加了應用程式的邏輯複雜度， 原本只要在一個數據庫中連表就可以查出來的資料，現在要在不同的資料庫中查詢。
以上三種方案的難度依次遞增，對未來的預測和預留能力要求也是依次遞增。
現在出現了一些新的分散式方案，但是我還沒有試過，所以沒有寫上去，例如MySQL Cluster
和TiDB
。
但是一般來說，合理的安排資料庫的關係，合理的安排索引，合理的安排主從，在業務還沒有達到那個量級之前，根本就不需要使用 更加高階的方案，目前我使用的一張表，合理的安排索引和表的關係，已經達到1.6億行，讀寫分離1帶3，仍然能在10ms內完成查詢。