MyCat分库分表实战：从配置踩坑到路由验证全链路

简介：本资源是一份面向Java后端开发者与数据库架构初学者的Mycat分布式数据库中间件系统教程，聚焦从零基础入门到生产级精通，重点解决高并发、大数据量场景下的分库分表、读写分离与高可用架构难题。压缩包共2个文件（1个HTML教程主页+1个TXT课程索引），总大小仅6KB，轻量便携，HTML文件承载完整知识脉络与实操入口，TXT文件提供配套课程体系指引，便于快速定位学习路径。已有453人下载学习，覆盖电商、社交等典型分布式业务场景。教程涵盖Mycat核心原理（Server/DataNode/Schema/Rule）、安装配置三要素（server.xml/schema.xml/user.xml）、哈希/范围分片策略选型、XA事务权衡、多节点高可用部署及SQL性能调优要点，并对比ShardingSphere等主流中间件，助读者建立技术选型能力与落地排错思维。

1. MyCat 入门到精通：不是“中间件选型课”，而是“分库分表落地黑匣子拆解实录”

你手头有个单体 MySQL，QPS 刚过 3000，慢查开始扎堆，DBA 提议“上分库分表”，你点头说好——结果一查资料，发现得先学 ShardingSphere、再啃 Vitess、还得配 ProxySQL……最后卡在 MyCat 的 schema.xml 里改了八遍，dataNode="dn1"死活连不上后端host="192.168.5.12"的真实库，日志只打一行java.lang.NullPointerException，连报错栈都截不全。这不是玄学，是 MyCat 入门最真实的断崖：它不拒绝新手，但会用配置即代码、状态即日志、路由即逻辑这三把锁，把没亲手敲过start.sh、没翻过mycat.log最后 200 行、没手动telnet 8066过的人，挡在真正可用的边界之外。这份《MyCat 入门到精通教程》不是概念拼盘，而是我带某高校实验室做模拟项目X时，从零部署、压测、踩坑、回滚、再上线的完整链路复刻——覆盖 1.6.7 到 2.2.1 三个主力版本，聚焦“让读写请求真能落到正确物理库表上”这一唯一目标。适合正在被分库分表需求推着走、有基础 Linux 和 MySQL 操作能力、但没接触过数据库中间件的后端/DBA 工程师。别信“五分钟上手”，信“两小时跑通第一个分片查询”。

2. MyCat 是什么：不是代理层，是 SQL 路由决策引擎 + 连接池管理器 + 元数据协调器

MyCat 常被误称为“MySQL 代理”，这是最大的认知偏差。它既不转发原始 TCP 包（像 HAProxy），也不做协议解析重写（像 ProxySQL），更不托管 SQL 执行计划（像 TiDB）。它的核心角色是三层协同体：SQL 解析层（基于 Druid 解析器提取表名、条件、分片键）、路由决策层（查schema.xml+rule.xml+server.xml生成物理执行路径）、连接池管理层（维护与后端 MySQL 的长连接，复用、心跳、故障剔除）。这意味着：你写的SELECT * FROM order WHERE user_id = 1001，MyCat 不是简单转发，而是先判断order表是否分片、user_id是否为分片列、值1001经哈希/范围算法后应路由至dn1还是dn2，再从dn1的连接池取空闲连接执行。这个过程全程无日志默认输出，失败就静默丢包——所以“连不上”从来不是网络问题，而是元数据配置与物理库状态的错位。

2.1 为什么选 MyCat 而非 ShardingSphere-JDBC？

ShardingSphere-JDBC 是 JDBC 层改造，需改应用代码、升级驱动、处理事务传播；MyCat 是服务端透明代理，应用仍连localhost:8066，SQL 零修改。某跨平台系统要求“不碰业务代码”，我们实测对比：ShardingSphere-JDBC 在 Spring Boot 2.7 下需引入shardingsphere-jdbc-spring-boot-starter并配置spring.shardingsphere.rules，而 MyCat 只需部署一个 Java 进程，改schema.xml中<schema name="TESTDB" checkSQLschema="false" sqlMaxLimit="100">即可接入。但代价是：MyCat 无法感知应用级事务边界，XA 分布式事务需额外配置xaEnabled="true"并依赖后端 MySQL 的 XA 支持；而 ShardingSphere-JDBC 可通过@ShardingTransactionType(TransactionType.XA)精确控制。选型关键不在功能多寡，而在你的约束：是否允许改应用？是否接受单点代理？是否需要强一致性事务？我们选 MyCat，因约束是“应用不可动、运维要统一入口、事务最终一致即可”。

2.2 MyCat 架构三文件：schema.xml、rule.xml、server.xml 的职责边界

MyCat 启动时加载三个 XML 文件，缺一不可，但职责常被混淆：

提示：schema.xml中<dataNode name="dn1" dataHost="host1" database="db1"/>的dataHost必须与server.xml中<dataHost name="host1" ...>的name完全匹配，大小写敏感。曾有 A 同学因host1写成HOST1，MyCat 启动成功但所有查询返回ERROR 1105 (HY000): can't find table，查日志才发现can't find dataHost: HOST1。

2.3 物理库准备：MyCat 不创建表，只路由查询

MyCat绝不帮你建表。你必须在每个后端 MySQL 实例上，手动执行CREATE DATABASE db1; USE db1; CREATE TABLE order(...);。MyCat 的schema.xml中<table name="order" .../>仅声明“逻辑表 order 映射到物理库表”，不触发 DDL。验证方法：停掉 MyCat，直接连mysql -h192.168.5.12 -P3306 -udbuser -pdbpass -Ddb1，执行SHOW CREATE TABLE order;确保结构存在且字段一致。若物理库无表，MyCat 查询会返回ERROR 1146 (42S02): Table 'db1.order' doesn't exist，而非 MyCat 自身错误。这是新手最高频翻车点——以为 MyCat 会同步建表，结果压测时全量报错。

3. 从零部署：CentOS 7 + MySQL 5.7 + MyCat 2.2.1 三步闭环

部署不是复制粘贴命令，而是建立“配置-启动-验证”闭环。以下基于 CentOS 7.9、MySQL 5.7.36、OpenJDK 1.8.0_322、MyCat 2.2.1（2023 年最新稳定版）实操。注意：MyCat 2.x 与 1.x 配置差异巨大，本文不兼容 1.6.x。

3.1 环境准备：Java、MySQL、MyCat 二进制包安装

# 1. 安装 OpenJDK 1.8（MyCat 2.2.1 强依赖 JDK 8） sudo yum install -y java-1.8.0-openjdk-devel java -version # 输出应含 "1.8.0_322" # 2. 部署两个 MySQL 实例（端口 3306 和 3307），均启用 binlog（MyCat 主从探测必需） # 此处省略 MySQL 安装细节，重点配置 my.cnf： # [mysqld] 下添加： # server-id=1 # log-bin=mysql-bin # binlog-format=ROW # bind-address=0.0.0.0 # 重启 MySQL：sudo systemctl restart mysqld # 3. 下载 MyCat 2.2.1（官方 GitHub Release） wget https://github.com/MyCATApache/Mycat2/releases/download/2.2.1/mycat2-2.2.1-release.tar.gz tar -xzf mycat2-2.2.1-release.tar.gz mv mycat2-2.2.1-release /opt/mycat chown -R mycat:mycat /opt/mycat

参数说明：bind-address=0.0.0.0是必须项，MyCat 需从本机访问 MySQL；binlog-format=ROW是 MyCat 主从延迟探测的基础，STATEMENT 格式会导致show slave status解析失败；server-id在多实例中必须唯一，避免主从冲突。

3.2 配置三文件：以user_id分片的order表为例

假设业务要求：order表按user_id（BIGINT）哈希分片至dn1(192.168.5.12:3306) 和dn2(192.168.5.12:3307)，user表全局广播。

第一步：编辑/opt/mycat/conf/server.xml，定义用户和数据源

<!-- /opt/mycat/conf/server.xml --> <user name="mycat_user"> <property name="password">mycat_pwd</property> <property name="schemas">TESTDB</property> </user> <dataHost name="host1" maxCon="1000" minCon="10" balance="0" writeType="0" dbType="mysql" dbDriver="jdbc" switchType="1" slaveThreshold="100"> <heartbeat>select user()</heartbeat> <writeHost host="hostM1" url="192.168.5.12:3306" user="dbuser" password="dbpass"/> <writeHost host="hostM2" url="192.168.5.12:3307" user="dbuser" password="dbpass"/> </dataHost>

逻辑说明：<dataHost>定义一个逻辑数据主机，内含两个writeHost（MyCat 2.2.1 不再区分 read/write，全为 writeHost，balance="0" 表示不读写分离）；<heartbeat>是存活检测 SQL，必须返回非空结果，select user()最轻量；url中 IP 和端口必须与物理 MySQL 实例一致。

第二步：编辑/opt/mycat/conf/schema.xml，定义逻辑库表映射

<!-- /opt/mycat/conf/schema.xml --> <schema name="TESTDB" checkSQLschema="false" sqlMaxLimit="100"> <table name="order" dataNode="dn1,dn2" rule="mod-long"/> <table name="user" type="global" dataNode="dn1,dn2"/> </schema> <dataNode name="dn1" dataHost="host1" database="db1"/> <dataNode name="dn2" dataHost="host1" database="db2"/>

参数说明：rule="mod-long"指向rule.xml中定义的哈希规则；type="global"表示user表在dn1和dn2均创建全量副本；database="db1"是物理库名，必须与 MySQL 中CREATE DATABASE db1;一致。

第三步：编辑/opt/mycat/conf/rule.xml，定义分片算法

<!-- /opt/mycat/conf/rule.xml --> <tableRule name="mod-long"> <rule> <columns>user_id</columns> <algorithm>mod-long</algorithm> </rule> </tableRule> <function name="mod-long" class="io.mycat.route.function.PartitionByLong"> <property name="count">2</property> </function>

逻辑说明：<columns>user_id</columns>声明分片键字段名，必须与物理表order的字段名完全一致；<property name="count">2</property>表示哈希模数为 2，即user_id % 2决定路由到dn1(余0) 或dn2(余1)；若改为count="4"，则需新增dn3、dn4dataNode。

3.3 启动与基础验证：telnet + mysql-client 双确认

# 1. 启动 MyCat（首次启动加 -console 查看实时日志） /opt/mycat/bin/startup_nowrap.sh -console # 2. 验证端口监听（MyCat 默认 8066 为 SQL 端口，9066 为管理端口） netstat -tuln | grep ':8066' # 应输出：tcp6 0 0 :::8066 :::* LISTEN # 3. telnet 测试端口连通性（排除防火墙） telnet 127.0.0.1 8066 # 成功显示 "Escape character is '^]'" 即通 # 4. 用 mysql-client 连接 MyCat（密码为 server.xml 中配置的 mycat_pwd） mysql -h127.0.0.1 -P8066 -umycat_user -pmycat_pwd -DTESTDB mysql> SHOW DATABASES; # 应返回：+----------+ | Database | +----------+ | TESTDB | +----------+ mysql> SHOW TABLES; # 应返回：+------------------+ | Tables_in_TESTDB | +------------------+ | order | | user | +------------------+

关键验证点：SHOW TABLES返回逻辑表名，证明schema.xml加载成功；若返回空或报错，立即检查mycat.log中Can't find table类日志，90% 是dataNode名称不匹配或物理库无表。

4. 分片路由实战：INSERT/SELECT 如何精准落库？手撕执行计划

MyCat 的灵魂在于路由。光连上没用，必须确认INSERT INTO order(user_id, amount) VALUES(1001, 99.9)真的进了dn1（192.168.5.12:3306），而VALUES(1002, 88.8)进了dn2（192.168.5.12:3307）。这需要穿透 MyCat 日志，直击物理库验证。

4.1 INSERT 路由验证：从 MyCat 日志定位物理库

-- 在 MyCat 客户端执行 INSERT INTO order(user_id, amount) VALUES(1001, 99.9); INSERT INTO order(user_id, amount) VALUES(1002, 88.8);

查看 MyCat 日志定位路由：

# tail -f /opt/mycat/logs/mycat.log | grep -E "(route|dn[12])" # 输出示例： 2023-10-05 14:22:33.123 [INFO] [$_NIOREACTOR-0-RW] route to dn1 for INSERT into order... 2023-10-05 14:22:33.125 [INFO] [$_NIOREACTOR-0-RW] route to dn2 for INSERT into order...

登录物理库验证数据落点：

# 连 dn1（3306 端口） mysql -h192.168.5.12 -P3306 -udbuser -pdbpass -Ddb1 -e "SELECT user_id, amount FROM order WHERE user_id IN (1001,1002);" # 输出：1001 | 99.9 # 连 dn2（3307 端口） mysql -h192.168.5.12 -P3307 -udbuser -pdbpass -Ddb2 -e "SELECT user_id, amount FROM order WHERE user_id IN (1001,1002);" # 输出：1002 | 88.8

原理说明：mod-long算法对user_id=1001计算1001 % 2 = 1，路由至dn2？不对！MyCat 的mod-long实现是abs(hashCode(key)) % count，但hashCode(1001)为 1001，1001 % 2 = 1，而dn1对应余数 0，dn2对应余数 1 —— 所以1001应入dn2。但日志显示1001入dn1？这是因为 MyCat 2.2.1 的PartitionByLong默认将余数 0 映射到第一个 dataNode（dn1），余数 1 映射到第二个（dn2），无需额外配置。验证永远以物理库数据为准，日志只是辅助。

4.2 SELECT 路由验证：单库查询 vs 全局扫描

-- 场景1：带分片键的查询（精准路由） SELECT * FROM order WHERE user_id = 1001; -- MyCat 日志：route to dn1 for SELECT from order... -- 场景2：不带分片键的查询（全库扫描） SELECT * FROM order WHERE amount > 50; -- MyCat 日志：route to dn1,dn2 for SELECT from order... （并发查两个库） -- 场景3：跨分片 JOIN（MyCat 2.2.1 支持，但性能敏感） SELECT o.*, u.name FROM order o JOIN user u ON o.user_id = u.id; -- user 表为 global，o.user_id=1001 时，MyCat 先查 dn1 的 order，再查 dn1 和 dn2 的 user（广播），合并结果

避坑：JOIN 性能黑洞
现象：SELECT o.*, u.* FROM order o JOIN user u ON o.user_id = u.id WHERE o.user_id = 1001执行超时。
原因：user表是 global，MyCat 会向dn1和dn2同时发SELECT * FROM user WHERE id = 1001，但id=1001只存在于dn1，dn2返回空，MyCat 等待dn2超时（默认 30s）才合并。
解决：在user表上增加冗余字段user_id，并确保user_id = id，改写为JOIN user u ON o.user_id = u.user_id，MyCat 识别u.user_id为分片键，只查dn1。

4.3 全局表（global）的双写一致性保障

user表设为type="global"，MyCat 保证所有INSERT/UPDATE/DELETE同时发往dn1和dn2。但若dn2网络抖动，写入失败怎么办？

# 模拟 dn2 故障：关闭 3307 端口 MySQL sudo systemctl stop mysqld@3307 # 执行 INSERT INSERT INTO user(id, name) VALUES(1, 'Alice'); # MyCat 日志报错：write to dn2 failed, but dn1 success... # 此时 dn1 有数据，dn2 无数据，全局表不一致！

解决机制：MyCat 2.2.1 默认开启failFast="true"（在server.xml的<dataHost>中），任一 writeHost 失败则整个事务回滚，应用收到ERROR 1105 (HY000): execute error。若需最终一致，需设failFast="false"并配合异步补偿任务。生产环境强烈建议failFast="true"，宁可失败也不容忍不一致。

5. 避坑指南：MyCat 部署与路由的五个血泪现场

MyCat 的坑不在文档缺失，而在日志静默、配置耦合、版本跳变。以下是我在模拟项目X中踩出的五条硬核经验，每一条都附带可复现现象、根因分析和即时解法。

5.1 现象：MyCat 启动成功，但mysql -h127.0.0.1 -P8066连接超时

原因：Linux 防火墙未开放 8066 端口，或server.xml中<system>节点缺失<property name="serverPort">8066</property>（MyCat 2.2.1 默认端口为 8066，但某些定制版需显式声明）。
解决：

# 开放端口 sudo firewall-cmd --permanent --add-port=8066/tcp sudo firewall-cmd --reload # 检查 server.xml 是否有 system 节点 grep -A 5 "<system>" /opt/mycat/conf/server.xml # 若无，添加： <system> <property name="serverPort">8066</property> <property name="managerPort">9066</property> </system>

5.2 现象：SELECT * FROM order返回部分数据，WHERE user_id = ?查询为空

原因：物理库中order表的user_id字段类型与 MyCat 预期不符。mod-long算法要求分片键为BIGINT或INT，若误建为VARCHAR，MyCat 解析user_id = '1001'时无法转为数字，路由失败，默认发往第一个 dataNode（dn1），而数据实际在dn2。
解决：

-- 登录所有物理库，检查字段类型 mysql -h192.168.5.12 -P3306 -e "DESCRIBE db1.order;" mysql -h192.168.5.12 -P3307 -e "DESCRIBE db2.order;" -- 确保 user_id 为 BIGINT，否则修改： ALTER TABLE db1.order MODIFY user_id BIGINT NOT NULL; ALTER TABLE db2.order MODIFY user_id BIGINT NOT NULL;

5.3 现象：INSERT成功，但SELECT查不到刚插入的数据

原因：MyCat 缓存了schema.xml中的表结构，修改物理库表（如ADD COLUMN）后未重启 MyCat，导致路由解析仍按旧结构，SELECT时字段映射错乱。
解决：

# 修改物理库表后，必须重启 MyCat /opt/mycat/bin/shutdown.sh /opt/mycat/bin/startup_nowrap.sh -console # 或发送 reload 命令（MyCat 2.2.1 支持） mysql -h127.0.0.1 -P9066 -umycat_user -pmycat_pwd -e "reload @@config_all;"

5.4 现象：SHOW PROCESSLIST在 MyCat 中显示大量Sleep连接，内存持续增长

原因：应用未正确关闭数据库连接。MyCat 连接池中的连接被应用持有不释放，MyCat 无法回收，最终 OOM。
解决：

<!-- 在 server.xml 的 <system> 中增加连接超时控制 --> <system> <property name="processorBufferPoolType">0</property> <property name="connectionTimeout">30000</property> <!-- 30秒无活动断开 --> <property name="idleTimeout">600000</property> <!-- 空闲10分钟断开 --> </system>

同时，应用层必须使用连接池（如 HikariCP），设置maxLifetime小于 MyCat 的idleTimeout。

5.5 现象：SELECT COUNT(*) FROM order返回错误结果（远小于实际行数）

原因：COUNT(*)是聚合函数，MyCat 需从所有分片汇总。若某分片（如dn2）因网络延迟未响应，MyCat 默认超时后忽略该分片结果，导致总数偏小。
解决：

# 在 MyCat 客户端执行，强制等待所有分片 SET @mycat_route_force = 1; SELECT COUNT(*) FROM order; # 或调整全局超时（谨慎，影响所有查询） # 在 server.xml 的 <system> 中： <property name="sqlExecuteTimeout">60000</property> <!-- 60秒 -->

6. 生产就绪技巧：用9066管理端口做实时诊断与热加载

MyCat 的 9066 端口是运维的生命线。它不暴露给业务，但让你在不重启、不改配置文件的前提下，动态观测、干预、修复路由行为。这才是“精通”的分水岭——不是会配 XML，而是能在流量洪峰中稳住 MyCat。

6.1 实时诊断：show @@datasource与show @@heartbeat看清后端健康

# 连接管理端口（密码同 server.xml 中 user 密码） mysql -h127.0.0.1 -P9066 -umycat_user -pmycat_pwd # 查看所有数据源状态（关键字段：STATUS=success 表示正常，INITIALIZE 表示未初始化） mysql> show @@datasource; +----------+----------+-------+--------------+------+------+---------+-------+--------+-------+---------+----------------+---------------------+---------------+ | DATANODE | NAME | TYPE | HOST | PORT | W/R | ACTIVE | IDLE | SIZE | EXECUTE | READ_LOAD | WRITE_LOAD | LAST_ACTIVE_TIME | LAST_HEARTBEAT | HEARTBEAT_STATUS | +----------+----------+-------+--------------+------+------+---------+-------+--------+-------+---------+----------------+---------------------+---------------+ | dn1 | hostM1 | mysql | 192.168.5.12 | 3306 | W | 0 | 10 | 1000 | 0 | 0 | 0 | 2023-10-05 15:30:22 | 2023-10-05 15:30:22 | success | | dn2 | hostM2 | mysql | 192.168.5.12 | 3307 | W | 0 | 10 | 1000 | 0 | 0 | 0 | 2023-10-05 15:30:22 | 2023-10-05 15:30:22 | success | +----------+----------+-------+--------------+------+------+---------+-------+--------+-------+---------+----------------+---------------------+---------------+ # 查看心跳详情（LAST_HEARTBEAT 时间戳若停滞，说明心跳 SQL 执行失败） mysql> show @@heartbeat; +----------+--------+---------------------+---------------------+-------------+ | DATANODE | STATUS | LAST_ACTIVE_TIME | LAST_HEARTBEAT | HEARTBEAT_TIME | +----------+--------+---------------------+---------------------+-------------+ | dn1 | idle | 2023-10-05 15:30:22 | 2023-10-05 15:30:22 | 0 | | dn2 | idle | 2023-10-05 15:30:22 | 2023-10-05 15:30:22 | 0 | +----------+--------+---------------------+---------------------+-------------+

技巧：若HEARTBEAT_STATUS为error，立即查mycat.log中heartbeat fail日志，90% 是 MySQL 用户权限不足（dbuser需SELECT权限）或select user()被防火墙拦截。

6.2 热加载配置：reload @@config_all与reload @@sqlslow零停机更新

# 场景：修改了 rule.xml 中的分片算法参数，不想重启 MyCat # 1. 先备份原配置 cp /opt/mycat/conf/rule.xml /opt/mycat/conf/rule.xml.bak # 2. 编辑 rule.xml（如将 mod-long 的 count 从 2 改为 4） # 3. 发送热加载命令 mysql -h127.0.0.1 -P9066 -umycat_user -pmycat_pwd -e "reload @@config_all;" # 输出：Reload config success. # 验证：新 INSERT 的 user_id=1003,1004,1005,1006 应均匀分布到 dn1~dn4

注意：reload @@config_all会重新加载schema.xml、rule.xml、server.xml，但不会重置连接池。若修改了server.xml中的用户密码，需reload @@user单独加载。

6.3 SQL 慢日志追踪：show @@sqlslow定位分片瓶颈

# 开启慢日志（默认关闭，需在 server.xml 中启用） # 在 <system> 节点下添加： <property name="useSqlSlowLog">true</property> <property name="sqlSlowTime">1000</property> <!-- 慢于1秒记日志 --> # 重启 MyCat 后，执行慢查询 SELECT * FROM order WHERE amount > 10 AND create_time > '2023-01-01'; # 查看慢日志摘要 mysql> show @@sqlslow; +-----------+----------+---------------------+----------------+----------+----------+----------+----------+ | DATA_NODE | SQL | START_TIME | EXECUTE_TIME | RESULT | ROWS | USER | HOST | +-----------+----------+---------------------+----------------+----------+----------+----------+----------+ | dn1 | SELECT...| 2023-10-05 15:45:22 | 1250 | success | 1000 | mycat_user| 127.0.0.1| | dn2 | SELECT...| 2023-10-05 15:45:22 | 850 | success | 800 | mycat_user| 127.0.0.1| +-----------+----------+---------------------+----------------+----------+----------+----------+----------+

价值：EXECUTE_TIME直接暴露哪个分片最慢。若dn1执行 1250ms 而dn2仅 850ms，说明dn1物理库负载高或索引缺失，应登录dn1执行EXPLAIN分析。

从那以后我每次上线新分片规则，都强制走一遍show @@datasource+show @@heartbeat+show @@sqlslow三连查，哪怕只是本地测试。因为 MyCat 的路由黑匣子，只有管理端口能打开它的盖子。希望帮到你。

本文还有配套的精品资源，点击获取