企业官网建设流程全解析

简介：基于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 name="sharding-by-month"> <rule> <columns>create_time</columns> <algorithm>sharding-by-month</algorithm> </rule> </tableRule> <function name="sharding-by-month" class="io.mycat.route.function.PartitionByMonth"> <property name="dateFormat">yyyy-MM-dd</property> <property name="sBeginDate">2024-01-01</property> <property name="partitionCount">12</property> </function>

逻辑说明：columns 指明分片键是 create_time，algorithm 指向 function 的名字。PartitionByMonth 拿到 SQL 里的 create_time 值后，先按 yyyy-MM-dd 解析，再与 sBeginDate 做月份差计算，最后对 partitionCount 取模。例如 sBeginDate 为 2024-01-01，有一条 2024-05-15 的数据，月份差是 4，4 % 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 name="testdb" checkSQLschema="false" sqlMaxLimit="100"> <table name="orders" dataNode="dn202401,dn202402,dn202403" rule="sharding-by-month" /> </schema> <dataNode name="dn202401" dataHost="localhost1" database="db202401" /> <dataNode name="dn202402" dataHost="localhost1" database="db202402" /> <dataNode name="dn202403" dataHost="localhost1" database="db202403" />

这里 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 个月的表都塞进同一个 database，MyCat 的 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) ) ENGINE=InnoDB; 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) ) ENGINE=InnoDB;

逻辑说明：两张表的表结构完全一致，只是分属不同的 database。id 这里没有用 AUTO_INCREMENT，是因为多节点自增主键很容易撞键，后续章节会讲替代方案。create_time 就是 rule.xml 里配置的分片键，所以建了单独的二级索引，方便按月查询的物理执行计划走索引回表。

参数说明：字符集统一采用 utf8mb4，create_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 name="serverPort">8066</property> <user name="root"> <property name="password">123456</property> <property name="schemas">testdb</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 name="localhost1" maxCon="1000" minCon="10" balance="0" writeType="0" dbType="mysql" dbDriver="native" switchType="1"> <heartbeat>select user()</heartbeat> <writeHost host="hostM1" url="127.0.0.1:3306" user="root" password="123456"> </writeHost> </dataHost>

逻辑说明：dataHost 表示一组真实 MySQL 连接，writeHost 指向主库实例，balance="0" 表示读写不分离，所有请求都走主库。这是分片场景最稳妥的初始配置，等业务稳定后再考虑把读压力拆分出去。

参数说明：maxCon 和 minCon 控制连接池水位，1.6 系列在连接数暴涨时经常报 "Can not get connection from datasource"，如果并发不高，maxCon 配 100 也够。dbDriver 保持 native，除非你很清楚为什么用 jdbc。heartbeat 可以是任意一条轻量 SQL，select 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 按场景设计验证用例

路由验证不要只测一条插入和一条查询。我一般会做下面这组用例，覆盖最常见的行为：

逻辑说明：跨月范围查询路由到两个节点是预期行为，但你要重点观察结果集是否重复。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 字段是 DATETIME，MyCat 在解析时如果得不到期望的字符串，会退化成把时间部分截掉或按默认值处理，导致所有日期的月份差都被算成 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' doesn't 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_time，MyCat 无法定位月份，只能把 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 的月份差是 12，12 % 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 之后，这种风险才彻底解除。希望这些踩坑记录能让你少走一轮弯路，帮到你。

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