Mycat配置怎么设置读写分离？mycat配置详解与优化

MyCat配置的本质是数据路由策略的声明式落地，配置好坏的决定性因素不在XML文件本身，而在分片键选择是否贴合业务查询路径，在实际生产中，100个分片规则里90个败给了不合理的分片键，配置MyCat时，先梳理业务SQL的WHERE条件，再设计分片规则，最后动手改配置文件顺序错了，后期运维成本翻倍增长。

配置架构基础：schema.xml的边界定义

schema.xml是MyCat配置的地基，核心任务是回答“数据存在哪、逻辑表长什么样、怎么写进去”。

逻辑表与物理表的映射是第一步，用 <schema> 标签声明逻辑库，再用 <table> 子标签定义逻辑表及其分片目标，这里必须遵守一条铁律：逻辑表的分片字段必须在SQL中可见，且分片字段不能是联合主键的一部分，否则，跨分片查询会频繁触发全局路由，性能断崖式下跌。

dataNode与dataHost的物理拓扑要独立配置，注意dataHost的balance属性balance=”0″ 表示不启用读写分离，而balance=”1″ 表示在从节点之间轮询，很多初学者在这里踩坑：以为配了从节点就自动读写分离了，实际上balance值没改，所有流量依旧打到主库。

<dataHost name="localhost1" maxCon="1000" minCon="10" balance="1"
          writeType="0" dbType="mysql" dbDriver="jdbc" switchType="1">

这段配置里,writeType=”0″ 表示所有写操作发到第一个writeHost，writeType=”1″ 则是随机发往所有writeHost后者会造成主从数据不一致，生产环境慎用。

分片规则配置：rule.xml的精细博弈

rule.xml决定数据落在哪个分片，是整个MyCat配置的灵魂。常见的分片算法有取模、范围枚举、一致性哈希、范围求模

，每种都有适用边界，不存在银弹。

• 取模分片：实现简单，扩容迁移成本极高，适合确认三年内不分片的业务。
• 范围分片：按时间或ID段划分，天然支持批量归档，但热点集中在新分片。
• 一致性哈希：扩容只需迁移少量数据，但分片键的分布均匀度依赖哈希算法质量。
• 范围求模：先范围再取模，兼顾扩容和均匀性，是电商订单表的推荐方案。

配置function的关键参数是count数组和分片键类型，count数组长度等于分片总数，分片键必须声明为数值型或字符串型。字符串分片键的哈希与数值类型不同，会导致同样数据分布在不同节点，这是规则配置中最隐蔽的坑。

读写分离配置：server.xml中的身份与权限

server.xml里的 system 标签控制全局行为，而 user 标签定义客户端访问权限，建议为MyCat单独创建数据库账号，避免使用MySQL的root账号直连，这样可以在MyCat层面做细粒度隔离，同时也方便日志审计。

<user name="mycat_user" defaultAccount="true">
    <property name="password">your_password</property>
    <property name="schemas">logic_db</property>
</user>

表（全局表）建议在server.xml中显式声明，全局表在每个分片都保存完整副本，适合配置字典、类目等低频变更数据，不声明而直接使用普通表的JOIN，会导致跨分片笛卡尔积查询这是性能灾难的根源之一。

性能调优与监控：配置之外的硬功夫

MyCat配置并非写完就万事大吉。连接池大小直接影响并发吞吐

，maxCon不是越大越好：连接数过多会拖垮后端MySQL线程资源，建议maxCon与dataHost上的MySQL max_connections保持同步，并预留30%缓冲。

慢SQL日志的开启时机也值得关注，生产环境默认关闭，遇到”压测通过但线上偶发超时”的场景，优先开启 sqlExecuteTimeout 与慢日志记录，定位到具体分片后再优化索引，切忌无脑加机器。

酷番云生产环境经验案例

我们在酷番云平台承载过一个日订单量约80万的电商客户,MyCat部署在酷番云4核8G的云服务器上，后端挂了3台MySQL（1主2从），最初配置是全表取模分片，订单查询用 user_id 做条件，效果尚可，后续增加了商家后台的订单检索需求，SQL过滤条件是 shop_id + order_time，直接导致全分片扫描，CPU飙到85%。

我们的调整方案分两步走：

• 将订单表从纯取模改为“范围求模”先按月份分片，再对user_id取模，避免跨年数据堆积。
• 为shop_id加上冗余字段并新建索引，并在MyCat层面为该查询配置了单独的读写分离路由策略，把这类重查询全部引流到从节点。

改造后,商家后台的查询响应时间从平均1.8秒降至280毫秒，主库负载下降了40%，这次踩坑的根源在于分片键设计只满足了开发期的唯一查询路径，没有预判到业务扩张后的多维度查询需求，我们在酷番云后续的客户部署中，都会强制要求先做SQL审计再定分片规则，这一步能规避掉80%以上的性能返工。

常见配置陷阱与规避方案

• 事务一致性：MyCat默认不支持跨分片分布式事务，跨节点更新必须引入补偿机制或改用最终一致性方案，配置里不应刻意追求强一致性。
• 全局序列号：MyCat内置了多种全局ID生成策略，

  

  数据库方式有单点风险，ZK方式有性能开销，在并发量低于5万TPS时，建议用本地时间戳+随机数组合，简单且无额外依赖。

• 配置热加载：修改schema.xml和rule.xml后，不一定需要重启MyCat，可用 reload @@config 命令热加载，但修改server.xml的系统参数后必须重启才生效。

相关问答

问：一张表有多个查询维度（如订单号、用户ID、商家ID），该怎么选分片键？

答：必须回到业务主路径上去选择，分片键只能有一个，优先保障最高频、最核心的查询单点命中，这里的关键是接受“部分查询注定跨分片”的现实，然后用索引、读写分离或搜索引擎去兜底，不要试图让分片键适配所有查询，那是伪需求，会导致规则冗长且不可维护，更好的方案是引入数据冗余表或宽表，把次要查询路径的流量拆分出去。

问：MyCat节点本身挂了，客户端的连接会中断吗？

答：会，MyCat本身是无状态的，但只要它宕机，所有数据库连接都会断，部署上需要前置一层负载均衡（如Keepalived或云负载均衡），并配置MyCat集群的健康检查，一旦检测到故障就切换流量到备用节点，如果预算受限，至少要保证MyCat与MySQL不在同一台物理机上否则硬件故障就是单点全灭，客户端侧建议启用连接池自动重试机制，降低对短暂的网络抖动感知。

结语与互动

MyCat配置不是一锤子买卖,它是分片策略、SQL特征与硬件拓扑三者持续博弈的动态产物。先跑通最小可用配置，再逐步叠加读写分离、缓存和监控，才是稳健的上线路径。

你在配置MyCat时遇到过最头疼的问题是什么？是分片键选择，还是跨分片查询调优？欢迎在评论区留言交流。