mycat配置详解，mycat读写分离怎么配置

MyCat 配置的核心结论是：掌握 MyCat 配置的关键在于理解其三层逻辑架构即 server.xml（系统与用户权限）、schema.xml（逻辑库与数据节点映射）、rule.xml（分片规则算法）的协同关系，只要理顺了数据从逻辑库流向物理库的映射链条，无论是读写分离还是分库分表，都能通过精确的配置项实现。

MyCat 配置的基石：理解三大核心文件

MyCat 的配置体系不复杂，但容易出错，很多初次接触的开发者往往陷入某个单一标签的细节中，忽略了全局逻辑。专业建议是：先搭框架，再填细节。

• server.xml：负责定义 MyCat 自身的连接信息、线程池大小，以及最重要的逻辑用户权限，这里决定了应用层以什么账号密码连接 MyCat，以及该账号能访问哪些逻辑库。
• schema.xml：这是配置的心脏，它定义了逻辑库（schema）、逻辑表（table）、数据节点（dataNode）与真实物理数据库（dataHost）之间的映射关系。
• rule.xml：当进行分片时，此文件决定数据按照何种规则（如取模、枚举、范围）路由到不同的数据节点。

实战配置详解：从逻辑到物理的映射

在配置 schema.xml 时，最大的痛点是分片表与非分片表的混合使用，很多用户将无需分片的表也强制路由，导致查询效率低下。

解决方案： 对于数据量小、关联查询频繁的表（如字典表），在 <table> 标签中不配置 dataNode 属性，而是让其仅在特定 dataNode 上存在，这能有效避免跨节点 JOIN 的性能灾难。

<!-- 正确示例：只读表与分片表共存 -->
<schema name="TESTDB" checkSQLschema="true" sqlMaxLimit="100">
    <!-- 全局表：只在 dn1 上存在 -->
    <table name="t_dict" dataNode="dn1" type="global"/>
    <!-- 分片表：按照 id 取模分布 -->
    <table name="t_order" dataNode="dn1,dn2,dn3" rule="mod-long"/>
</schema>
<dataNode name="dn1" dataHost="host1" database="db_order_1" />
<dataNode name="dn2" dataHost="host1" database="db_order_2" />
<dataNode name="dn3" dataHost="host2" database="db_order_3" />

独立的见解： 不要过度分片。分片的数量应等于物理库的 CPU 核心总数，而不是越大越好，分片过多会导致跨节点聚合查询的响应时间呈指数级上升。

读写分离配置：权重与延迟的博弈

在 schema.xml 的 <dataHost> 标签中，balance 属性和 writeHost/readHost 的配置决定了流量的走向。

• balance="1"：表示读写分离，select 语句在 readHost

  

  和 writeHost 上轮询分发。

• writeType="0"：表示所有写操作仅发往第一个 writeHost。

专业陷阱提示： 默认配置下，如果主从同步延迟较高，刚插入的数据可能无法立即在从库查到。建议在业务代码中强制将实时性要求高的查询路由到主库（例如在 SQL 前加注解 /#mycat:db_type=master/），或者在 dataHost 层面开启 slaveThreshold 参数，当从库延迟超过阈值时自动摘除，保证数据强一致性。

酷番云实践：从单库瓶颈到水平扩展的蜕变

我们在协助某电商客户迁移至云环境时,遇到其订单表数据量突破 5000 万行，单库写入性能急剧下降。

经验案例： 我们利用酷番云的云服务器资源，规划了三节点 MyCat 集群方案。

• 第一步：在酷番云控制台创建了三台 4核8G 的 CVM，安装 MyCat 1.6 版本。
• 第二步：依据业务特征，采用 mod-long 分片规则，将订单数据按 user_id 取模分布至 3 个 MySQL 实例。
• 第三步：最关键的是，我们在酷番云的内网负载均衡上配置了 TCP 监听，将应用层的数据库连接分发至 MyCat 集群，解决了 MyCat 单点故障问题。

结果： 通过精确的 rule.xml 配置与云资源的结合，该客户在双十一期间承受住了平时 10 倍的 QPS 峰值，写入性能提升了 300%

，这一案例验证了：在云化环境中，MyCat 的配置必须与底层云资源的拓扑结构（如内网延迟、IOPS）紧密结合，否则配置再完美，物理硬件的瓶颈依然无法突破。

常见问题解答模块

MyCat 配置了分片后，如何执行 order by 或者 limit 查询？
MyCat 会将 SQL 下发至各个分片执行，并在内存中进行结果集归并排序，但请注意，当分片数量较多且数据量极大时，全排序会消耗大量 JVM 内存，建议在业务 SQL 中严格限制 limit 的偏移量，避免深分页，对于复杂的聚合统计，建议使用 ERJoin 或者异构索引（如将数据同步至 Elasticsearch），这比单纯调整 MyCat 配置更有效。

server.xml 中的 useGlobleTableCheck 参数到底要不要开启？
该参数用于检查全局表的数据一致性。建议开启，在分布式环境下，如果不开启此参数，全局表的 DML 操作可能只更新了部分节点，导致数据逻辑错误，开启后，MyCat 在启动时会执行 check-global-table 校验，确保每个分片上的全局表数据一致，虽然会略微增加启动时间，但对于数据一致性而言，这个代价是值得的。

是 MyCat 配置的核心逻辑与实战沉淀，你在配置过程中是否遇到过分片键选择困难或者跨分片 join 性能低下的问题？欢迎在评论区分享你的配置经历，我们可以针对具体的业务场景进一步拆解优化方案。