简介基于MyCat 1.6.7.6正式版源码二次开发的分表中间件扩展包面向需要按月份维度自动分表的MySQL运维与架构人员。核心亮点是支持subTables按月分表正则配置例如配置subTables、subTableWay等于BYMONTH与sharding-by-month规则后即可从指定开始月份动态生成并路由到当前日期对应的月份子表解决手动分表与跨月扩容难题。压缩包共111个文件约24.86MB包含核心分表jar、第三方依赖库、数据源与分表规则配置文件、启停脚本、SQL初始化脚本以及Linux平台wrapper运行组件结构清晰便于替换和部署。目前已有374人学习下载适合熟悉MyCat基本用法、希望平滑升级月度分表能力的开发与运维人员。通过该包可拿到基于官方版本改造后的完整运行环境结合规则配置快速验证按月分表逻辑配合动态建表机制实现子表自动增长。1. 拿到 mycat-1.6.7.6_BYMONTH.zip先想清楚按月分片解决什么问题如果你的订单表或者行为日志表已经涨到几千万行查询慢、备份慢、清理历史数据也投鼠忌器那大概率会有人给你指路用 MyCat 做分片。而 mycat-1.6.7.6_BYMONTH.zip 这个发行包解压后对应的是 MyCat 1.6.7.6 分支里内置了按月分片规则BYMONTH的版本形态——本质上就是一套把数据按自然月拆到不同物理节点的方案模板。它最擅长处理强时间维度的数据订单、支付流水、设备上报记录。但先说结论按月分片只保证“带上月份范围条件”的查询受益不带时间条件的查询反而会被放大成跨节点全扫描这是很多人装完以后直呼“翻车”的根本原因。适合它的人通常是想在不替换 MySQL 的前提下把单表膨胀问题先按住的中小团队。2. 按月分片的路由计算从 rule.xml 到 dataNode 的映射2.1 先解包看结构zip 解压后哪些文件决定分片行为网上下载回来的 mycat-1.6.7.6_BYMONTH.zip 只是一个普通的发行压缩包没有做 zip 伪加密之类的小动作直接解压即可。Linux 环境我习惯用命令行处理unzip mycat-1.6.7.6_BYMONTH.zip -d /opt/mycat。Windows 上右键用 7-Zip 打开或者 WinRAR 解压都行这类中间件都是免安装设计解压完就能跑不需要往注册表里写东西。解压后你会看到这样一个目录骨架bin/ 启动与维护脚本 conf/ server.xml、schema.xml、rule.xml 等核心配置 lib/ MyCat 自身依赖的 Jar 包一般不用动 logs/ mycat.log 运行日志排错主战场真正决定“按月分片怎么分”的只有 conf 下的三个文件rule.xml 负责定义分片算法schema.xml 负责把逻辑表映射到物理库表server.xml 负责对外暴露的连接方式与用户权限。其中 rule.xml 和 schema.xml 的配合关系是核心rule.xml 告诉 MyCat“按哪个字段、用什么算法算出节点号”schema.xml 告诉 MyCat“算出来的节点号对应哪个物理库和物理表”。不少第一次上手的人只改了 schema.xml忘了 rule.xml 里的 function 还没绑定结果 SQL 全部落到单一节点表面上是 MyCat 在工作实际上跟直连 MySQL 没有任何区别。提示解压后不要直接改完配置就投入生产。1.6 系列的 conf 目录里自带多种分片规则模板BYMONTH 相关的规则默认是注释掉的需要自己解开并确认类名是否匹配。2.2 PartitionByMonth 的月份差算法与规则文件在 1.6.7.6 这个版本里按月分片对应的分片函数是 io.mycat.route.function.PartitionByMonth。它的核心逻辑并不复杂从配置的起始日期 sBeginDate 出发把分片键一般是 create_time按 dateFormat 格式化成年月计算与起始日期的月份差然后对 partitionCount 取模得到的余数就是 dataNode 的下标。rule.xml 中典型的一段配置长这样tableRule namesharding-by-month rule columnscreate_time/columns algorithmsharding-by-month/algorithm /rule /tableRule function namesharding-by-month classio.mycat.route.function.PartitionByMonth property namedateFormatyyyy-MM-dd/property property namesBeginDate2024-01-01/property property namepartitionCount12/property /function逻辑说明columns 指明分片键是 create_timealgorithm 指向 function 的名字。PartitionByMonth 拿到 SQL 里的 create_time 值后先按 yyyy-MM-dd 解析再与 sBeginDate 做月份差计算最后对 partitionCount 取模。例如 sBeginDate 为 2024-01-01有一条 2024-05-15 的数据月份差是 44 % 12 4于是路由到第 5 个 dataNode下标从 0 开始。参数说明里有三个关键点。dateFormat 必须与分片键传入的类型和格式匹配如果 SQL 里传的是时间戳 1715731200000那解析会直接失败。sBeginDate 是路由基准改一次等于把所有已存在数据的落库位置重新洗牌上线前务必冻结。partitionCount 只是取模的分母并不代表物理库个数你可以配置 12 个分区但物理库里只有 3 个库多出来的节点会在路由后报错。这里还藏着一个 1.6 系列的行为细节PartitionByMonth 并不是按“当前自然月”动态分片的而是严格按“起始日期 月份差取模”来算。也就是说如果你的 partitionCount 是 12那么在 2025 年 1 月写入的数据月份差为 12取模后仍回到 0 号节点与 2024 年 1 月的数据落在同一个物理库。这个问题我会在第 5 章专门展开。2.3 schema.xml 里把月份编号映射到物理表rule.xml 只负责算出节点下标真正决定数据写到哪里还得看 schema.xml 里的 dataNode 与 dataHost。按月分片的常见做法是“一月一库”每个自然月对应一个 database库内的表结构完全相同表名也完全一致。这样 MyCat 的 dataNode 名可以直接带月份例如 dn202401、dn202402日志和告警里一眼就能定位到是哪个月份的数据出了问题。下面是一段最小可用的 schema.xml 关键配置schema nametestdb checkSQLschemafalse sqlMaxLimit100 table nameorders dataNodedn202401,dn202402,dn202403 rulesharding-by-month / /schema dataNode namedn202401 dataHostlocalhost1 databasedb202401 / dataNode namedn202402 dataHostlocalhost1 databasedb202402 / dataNode namedn202403 dataHostlocalhost1 databasedb202403 /这里 table 的 dataNode 属性列出该逻辑表分布的所有物理节点rule 属性绑定 2.2 节定义的 tableRule。dataNode 的 name 是路由结果的目标名database 是 MySQL 里的真实库名。PartitionByMonth 算出下标 0 后MyCat 会取 dn202401 这个节点然后连接 dataHost 指向的 MySQL 实例操作 db202401 库下的 orders 表。需要注意一个常见的认知误差MyCat 1.6 的逻辑表在它所有的 dataNode 上映射的物理表名是相同的。也就是说如果一个 dataNode 指向 db202401另一个指向 db202402那两张物理表都叫 orders。如果想做成“同一个 MySQL 库里的 orders_202401、orders_202402”配置上非常别扭1.6 对“按 dataNode 分别制定物理表名”这件事支持并不好生产上也不推荐。老老实实按月建库反而让后续的备份、清理、归档都简单直接。2.4 为什么建议“一月一库”而不是“一表一节点”MySQL 的跨库查询本来就麻烦如果你把 12 个月的表都塞进同一个 databaseMyCat 的 dataNode 又没法分别指定表名最后要么靠视图糊弄要么在业务代码里手动拼表名——这两种做法都会绕过 MyCat 的路由规则分片形同虚设。而按月建库之后每个月的数据天然隔离mysqldump 备份某个库、清理半年前的历史数据都是直接 drop database 级别的事恢复也只需要重新建库导入。这是我在生产环境里踩过一轮之后固化的选型结论。如果你的 MySQL 实例数量有限可以用同一个实例上的多个 database只要物理机的磁盘和连接数扛得住路由逻辑不受影响。3. 最小可跑通的部署步骤初始化 MySQL 与服务配置3.1 准备两个物理库验证分片效果在接入 MyCat 之前先把物理环境准备干净。我建议不要一开始就建 12 个库先用两个库跑通全链路再批量补齐。第一步是在 MySQL 实例上创建两个 database 和对应的 orders 表。CREATE DATABASE db202401 DEFAULT CHARACTER SET utf8mb4; CREATE DATABASE db202402 DEFAULT CHARACTER SET utf8mb4; CREATE TABLE db202401.orders ( id BIGINT PRIMARY KEY, order_no VARCHAR(64) NOT NULL, create_time DATETIME NOT NULL, KEY idx_create_time (create_time) ) ENGINEInnoDB; CREATE TABLE db202402.orders ( id BIGINT PRIMARY KEY, order_no VARCHAR(64) NOT NULL, create_time DATETIME NOT NULL, KEY idx_create_time (create_time) ) ENGINEInnoDB;逻辑说明两张表的表结构完全一致只是分属不同的 database。id 这里没有用 AUTO_INCREMENT是因为多节点自增主键很容易撞键后续章节会讲替代方案。create_time 就是 rule.xml 里配置的分片键所以建了单独的二级索引方便按月查询的物理执行计划走索引回表。参数说明字符集统一采用 utf8mb4create_time 用 DATETIME 而不是 TIMESTAMP。DATETIME 的范围是 1000-01-01 到 9999-12-31对历史归档和跨年数据更友好TIMESTAMP 到 2038 年就溢出了。如果你的数据可能横跨多年这里不建议省事沿用 TIMESTAMP。3.2 修改 server.xml 与 schema.xml 连接真实库物理库准备好后回来改 MyCat 的配置。先看 conf/server.xml里面定义了逻辑端口和访问 MyCat 的用户。最小配置是解开注释并改成下面这样property nameserverPort8066/property user nameroot property namepassword123456/property property nameschemastestdb/property /user逻辑说明serverPort 是 MyCat 对外暴露的 MySQL 协议端口应用连的是 8066而不是 MySQL 的 3306。user 标签里定义的是逻辑用户root 只是名字跟 MySQL 的 root 没有关系schemas 指定这个用户可以访问哪个逻辑库对应 2.3 节 schema 标签里的 name。接着改 conf/dataSource这里需要确认你用的是 dbinfo 还是完整 dataHost 配置。1.6.7.6 默认支持 dataHost 方式核心参数如下dataHost namelocalhost1 maxCon1000 minCon10 balance0 writeType0 dbTypemysql dbDrivernative switchType1 heartbeatselect user()/heartbeat writeHost hosthostM1 url127.0.0.1:3306 userroot password123456 /writeHost /dataHost逻辑说明dataHost 表示一组真实 MySQL 连接writeHost 指向主库实例balance0 表示读写不分离所有请求都走主库。这是分片场景最稳妥的初始配置等业务稳定后再考虑把读压力拆分出去。参数说明maxCon 和 minCon 控制连接池水位1.6 系列在连接数暴涨时经常报 Can not get connection from datasource如果并发不高maxCon 配 100 也够。dbDriver 保持 native除非你很清楚为什么用 jdbc。heartbeat 可以是任意一条轻量 SQLselect user() 比 select 1 在部分 MySQL 版本上对权限的依赖更小。3.3 启动 MyCat 并验证逻辑库可见Linux 下启动直接执行 bin/mycat start对我个人来说更推荐先执行 bin/mycat console 在前台跑一轮这样能第一时间看到启动日志。启动后不要急着接业务先用 MySQL 客户端连一次逻辑端口mysql -h127.0.0.1 -P8066 -uroot -p123456连接成功后再执行SHOW DATABASES; USE testdb; SHOW TABLES;逻辑说明第一个 SHOW DATABASES 返回的是 MyCat 的逻辑库列表不是物理 MySQL 的库列表。USE testdb 切到逻辑库后SHOW TABLES 会显示 orders 这张逻辑表。看到 orders 表就说明 server.xml 与 schema.xml 的 schema 名对上了。Windows 环境下没有 bin/mycat 脚本可以用解压目录里的 startup_nowrap.bat 启动。如果你希望 MyCat 作为 Windows 服务开机自启常见做法是把 startup_nowrap.bat 做成计划任务或者使用 sc.exe 注册一个服务指向 Java 命令。这跟把任意免安装的 Java 服务包设置成本地服务的套路一致关键在于指定好 Java 的路径、MyCat 的 MYCAT_HOME 环境变量以及启动参数。3.4 插入一条数据确认首次路由逻辑库能连上之后插入一条测试数据然后回到物理库确认它落在了哪里。INSERT INTO orders (id, order_no, create_time) VALUES (1, NO001, 2024-01-15 10:00:00);按 2.2 节的规则这条 create_time 与 sBeginDate 的月份差为 0取模后为 0应该落在 dn202401。到 MySQL 里查一下SELECT COUNT(*) FROM db202401.orders; SELECT COUNT(*) FROM db202402.orders;逻辑说明如果 db202401 里 count 为 1说明路由生效。如果两条都不为 0或者 MySQL 直接报表不存在优先检查 rule.xml 里 tableRule 的 columns 是否真的对应了 orders 表的 create_time以及 schema.xml 里 dataNode 列表的顺序是否与 function 计算逻辑期望一致。4. 用 EXPLAIN 与日志验证分片路由是否正确4.1 EXPLAIN 输出里的 dataNode 怎么读MyCat 在 1.6 版本就提供了 EXPLAIN 命令用法是在任意 SQL 前加上 EXPLAIN它会返回这条 SQL 会被路由到哪些 dataNode。执行下面这条查询EXPLAIN SELECT * FROM orders WHERE create_time BETWEEN 2024-01-01 AND 2024-01-31;返回结果大致是DATA_NODE | SQL dn202401 | SELECT * FROM orders WHERE create_time BETWEEN 2024-01-01 AND 2024-01-31逻辑说明DATA_NODE 列显示目标节点这里只有一个 dn202401。MyCat 解析出 WHERE 条件里的 create_time 范围后与 sBeginDate 计算月份差判定这个查询只涉及 1 月的数据因此不会把 SQL 发到 dn202402。再试一条不带月份条件的查询EXPLAIN SELECT * FROM orders;返回结果会列出所有 dataNode每行一条原始 SQL。这说明 MyCat 不知道往哪里路由把查询广播给所有节点再把结果合并。这种 SQL 在分片环境里极其危险线上一条这样的慢查询会把所有物理节点的 IO 都拉高。参数说明EXPLAIN 只是路由解析不真正执行 SQL所以即使物理库表不存在它也可能返回成功。验证物理表可用性还得靠实际执行。另外MyCat 对 BETWEEN 的时间范围识别依赖于语法解析如果写成 create_time 2024-01-01 AND create_time 2024-02-01它也认但如果你把时间包在函数里比如 DATE_FORMAT(create_time, %Y-%m-%d) 2024-01-01分片键就失效了整个查询会广播到全节点。4.2 mycat.log 里看路由细节有时候 EXPLAIN 的结果和实际执行不一致特别是有 join、子查询或 order by 的场景。这时候去 logs/mycat.log 翻路由日志最直接。grep Route Result logs/mycat.log | tail -n 5这条命令会列出最近几次 SQL 的路由结果。日志中一般会打印出目标 dataNode 的 index 和 name比如Route Result: dn202401, dn202402逻辑说明如果一条 SQL 的 WHERE 条件横跨 1 月和 2 月MyCat 会把它拆成两条 SQL分别发给 dn202401 和 dn202402然后在 MyCat 层做结果合并。看到两个节点是正常的但如果一条简单的等值查询也出现多个节点说明分片键没被解析到。MyCat 默认日志级别是 INFO对路由细节已经足够。如果怀疑某个分片键在复杂 SQL 里失效可以临时把 conf/log4j2.xml 里 MyCat 的 logger 级别调到 DEBUG能直接看到分片函数的入参和出参。但生产环境千万别开一整局 DEBUG日志量会撑爆磁盘排完问题立刻改回来。4.3 按场景设计验证用例路由验证不要只测一条插入和一条查询。我一般会做下面这组用例覆盖最常见的行为场景测试 SQL预期路由当月等值查询SELECT * FROM orders WHERE create_time 2024-01-05 12:00:00dn202401跨月范围查询SELECT * FROM orders WHERE create_time BETWEEN 2024-01-31 AND 2024-02-01dn202401, dn202402不带时间条件SELECT * FROM orders LIMIT 10所有 dataNode按月插入INSERT INTO orders ... VALUES (2024-02-01 ...)dn202402按月删除DELETE FROM orders WHERE create_time 2024-01-01所有 dataNode执行前慎用逻辑说明跨月范围查询路由到两个节点是预期行为但你要重点观察结果集是否重复。MyCat 在合并来自多个节点的结果时同一个主键如果出现在两张物理表会原样返回两条所以分片键的边界设计必须让每条数据只能落在一个节点上这要求在应用层写入时就保证 create_time 精确到秒且不做范围重合。我实际遇到过的最隐蔽问题是在分页场景ORDER BY create_time LIMIT 10 不带 WHERE 条件时MyCat 先从每个节点各取 10 条再在内存里排序取前 10结果和单库 LIMIT 语义并不完全等价。所以在分片环境下分页查询必须带上时间过滤条件否则翻页会漏数据或重复数据。这是老生常谈但几乎每批接入的人都会在联调时翻一次车。5. 避坑按月分片最常见的 5 个现场5.1 坑一日期格式串写错路由全部挤到同一个节点现象插入任何日期的数据最终都落到 dn202401其他节点一条数据都没有。原因rule.xml 里 dateFormat 写成 yyyy-MM-dd但 create_time 字段是 DATETIMEMyCat 在解析时如果得不到期望的字符串会退化成把时间部分截掉或按默认值处理导致所有日期的月份差都被算成 0。还有一种是 dateFormat 里把月份写成了 yy-MM-dd年份变成两位跨年的月份差计算直接错乱。解决先把 dateFormat 统一成 yyyy-MM-dd HH:mm:ss再在 rule.xml 和 SQL 参数里保持一致。排查时先用 EXPLAIN 打印两条不同日期的 SQL观察返回的 dataNode 是否随日期变化而变化如果不变化十有八九是 dateFormat 解析问题。5.2 坑二dataNode 配置了 12 个物理库只建了 2 个现象配置好的 MyCat 能正常启动插入 1 月、2 月的数据也没问题但插入 3 月数据时 MySQL 直接报 Table db202403.orders doesnt exist。原因schema.xml 里 table 的 dataNode 列表写了 12 个节点但初始化脚本只建了 db202401 和 db202402。MyCat 的路由计算觉得 3 月对应 dn202403于是连接 MySQL 操作 db202403.orders库不存在就报错。解决写一个循环建库脚本一次性把 12 个月份的数据库和表全部建好。我习惯把建表 SQL 存成模板脚本按月循环执行for i in 01 02 03 04 05 06 07 08 09 10 11 12; do mysql -h127.0.0.1 -uroot -p123456 -e CREATE DATABASE IF NOT EXISTS db2024\${i} DEFAULT CHARACTER SET utf8mb4; CREATE TABLE IF NOT EXISTS db2024\${i}.orders (...); done注意脚本里的 ${i} 是为了让 shell 在展开时保留变量语义实际执行时 01 到 12 会被逐一拼进库名。更稳妥的做法是把建表语句单独存成 schema.sql用 mysql 客户端重定向导入避免命令行转义问题。5.3 坑三查询不带分片键MyCat 把 SQL 广播到所有节点现象一条 SELECT COUNT(*) FROM orders 在分片前只需要 50ms接上 MyCat 后变成 2 秒数据库连接数居高不下。原因WHERE 条件里没有 create_timeMyCat 无法定位月份只能把 SQL 发送到所有 dataNode最后再聚合。如果业务里有大量报表类查询不带时间范围MyCat 不但没有帮你分担压力反而放大了压力。解决在应用层的数据访问层强制注入默认时间范围。比如 Java 项目里写一个 MyCat 专用的查询拦截器未带 create_time 的 SQL 默认追加前 30 天的时间条件。另外一个办法是把这类不常用的统计查询切到直连 MySQL 从库而不是走分片逻辑库。MyCat 适合承接在线事务不适合做无边界统计分析。5.4 坑四跨年数据没有新节点新一年数据覆盖旧一年现象2025 年 1 月的数据插入后db202401.orders 的行数异常增长而 db202501 根本不存在甚至 2025 年 1 月的查询返回了 2024 年 1 月的旧数据。原因PartitionByMonth 的取模逻辑决定了下标 月份差 % partitionCount。partitionCount 为 12 时2024-01 到 2025-01 的月份差是 1212 % 12 0所以数据又回到 0 号节点。这不是配置错误是算法本身的循环特性。解决三个方向。第一partitionCount 直接设为 36覆盖未来三年让 2025、2026 的数据落在新节点上代价是要把 dataNode 列表补到 36 个并提前建库。第二每年年底做一次数据迁移把满一年的节点数据归档并重建规则。第三升级思路不用 PartitionByMonth改用自定义分片函数按年月后缀直接映射例如把 create_time 转成 202501 这样的数字再用 PartitionByLong 精确路由彻底绕开取模。生产上我建议第一种和第三种结合既保留按月分片的直观性又避开循环覆盖。5.5 坑五多节点自增主键撞车插入报主键冲突现象应用原本在单表上用 AUTO_INCREMENT 主键接入 MyCat 后db202401.orders 和 db202402.orders 的主键都从 1 开始自增两条不同订单的 id 都是 1导致 MyCat 层的数据合并逻辑无法区分数据。原因MyCat 只是路由中间件不会帮你把多个物理表自增主键协调成全局唯一。AUTO_INCREMENT 在每个物理库内独立跨库必然撞车。解决要么在 server.xml 里配置全局序列把 sequenceHandlerType 从默认改掉通过 MyCat 生成全局 id要么在应用层改用雪花算法直接为 id 赋值不让数据库参与主键生成。前者部署简单但 MyCat 重启后要留意序列文件备份后者更符合分布式惯例。我个人的习惯是应用层生成雪花 id把数据库的主键完全做成逻辑层这样可以随时把某个月份的库迁移到新机器而不担心 id 断档。6. 把按月分片从“能跑”调到“好管”6.1 月末自动建下月库表按月分片稳定的前提是“每个月要用的库必须提前存在”。手工每月建一次不是不行但容易忘。我一般留一个建库脚本放到 crontab 里每月 28 号执行一次生成下一个月的 database 和与 schema.sql 完全一致的表结构。这个脚本同时会检查 dataNode 是否已经配置在 schema.xml 里如果新月份超出了现有 dataNode 列表我会提前把节点补进配置并维护 plan比如直接先写好 36 个节点让 MyCat 不再要求改 schema。6.2 给应用层加上时间条件拦截器这是监控之外最值的投入。分片中间件不会替你判断“这条 SQL 是否合适”不加条件就是广播。常见做法是在 DAO 层做一个薄薄的切面解析出 SQL 里如果找不到 create_time 关键字就拒绝执行或者自动拼上最近 30 天条件。这个切面逻辑不复杂但能让团队里所有成员都不再踩“不带时间查询”的坑。6.3 月度核对脚本保住最后一道防线配置再严谨也要防一手数据落错节点的玄学问题。我每个月初会跑一个核对任务连上每个物理库执行 COUNT(*)再把所有节点的行数相加和业务侧的订单总量做比对。发现对不上第一时间翻 mycat.log 查路由而不是直接改数据。这样做了一年多最大的教训是跨年切换前的规则检查一定不能省2024 年底我因为漏看取模算法差点让 2025 年 1 月的订单和 2024 年 1 月的数据混在一起。提前把 partitionCount 放大到 36 之后这种风险才彻底解除。希望这些踩坑记录能让你少走一轮弯路帮到你。本文还有配套的精品资源点击获取