分庫拆表：
好處：1. 資料庫容量問題；
2. 解決效能壓力的最優選擇；
原則：反正規化資料結構設計，所謂反正規化，第一要點是不用外來鍵，不允許join 操作，不允許任何需要跨越兩個表的查詢請求；第二要點是適度冗餘減少查詢請求。
分庫方案：
1. 安全性拆分
將高安全性資料與低安全性資料分庫，這樣的好處第一是便於維護，第二是 高安全性資料的資料庫引數配置可以以安全優先，而低安全性資料的引數配置以效能優先。
2. 基於業務邏輯拆分
基於業務邏輯拆分，可以減少前端應用請求傳送到不同資料庫伺服器的頻次，從而減少鏈結開銷，便於日常維護和前端呼叫；
3. 基於負載壓力拆分
基於負載壓力對資料結構拆分，便於直接將負載分擔給不同的伺服器。
基於負載壓力拆分，可能拆分後的資料庫包含不同業務型別的資料表，日常 維護會有一定的煩惱
分表：資料量過大或者訪問壓力過大的資料表需要切分
忙閒分表
單資料表字段過多，可將頻繁更新的整數資料與非頻繁更新的字串資料切分
橫向切表
a. 等分切表，如雜湊切表或其他基於對某數字取餘的切表。等分切表的優點是 負載很方便的分布到不同伺服器；缺點是當容量繼續增加時無法方便的擴容， 需要重新進行資料的切分或轉表。而且一些關鍵主鍵不易處理。
b. 遞增切表，比如每 1kw 使用者開乙個新錶，優點是可以適應資料的自增趨勢； 缺點是往往新資料負載高，壓力分配不平均。
c. 日期切表，適用於日誌記錄式資料，優缺點等同於遞增切表。
熱點資料分表
將資料量較大的資料表中將讀寫頻繁的資料抽取出來，形成熱點資料表。通常乙個龐大資料表經常被讀寫的內容往往具有一定的集中性，如果這些集中資料單獨處理，就會極大減少整體系統的負載。
熱點資料表與舊有資料關係:
a. 可以是一張冗餘表，即該錶資料丟失不會妨礙使用，因源資料仍存在於 舊有結構中。優點是安全性高，維護方便，缺點是寫壓力不能分擔，仍 需要同步寫回原系統。
b. 可以是非冗餘表，即熱點資料的內容原有結構不再儲存，優點是讀寫效 率全部優化；缺點是當熱點資料發生變化時，維護量較大。
c. 具體方案選擇需要根據讀寫比例決定，在讀頻率遠高於寫頻率情況下，優先考慮冗餘表方案。
主從架構：
1. 讀寫分離對負載的減輕遠遠不如分庫分表來的直接；
2. 寫壓力會傳遞給從表，唯讀從庫一樣有寫壓力，一樣會產生讀寫鎖！
3. 主從延遲也是重大問題。一旦有較大寫入問題，如表結構更新，主從會產生巨大 延遲。
mysql優化：
建索引的原則：
1.最左字首匹配原則，非常重要的原則，mysql會一直向右匹配直到遇到範圍查詢(>、<、between、like)就停止匹配，比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)順序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引則都可以用到，a,b,d的順序可以任意調整。
2.=和in可以亂序，比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意順序，mysql的查詢優化器會幫你優化成索引可以識別的形式
3.盡量選擇區分度高的列作為索引,區分度的公式是count(distinct col)/count(*)，表示欄位不重複的比例，比例越大我們掃瞄的記錄數越少，唯一鍵的區分度是1，而一些狀態、性別字段可能在大資料面前區分度就是0，那可能有人會問，這個比例有什麼經驗值嗎？使用場景不同，這個值也很難確定，一般需要join的字段我們都要求是0.1以上，即平均1條掃瞄10條記錄
4.索引列不能參與計算，保持列「乾淨」，比如from_unixtime(create_time) = 』2014-05-29』就不能使用到索引，原因很簡單，b+樹中存的都是資料表中的字段值，但進行檢索時，需要把所有元素都應用函式才能比較，顯然成本太大。所以語句應該寫成create_time = unix_timestamp(』2014-05-29』);
5.盡量的擴充套件索引，不要新建索引。比如表中已經有a的索引，現在要加(a,b)的索引，那麼只需要修改原來的索引即可
慢查詢優化步驟：
1. 先從單個表where條件後，返回記錄數最小的表查起；
2. order by limit 形式的sql語句讓排序的表優先查；
3. explain檢視執行計畫，是否與1預期一致（從鎖定記錄較少的表開始查詢）；
4. 根據建索引的原則，新增索引
mysql 分庫分表 開源 MySQL優化分庫分表
昨天面試新人的時候，遇到了這麼乙個問題，按照自己的想法大體聊了一些，但大多是感性的，並沒有完整的了解why and how.之一，為什麼要分表？分表，按形式，有水平分表和主附分表。水平分表常見於按id取模或者按日期將相同表結構的內容雜湊到不同的表上，主附分表常見於有對應關係的多張表，通過主外來鍵進行...
mysql分表分庫實現 MySql分表分庫思路
一.資料庫瓶頸 1.1io瓶頸 第一種 磁碟讀io瓶頸，熱點資料太多，資料庫快取放不下，每次查詢時會產生大量的io 分庫和垂直分表 第二種 網路io瓶頸，請求的資料太多，網路頻寬不夠 分庫 1.2cpu瓶頸 第一種 sql問題，如sql中包含join，group by，order by，非索引字段條...
MySQL範圍分表分庫 mysql 分表分庫策略
唯一id的生成 下面列舉幾種常見的唯一id生成方案，需要滿足兩大核心需求 1.全域性唯一 2趨勢有序 1.用資料庫的auto increment 自增id 來生成，每次通過寫入資料庫一條記錄，利用資料庫id自增的特性獲取唯一，有序的id。優點 使用資料庫原有的功能，相對簡單 能夠保證唯一 能夠保證遞...