1、MYCAT最佳實踐支持1000億大數據中國第一開源分布式數據庫中間件MYCAT的原理分表分庫Mysql2Mysql1分片原則與限制每個分片的記錄量為1000萬左右，分片數量是雙刃劍，不易過多分片字段不支持多個字段的組合原則上以最頻繁查詢的字段為分片字段，分片字段不能改變值，分片字段的選擇很大程度上影響系統性能非分片字段的查詢語句，會并發發送到每個分片上去，導致資源消耗更多非范圍分片，擴容難度大，一致性Hash也只是做出了一定的改善分片導致某些SQL語句的執行結果不符合預期，可以視為不支持分片產生了跨分片排序和分組統計等問題分片產生了表關聯問題分片產生了分布式事務問題MYCAT目前不能支持的SQ

2、LInsert into values( xxxx)Insert into b select * from aSelect * from a where partionCol like “xxxx”Select * from b where pationCol 4 and pationC between Lock table a Select * from a for update - /*!mycat: sql = update a */ 任意的分片表的Join語句Select a from A order by bselect count(*) from A group by bSelec

3、t distinct a.* from a 存儲過程中有輸出參數的，目前不支持MYCAT注解方式解決特殊分片SQL路由問題對于一個特殊的復雜SQL，Mycat的語法解析器如果解析失敗，無法通過，則可以通過注解方式“偷梁換柱”，從而基本解決這一問題Select * from a for update /*!mycat: sql = update a */ Select * from a for update 跨分片JOIN的幾種策略關聯字段采用相同的分片規則ER關系分片全局表編程方案： Catlet或自行處理任意兩個分片表JION目前業界并沒有很好的通用性解決方案，所以要盡可能避免大量在線的JO

4、IN SQL，而是采用后臺預先定期計算并存儲結果的方式Catlet是Java編寫的一段程序，類似數據庫中的存儲過程，可以實現任意復雜SQL的Join、Group、Order等功能MYCAT ER分片DN1DN2MycatCustomer1Customer100Customer1Customer100Custermer1 - Order1Cutermer100 - Order4Custermer1 - Order2Custermer100 - Order 3Order1Order2Order3Order4存在關聯關系的父子表在數據插入的過程中，子表會被Mycat路由到其相關父表記錄的節點上，從而

5、父子表的Join查詢可以下推到各個數據庫節點上完成，這是最高效的跨節點Join處理技術，也是Mycat首創MYCAT全局表ordershost1ordershost2ordershost3ordershost4insert into orders (xxx)Mycat每個節點同時并發插入和更新數據，每個節點都可以讀取數據，提升讀性能的同時解決跨 節點Join的效率全局表的建議和限制全局表記錄數在1000萬以內更新頻率低常見如用戶、商戶、商品等建議把變動頻率高的字段從全局表剝離全局表目前是采用弱XA事務，存在局部失敗的可能性MYCAT分布式事務問題XA分布式事務產生的代價較大，互聯網領域多傾向于

6、抵制MySQL 直到5.7的某個版本，才修復了一直以來的XA缺陷，即binlog不寫prepare日志，導致主從數據可能不一致Mycat目前沿用了Cobar的弱XA事務模型Mycat 2.0計劃實現標準的事務，供應用自行決定使用當一個普通事務內的SQL被路由到多個節點上去執行時，就產生了分布式事務問題弱模型update sqlDN1DN2DN3commit任意錯誤回滾標志只能ollback在Update SQL執行成功的情況下，隨后的Commit失敗的概率非常小因此此模型還是能滿足大多少應用的要求MYCAT讀寫分離和自動切換機制Mycat 支持基于MySQL主從復制狀態的高級讀寫分離控制機制，

7、比如 Slave_behind_master 100則開啟，而一旦檢測到主從同步出錯或者延時超過發展，則自動排除readHost，防止程序讀到很久的舊數據MYCAT的高可靠業務數據存儲方案MycatGalera clusterMysql Master/SlaveNoSQL多主同時寫入，高可靠性，適合系統中的關鍵表帳務表、訂單表等用戶表、字典表、常規數據日志類的數據主從故障切換，可能有數據丟失的問題存儲大量一次性非業務數據ClientOne SchemaMYCAT生產案例超過300個案例某電信領域海量交易數據實時查詢案例分析每天2億交易數據，保持最近一個月內的交易數據主要查詢條件為某天（某幾天）

8、某個交易手機號的交易記錄查詢時間要求3秒內返回結果MYCAT方案采用交易時間字段進行分片，分片規則為日期范圍分片，每小時一個分片，總共24*31=744個分片，保存了31天的記錄，744個分片均勻分布在4臺X86服務器上，月末手工清理（轉移歷史數據），手機號建立索引數據庫用InnoDBMYCAT方案系統實際的查詢響應時間平均小于1秒研究了MySQL內存表與InnoDB兩種引擎，結果表明，大多數情況下InnoDB是比較理想的選擇，內存表對內存的要求很高，而且不太合適查詢同時有大量的插入/更新操作的場景此方案具有很強的代表性，意味著當前很多SQL緩存數據庫記錄的方案都可以用MyCAT簡單可靠替換。

9、大內存調優關鍵wrapper.java.additional.3=-XX:MaxPermSize=64Mwrapper.java.additional.4=-XX:+AggressiveOptswrapper.java.additional.5=-XX:MaxDirectMemorySize=2Gwrapper.java.additional.6=-Dcom.sun.management.jmxremotewrapper.java.additional.7=-Dcom.sun.management.jmxremote.port=1984wrapper.java.additional.8=-Dc

10、om.sun.management.jmxremote.authenticate=falsewrapper.java.additional.9=-Dcom.sun.management.jmxremote.ssl=falsewrapper.java.additional.10=-Xmx4Gwrapper.java.additional.11=-Xms1G當有超過8G可用內存時候，建議大部分分配給XX:MaxDirectMemorySize，比如比如16G，而，而Xmx與與Xms則在則在4G左右左右MaxDirectMemorySize的大部分，比如的大部分，比如90%，分配給，分配給Mycat

11、的網絡堆內存，為的網絡堆內存，為system.xml中的以下兩個參數：中的以下兩個參數：processorBufferPool，單位字節，建議設置為 MaxDirectMemorySize的的90%左右，比如左右，比rocessorBufferChunk，BufferPool里單元大小，默認里單元大小，默認4096字節字節于于是總共有是總共有processorBufferPool/ processorBufferChunk 個單元格個單元格 ：即：/4096= 3774873 個單元格個單元格單元單元格越多，通常性能越好，可以在管理端口格越多，通常性能越好，可以在管理端口(