主從複製（一主一從，一主多從），主負責寫，從負責讀；
資料複製延遲（1秒到1分鐘都有可能）
即資料寫入到主伺服器後，立刻通過從伺服器進行讀取，此時主機可能還沒有將資料複製到從機（1秒內或大資料量資料同步），導致讀取從機時讀取不到最新的資料；
解決方法：
（1）寫操作後的讀操作傳送給資料庫主伺服器；
（2）讀從失敗後再讀一次主機（二次讀取）；
（3）關鍵業務讀寫操作全部指向主伺服器，非關鍵業務採用讀寫分離；
分配機制
（1）程式**封裝（程式自己封裝資料訪問層）
**tddl（taobao distributed data layer，外號：頭都大了）
（2）中介軟體封裝（資料庫**，客戶端無需改動）
mysql proxy， mysql router（mysql官方推薦），360 atals（基於mysql proxy）、mycat
思考
若能真正做到讀寫分離，可單獨對讀庫進行索引優化和readonly設定，寫庫上減少索引（索引對查詢有優化但影響寫入速度）；
若資料庫讀取速度變慢，應該先考慮：
（1）sql查詢優化（索引優化）、**優化（減少不必要的查詢、減少多次查詢（使用join））；
（2）考慮使用快取（例如redis），若業務過於複雜，可按照2-8原則（最重要的80%只佔20%）優先處理這重要的20%；
（3）資料庫配置調優；
若以上方式都解決不了，再去考慮讀寫分離；
隨著業務的發展，資料量越來越大（千萬甚至上億條），單台資料庫伺服器的儲存能力（10萬使用者量級）已無法支撐（效能瓶頸，讀寫效能下降，資料量太大、索引太大、備份耗時、丟失風險大），需要通過分庫（或分表）將儲存分散到多台資料庫伺服器上；
架構
按照業務模組將資料（table）分散到不同的資料庫伺服器（即將不同業務的表分開放到不同的伺服器上）；
問題
（1）程式需要控制對不同資料庫的訪問（多個資料來源）；
（2）join問題，因為table分散到不同資料庫，所以無法做join查詢，需要多次查詢不同的資料庫後對資料進行組合（可先執行返回結果最少的查詢，後再根據查詢結果繼續查詢其他資料庫，減少每次查詢的引數大小（進而減少每次查詢的結果集大小））；
（3）無法保證事務，需要程式自己控制（回滾）；
（4）成本問題，需要新增伺服器（不適用初創公司，可日後業務發展大好之後再考慮分庫）；
業務繼續發展，即使分庫（百萬或千萬規模）以後，同一業務的單錶資料量的不斷增加也會成為單台資料伺服器的處理瓶頸；
此時就需要對單錶資料進行拆分（垂直分表、水平分表），示意圖如下：
垂直分表
適合將不常用且占用大量空間的列拆分出去，
水平分表
適合單錶行數特別大（當看到單錶資料量超過千萬級別，就需要警覺），將乙個表拆分成多個表（多個表定義完全相同），以提公升訪問效能；
問題：
路由：哪條資料屬於拆分後的哪個子表，需要增加路由演算法進行計算；
（1）範圍路由：建議100萬到2000萬作為分段大小（需結合具體業務），需考慮id生成策略；
（2）hash路由：單列（或多列）hash值運算（例如user_id%5），然後根據hash結果分散到不同資料表中；
（3）配置路由表；
join操作：需join查詢多次後合併結果；
count操作：多次count操作 或 記錄數表（單建一張表，來維護其他每張表（每次新增、修改、刪除後更新）的記錄數）；
order by操作：多次查詢子表資料後彙總排序；
以上分庫分表操作，均需要通過程式**封裝或中介軟體封裝來實現；
資料庫分庫分表
1 基本思想之什麼是分庫分表？從字面上簡單理解，就是把原本儲存於乙個庫的資料分塊儲存到多個庫上，把原本儲存於乙個表的資料分塊儲存到多個表上。2 基本思想之為什麼要分庫分表？資料庫中的資料量不一定是可控的，在未進行分庫分表的情況下，隨著時間和業務的發展，庫中的表會越來越多，表中的資料量也會越來越大，相...
資料庫分庫 分表
分庫的優點是 實現簡單，庫與庫之間界限分明，便於維護，缺點是不利於頻繁跨庫操作，單錶資料量大的問題解決不了。分表的優點是 能解決分庫的不足點，但是缺點卻恰恰是分庫的優點，分表實現起來比較複雜，特別是分表規則的劃分，程式的編寫，以及後期的 資料庫拆分移植維護。實際應用中，一般網際網路企業的路線都是先分...
資料庫分庫分表
簡單了解資料庫分庫分表，以及資料庫的分片 什麼是分庫分表 原本儲存於乙個庫的資料分塊儲存到多個庫上，把原本儲存於乙個表的資料分塊儲存在到多個表上 為什麼分庫分表 當一張表的資料達到幾千萬時，你查詢一次所花的時間會變多，如果有聯合查詢的花，我想啃根會死在那。分表的目的就在於此，減少資料庫的負擔，縮短查...