爲甚分庫分表？
先集羣：主從，且讀寫分離。
分表：數據量過大 查詢慢 鎖事物衝突。一般先垂直分，再考慮水平分
分庫：機器的寫壓力大，併發量數千級別，讀壓力大，太多slave
分庫分表後：降低磁盤使用率 單表數據量少 併發衝突低
主備延遲的原因： 機器性能不均衡 使用不均衡 大事物 沒有開啓並行同步 確實寫入併發過大
主從複製延遲解決：show status查看 Seconds_Behind_Master，可以看到從庫複製主庫的數據落後了幾 ms
8個方案：
從庫機器性能差，可以增加機器性能，或者多從
打開MySQL的並行複製：多個庫並行複製。某個庫的寫入併發就是特別高時無意義
開啓半同步複製：拉取binlog日誌要是多線程的
業務：
代碼修改：業務控制，插入後不要立刻查詢，等待後查詢
避免大事物：避免刪除大量數據；建立合適的索引，減少衝突；
使用不均衡，讀多寫少時，可以把部分讀放到主庫
必須先插入，立馬要求就查詢到：對主查詢設置直連主庫
分庫：一個主庫拆分爲多個主庫，每個主庫的寫併發就減少了幾倍，降低延遲
分庫分表的技術方案，比如：
mycat：中間件，代碼無需修改。通過改寫與轉發sql，然後彙總結果後返回給客戶端。
shading-jdbc：jar包，代碼需要修改。client層方案的優點在於不用部署，運維成本低，不需要代理層的二次轉發請求，性能很高，升級的話需要修改系統。
優缺點對比：mycat需要單獨部署與運維。sharding-jdbc,需要修改代碼。
分庫分表引入問題：
1）分佈式全局唯一id snowflake+mysqlIndex
2）分庫規則和策略
3）跨庫查詢問題
4）跨庫事物問題，即分佈式事務
跨庫join解決：
1）全局表，表重複，需要開啓全局表一致性檢測，配置全局表。
2）share join，簡單的跨分片join；如mycat，自動sql拆分查詢，並彙總結果
3）ER join，子表的記錄與所關聯的父表記錄存放在同一個數據分片上，從而解決跨庫join的問題
Federal引擎 或 帶上庫名
mycat和shading-jdbc：https://www.cnblogs.com/leeSmall/p/9539370.html
比較全的分庫分表： https://blog.csdn.net/qq_36625757/article/details/90477131
mycat分頁中的坑：LIMIT 1000100, 100;，他會查出所有取後幾條，解決：先查id，再根據id查詢具體記錄
不同分表方式的查詢
sharding jdbc方式：
按照訂單hash分表
按照訂單查詢：查詢的時候直接按照hash查詢對應表
按照用戶查詢訂單：建立訂單號和用戶的關係表，先根據用戶獲取對應的訂單號，然後查詢。
mycat方式
mycat分表的實現：首先在mycat的scheme.xml中配置邏輯表，並且在配置中說明此表在哪幾個物理庫上。此邏輯表的名字與真實數據庫中的名字一致！然後需要配置分片規則，即按照什麼邏輯分庫！
推薦:通過改寫與轉發sql，然後彙總結果後返回給客戶端。