加服务器扩Mycat分库分表，核心思路就一句话：先搞清楚瓶颈在连接数还是数据量，再决定是纵向加配置还是横向加节点，最后改配置文件并平滑迁移数据。很多团队一上来就想着加机器，结果改了分片规则后发现数据对不上，路由全乱了，业务直接断，本文按实际操作路径拆解，覆盖方案选型、配置修改、数据迁移和验证回滚。
mycat分库分表如何增加服务器：先判断扩容类型
Mycat扩容不是简单往集群里塞一台机器就行，你得先回答两个问题：当前是连接数扛不住，还是单库数据量太大？这两者对应的扩容方式完全不同。
- 连接数瓶颈：表现为CPU不高、磁盘不忙，但报“Too many connections”或响应变慢，此时优先做纵向扩容，即提升现有服务器配置,不改任何分片规则。
- 数据量瓶颈：表现为单表行数过大、查询索引失效、磁盘占用接近警戒线，此时必须做横向扩容,增加物理节点并调整分片规则。
行业共识认为，80%以上的扩容场景属于数据量驱动，而非单纯的连接数驱动，如果你不确定，先看慢查询日志和磁盘增长曲线,再决定路径。
纵向扩容：只加资源，不改规则
纵向扩容是最安全的方式,风险几乎为零。
- 将新服务器加入Mycat所在集群，或直接升级现有服务器CPU/内存。
- 修改Mycat安装目录下的
conf/server.xml，调整system标签中的连接池参数，比如maxCon、maxPacketSize。 - 重启Mycat服务，执行
show @@backend确认后端连接池状态。
注意，纵向扩容不能解决分片本身带来的查询效率问题，如果单表已经分了几千万行,光加内存治标不治本。
横向扩容：改分片规则，必须迁移数据
横向扩容要动分片键和分片规则，这是高风险操作，必须在业务低峰期执行,并做好全量备份。
- 确定新的分片数量，比如原来4个分片，扩到8个，数据分布算法从
mod 4改成mod 8。 - 修改
conf/rule.xml中的tableRule和function配置，重点检查algorithm的count值是否与新节点数量一致。 - 修改
conf/schema.xml，在dataNode和dataHost中新增节点信息，并调整<dataNode>的database属性。
这里有一个关键细节：Mycat不自动搬迁数据，你改了分片规则，老数据还在旧位置上，路由却按新规则走，必然查不到或查错,所以横向扩容的核心工作其实是数据迁移。
mycat扩容数据迁移：三步走，别跳步
数据迁移是整个扩容成败的关键，业内有一种说法：“扩容失败九成出在数据迁移环节。”下面按顺序操作。
第一步：全量备份与数据导出
- 对每个旧分片执行
mysqldump,备份全量数据。 - 导出后校验行数：在Mycat命令行执行
show @@datasource确认后端连接正常，再用select count()比对各分片的数据量。
第二步：按新分片规则分桶
这是最需要小心的环节，假设旧规则是mod 4，新规则是mod 8，你需要用脚本把每条数据重新计算切分目标，别试图手工处理,写个Python或Shell脚本来做。
#!/bin/bash
# 伪代码示意，实际请根据分片键类型调整
for line in $(cat old_data.sql); do
shard_key=$(echo $line | awk -F',' '{print $1}')
new_shard=$((shard_key % 8))
echo $line >> shard_${new_shard}.sql
done
- 按新分片编号生成8个SQL文件。
- 在目标新节点上分别执行导入。
- 导入完成后,逐一核对每个新分片的行数总和等于旧分片总和。
第三步：切换Mycat配置并验证
- 更新
rule.xml和schema.xml后,重启Mycat。 - 先跑只读查询，验证路由正确性，执行
explain select from table where id = 123，看dataNode是否指向正确分片。 - 再跑写操作,确认插入数据落到了预期分片。
不要跳过验证直接上线，给业务方留10-15分钟做冒烟测试，观察日志里有没有route报错。
mycat分片规则修改：常见场景与配置示例
以下是一个从4分片扩到8分片的真实典型配置对照。
| 配置项 | 扩容前（4分片） | 扩容后（8分片） |
|---|---|---|
rule.xml中function<count> |
4 | 8 |
schema.xml中dataNode数量 |
4个，如dn1-dn4 |
8个，如dn1-dn8 |
dataHost中writeHost地址 |
4台物理机 | 8台物理机 |
| 分片算法 | mod-long取模4 |
mod-long取模8 |
| 数据分布 | 均匀随机分布 | 需重新分布 |
如果用的是hash分片或range分片，逻辑稍有差异，但核心原则一致：新规则必须覆盖所有数据节点，且旧数据必须重新分布。
分片键选择失误怎么补救
常见问题是分片键选得不好，导致数据倾斜，比如按订单ID取模，但某些大客户的订单量巨大，个别分片数据量超出其他分片数倍，这种情况下加服务器无济于事，必须换分片键或改用一致性哈希，Mycat支持一致性哈希分片算法，配置方法是在rule.xml中设置function为consistent-hash，并指定virtualBucketTimes参数，更换算法同样需要重新迁移数据,步骤与前文一致。
mycat扩容后性能验证：别只看启动成功
重启Mycat后服务正常，不代表扩容成功，你需要做一套完整的性能验证,这里列出核心检查项。
- 查看路由日志：
logs/mycat.log中是否出现route result且dataNode指向正确。 - 监控后端连接：执行
show @@connection,统计每个dataNode的连接数是否均衡。 - 压测写路径：用一个临时表写入10万条数据,然后按分片键查询分布情况。
- 检查慢查询：用
show @@slow查看是否存在跨分片查询。尽量避免跨分片join，这是分库分表后的常见性能杀手。
多服务器负载均衡配置
扩容后如果节点多了，Mycat所在服务器反而可能成为新的瓶颈，此时建议在前端增加HAProxy或Keepalived做负载均衡，将读写请求分发到多个Mycat实例,常见架构是：
- 两台Mycat做双热备,互为主备。
- HAProxy负责转发,Keepalived负责VIP漂移。
- 后端8个MySQL节点组成分片集群。
这种模式下，任何一台Mycat宕机，业务基本无感，但要注意，Mycat本身是无状态的吗？不是，它的配置状态在内存中，所以多实例间必须同步配置，你可以在两台Mycat上使用相同配置文件，或者在CI/CD流程中统一发布。
常见扩容坑与规避方法
根据社区反馈和实际操作经验,以下问题出现频率较高。
动态扩容后查询结果不一致：多半是分片规则改完但数据没搬迁，建议在切换前,用脚本比对旧分片总行数与新分片总行数之和。
Mycat启动报错Invalid rule：检查rule.xml中function的class标签是否拼写正确，count值是否大于等于dataNode数量。
数据迁移过程中出现主键冲突：新旧分片同时写入时可能产生冲突，迁移期间应停写或改用双写方案，旧分片不删，新分片双写,切换后再解除双写。
事务边界问题：分片规则变化后，涉及跨分片的事务需要全局事务管理器支持，如果没有配置XA事务或分布式事务,扩容后尽量避免跨节点事务。
多表关联被路由到不同分片：Mycat对父子表需使用ER分片规则，保证关联数据落在同一分片，扩容时,主表子表的分片规则必须同步修改和迁移。
mycat扩容成本与选型建议
扩容不只关乎技术，也涉及成本和运维复杂度，以下表格可帮你做决策（成本区间请结合本地服务器采购或云服务商报价，据公开信息，云厂商8核16G MySQL实例年费大致在万元级别，具体以实际合同为准）。
| 场景 | 建议方案 | 运维成本 |
|---|---|---|
| 数据量增长缓慢 | 纵向扩容，提升单机配置 | 低 |
| 数据量增长快但业务单一 | 横向扩容，继续用Mycat | 中 |
| 数据量增长快且查询复杂 | 考虑迁移到分布式数据库 | 高 |
近年来，有的团队从Mycat迁移到了原生分布式数据库，原因是Mycat本身是代理层，性能损耗和运维复杂度随着节点增多而上升，如果你当前分片数已经超过16个，且频繁出现路由问题,不妨重新评估方案。
如果确认继续使用Mycat，建议在扩容前做好三件事：确认分片键业务含义、备份全量配置、演练数据迁移,这三步能避免绝大多数翻车现场。
最后一个实操提醒：mycat分库分表增加服务器，不要把新节点加到原来的数据节点列表里就完事，必须同步更新分片算法中的count值，并对存量数据按新算法重新分布，跳过这一步，等于埋雷，数据查询错乱只是早晚问题，扩完容后持续观察一周慢日志和磁盘均衡度,确认稳定再放开业务流量。
Q&A：mycat分库分表增加服务器常见问题
扩容必须停机吗？
不一定，如果允许短时只读，可以在低峰期停机迁移，全程约30分钟到1小时，如果业务要求7×24可用，需要引入双写或在线迁移工具（如简米云DTS这类数据同步服务），配置Mycat规则切换时用灰度发布逐步放量，停机时间取决于数据量和分片数量，数据量越大,迁移窗口越长。
mycat分库分表增加服务器后，旧分片的数据怎么处理？
如果旧分片仍在dataNode列表中，数据会留在原地，但路由会按新规则走，导致旧数据“失联”，正确的做法是对旧数据按新规则重新分桶并导入新节点，迁移完成后，旧分片数据可以保留一段时间作为备份，待新分片稳定运行后再清理，不要立即删除旧节点数据,回滚时还需要它。
纵向扩容和横向扩容，怎么选性价比更高？
连接数瓶颈优先纵向扩容，加内存或CPU往往几百元就能解决，不用动分片规则，数据量瓶颈优先横向扩容，单纯加配置无法解决单表行数过大导致的索引膨胀和IO压力，判断依据很简单：看磁盘增长曲线是否接近线性增长，如果每个月数据量递增且增速稳定，横向扩容是唯一出路，如果只是大促期间临时连接打满,纵向扩容加连接池更划算。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/771179.html
