MyCat 1.6.7.6 部署与分库分表配置排错实战

1. 先搞清楚这个压缩包里装的是什么MyCat 是一个用 Java 写的数据库中间件它对外伪装成一台 MySQL 服务器对内把一条 SQL 拆分、路由、改写分发到后面若干台真实的 MySQL 实例上去执行再把结果集合并回来。你拿到的这个Mycat-server-1.6.7.6-release-windows-linux.rar本质上就是一份绿色免安装的运行目录解压、改配置、跑启动脚本三个动作就能让一台逻辑上的大数据库跑起来而底层其实是多个物理库在干活。它主要解决三类问题——单表数据量涨到几千万行后索引撑不住、单库连接数和 IO 顶到天花板、以及业务上天然可以水平切分的场景订单、日志、账单这类按用户或按时间天然隔离的数据。适合谁来读如果你手上有 MySQL 分库分表的诉求又不想在应用层硬编码路由逻辑那这份东西值得花半天时间摸一遍如果你只是想搭个单机数据库那真的没必要上中间件多一层就多一个故障点。很多人对这个包的困惑集中在两件事一是版本号后面那一串数字到底代表什么二是 windows 和 linux 打在一个包里是什么意思。先回答第二个windows-linux只是说明压缩包里的启动脚本两套都给齐了——bin目录下既有.bat也有.sh核心的jar包和配置文件是同一份跟平台无关你按操作系统挑脚本用就行。第一个问题稍微复杂一点得从 MyCat 的版本分支说起下面的内容会一点点拆开。我自己第一次碰这个东西是在一个订单库撑不住的场景里当时评估过应用层 sharding、代理层中间件、原生分区表三条路最后选了 MyCat原因很朴素改动面最小应用侧的 JDBC 连接串换个端口就行代码几乎不用动。这个选择的代价和后续踩的坑后面几节会挨个讲清楚。2. 1.6.7.6 这个版本号背后的选择逻辑与包内容2.1 从版本号读出维护状态与兼容边界MyCat 的版本号规则大致是大版本.分支.修订.补丁这样的四段式1.6.7.6 落在 1.6 这个分支的后期维护带上。1.6 系列是这条产品线里被验证得最久、资料最多的一支网上你能搜到的绝大多数配置示例、分片算法说明、问题帖都是围绕 1.6 展开的。这带来的直接好处是你遇到的坑大概率已经有人踩过了坏处是一些早期设计上的妥协被保留了下来比如跨库 join 的支持一直很有限分布式事务走的是弱 XA 路线而不是强一致的两阶段提交。至于为什么要在 1.6 的众多小版本里挑 1.6.7.6我的判断依据主要有三条。第一看它是不是该分支的末期版本越靠后的补丁版本通常把前面暴露的连接泄漏、结果集合并越界、管理端口命令失效这类问题修得更干净。第二看你后端 MySQL 的版本1.6 系列内置的 JDBC 驱动偏老如果你的后端是较新版本的 MySQL驱动大概率要手工替换这一点在选版本时就要提前想好。第三看社区活跃度一个版本如果长期没有新 issue 也没有回复说明维护基本停了那就只能当能跑就别动的稳定件来用别指望出问题有人接。注意不要迷信版本越新越好。数据库中间件这类组件稳定性和可预测性远比新特性重要一个跑了两年没出过事的旧版本比一个刚发出来三个月的新版本更值得留在生产上。2.2 压缩包里到底有哪些东西值得看解压之后你会看到一个标准目录结构bin放启动停止脚本和 wrapper 相关文件conf放全部配置文件lib放依赖 jarlogs是日志输出目录catlet放一些扩展用的脚本类东西根目录下通常还有个version.txt之类的说明文件。真正需要你动手的只有conf和bin两个目录其余的基本不用碰。conf里的文件值得挨个点名。server.xml管用户、逻辑库授权和系统级参数schema.xml是核心中的核心定义逻辑库、逻辑表、数据节点、物理数据源的映射关系rule.xml定义分片规则和算法实现sequence_conf.properties配合全局序列使用wrapper.conf控制 JVM 启动参数log4j2.xml管日志级别和滚动策略。剩下还有几个dnindex.properties之类的状态文件是运行期自动维护的别手动改。bin目录在 Windows 下有startup.bat、startup_nowrap.bat、mycat.bat在 Linux 下有startup.sh、mycat。这里的差别值得单独说一下带wrapper的启动方式会在前台起一个守护进程再拉起 JVM好处是能做自动重启坏处是 Windows 下会多弹一个控制台窗口容器化或者用进程管理工具托管的时候容易出乱子nowrap版本直接java -jar拉起简单粗暴适合调试和受控环境。2.3 获取渠道与完整性校验这件事这类中间件的分发包来源基本就三类项目官方的发布页面、开源代码托管平台的 release 附件、以及各类镜像站点和二次打包的整合包。前两类拿到的是原始产物第三类就要小心了——我见过不少所谓某某优化版某某增强版里面被塞了改过的 jar 包类名一样、行为不一样排查起来极其痛苦因为你看源码对不上。所以我的习惯是优先从官方发布渠道拿原始包拿到之后立刻核对校验值。正规的发布页一般会同时提供.md5或.sha1校验文件Windows 下用certutil -hashfile 文件名 MD5Linux 下用md5sum 文件名两边算出来的值对不上就别解压了直接重新下。这一步很多人嫌麻烦跳过但真出事的时候它是唯一能证明你手上这份东西没被动过手脚的依据。另外提醒一句.rar格式在 Linux 下不一定有现成的解压工具unrar往往需要单独装实在不行就在 Windows 或本地机器上解压好再传上去。解压路径不要带中文、不要带空格这是老生常谈但每年都有人栽在这上面——wrapper 脚本里对路径的处理没你想的那么健壮。3. 它到底解决了什么问题映射链条与适用边界3.1 一条 SQL 从客户端到物理库的完整旅程理解 MyCat 最快的方式是把它的处理链路走一遍。客户端连上 8066 端口MyCat 先用 MySQL 协议完成握手和认证此时它在你眼里就是一台普通的 MySQL。你发过来一条select * from t_order where order_id 1001MyCat 拿到之后做几件事解析 SQL 语法树识别出表名t_order去schema.xml里查这张表绑定了哪些数据节点拿到order_id 1001这个条件套用rule.xml里配置的分片算法算出落在哪个节点上然后把原始 SQL 稍作改写主要是补上库名前缀或者调整分页参数通过后端连接池发到对应的物理 MySQL 上。结果回来之后如果只命中一个节点基本就是原样透传如果命中了多个节点麻烦就来了——需要做结果集合并。合并包括几件事字段对齐、行合并、排序归并、分页裁剪、聚合计算。order by的实现是每个分片各自排序后做多路归并limit 100, 10会被改写成每个分片取limit 0, 110然后在内存里跳过前 100 条count(*)是把各分片的计数加起来avg()更绕一点要拆成sum和count分别取回再相除。这些细节决定了你写 SQL 时的注意事项后面第 5 节会展开。这个链路听着不复杂但每一步都可能成为性能瓶颈或者结果错误的来源。3.2 分片规则把一行数据送到它该去的节点分片算法的选择是整个方案里最需要前置思考的部分因为它一旦定下来后期改动的成本极高——改分片规则意味着全量数据重新分布。MyCat 提供了十几种现成的算法实现常用的可以归成四类取模类、范围类、哈希类、日期类。取模类最直观order_id % 节点数数据分布均匀缺点是扩容时要重新洗数据而且取模的字段必须是稳定的、不会变的。范围类按区间划分比如 0 到 500 万走节点一500 万到 1000 万走节点二好处是范围查询能精准命中单个节点坏处是数据量增长不均时会热点集中而且需要提前规划好区间上限。哈希类用一致性哈希或者 MurmurHash扩容时只影响相邻节点的数据迁移代价是要额外维护虚拟节点。日期类按月或按天分片日志、账单这类带时间属性的表特别合适查询条件里带时间范围时能有效裁剪。选哪一类取决于你的查询模式。如果你的查询几乎都会带用户 ID那按用户 ID 取模是最省事的如果你的查询大量是最近七天的订单这种时间范围那按日期分片能把扫描范围压到最小。最怕的是那种什么条件都可能带的查询这种表要么做成全局表要么就得接受每次查询广播到所有分片的代价。3.3 哪些场景我建议你绕开它不是所有分库分表的需求都该用中间件解决这一点得说清楚。如果你的分片逻辑非常固定永远是按用户 ID 切、而且切分规则三年内不会变那在应用层用个简单的路由组件做掉链路更短、排障更直接中间件这层的价值就不大了。如果你的业务强依赖分布式事务的强一致性比如金融级的转账场景那 MyCat 的弱 XA 大概率满足不了你得上专门的事务协调组件。如果你的数据量其实没到瓶颈只是查询慢那该做的是加索引、优化 SQL、上缓存而不是引入分库分表因为后者带来的复杂度是成倍增加的。还有一个容易被忽略的点中间件会把很多数据库层面的报错模糊化。原生 MySQL 报错会告诉你具体哪个字段、哪一行、什么约束冲突经过 MyCat 之后有些错误会被包装成通用的执行异常定位成本明显上升。所以上中间件之前先想清楚团队有没有能力承接这种排障成本的上升。4. 落地第一步环境准备与启动验证4.1 JDK 与后端数据库的前置检查MyCat 是纯 Java 应用JDK 是硬依赖。1.6 系列的编译目标比较老用 JDK 8 跑是最稳的组合JDK 11 及以上不是完全跑不起来但可能遇到反射相关的报错尤其是老版本的日志框架和字节码库在模块化限制下容易出问题。所以我的建议很明确单独装一个 JDK 8 给 MyCat 用别跟其他服务混用。后端 MySQL 这边需要提前准备好若干个真实的库库名、字符集、账号权限都要配好。字符集建议统一成utf8mb4不然中文和表情符号过一遍中间件之后可能出现乱码而且这种乱码往往在测试阶段发现不了上了生产才暴露。账号权限方面MyCat 连接后端的账号需要具备建表之外的常规读写权限如果开了自动建表或者全局序列表还要加上对应的 DDL 权限。还有一点后端库的表结构必须完全一致索引也要一致否则路由到不同分片的同一条 SQL 可能表现不同这类问题极其难查。4.2 解压后的目录结构与关键文件解压到一个干净的路径比如D:\middleware\mycat或者/opt/mycat。目录结构长这样mycat/ ├── bin/ # 启动停止脚本 ├── catlet/ # 扩展脚本 ├── conf/ # 全部配置文件 ├── lib/ # 依赖 jar ├── logs/ # 日志输出 └── version.txtconf里最先要动的是三个 XML。动手之前先做一件事把原始的conf目录整体复制一份备份命名成conf.bak。我见过太多人改崩了配置之后想回滚结果发现原文件被覆盖了只能重新解压。这一步花不了三十秒救命的概率却不低。lib目录里有个细节值得留意里面内置的mysql-connector-java版本通常偏老。如果你后端是较新的 MySQL驱动需要手工替换——把新版本的驱动 jar 放进去老版本的删掉或者改名备份。替换的时候注意别同时留两个版本的驱动类加载顺序不确定容易出现莫名其妙的连接异常。4.3 Windows 与 Linux 的两种启动方式Windows 下双击startup.bat是最直接的方式它会弹出两个控制台窗口一个 wrapper 守护、一个 JVM 主进程。调试阶段我更推荐用startup_nowrap.bat只有一个窗口日志直接打屏CtrlC 就能停看启动异常特别方便。mycat.bat start是命令行的等价写法适合写进批处理脚本里。Linux 下的用法是bin/mycat start、bin/mycat status、bin/mycat stop三件套底层还是调startup.sh。这里有两个常见坑一是脚本要有执行权限chmod x bin/*.sh先做一遍二是脚本里对JAVA_HOME的依赖如果系统里没配环境变量需要在conf/wrapper.conf里显式指定wrapper.java.command指向 java 可执行文件的绝对路径。另外logs/wrapper.log是启动阶段的第一手信息源如果进程起不来、控制台什么也没打印先去翻这个文件八成能直接看到原因。启动参数也要提前调。默认的 JVM 堆内存在中小数据量下够用但如果你的分片多、并发高、结果集合并频繁堆会很快吃满表现是频繁 Full GC 甚至 OOM。我一般会显式设置成-Xms2g -Xmx2g起步然后观察logs目录下的 GC 情况再决定要不要往上加。直接在wrapper.conf里改wrapper.java.additional那几行就行。4.4 用 9066 和 8066 两个端口做启动验证启动成功的标志不是窗口没关而是要验证两个端口都通了。8066 是数据端口对外提供 MySQL 协议服务9066 是管理端口用来查看运行状态、执行运维命令。这两个端口的定位完全不一样很多人只知道 8066遇到问题就抓瞎。验证方式很简单用任何 MySQL 客户端连 9066执行show help能看到一屏命令列表就说明起来了。常用的几条show database看逻辑库列表show datanode看数据节点状态show datasource看后端连接池show heartbeat看后端库的心跳检测结果。心跳那一条尤其重要它会告诉你每个物理库是OK还是ERROR连不上后端的时候这里一眼就能看出来。再连 8066用server.xml里配置的账号登录执行show databases应该能看到你定义的逻辑库名。到这一步环境就算通了。接下来才是真正花时间的部分——把schema.xml和rule.xml配对写好。提示管理端口 9066 只应该在受控网络内开放不要暴露到公网。它没有额外的权限校验层能连上就能查配置、看连接、执行运维命令。5. 三份核心配置文件的逐项拆解5.1 server.xml用户、逻辑库与系统参数server.xml的结构很简单一个system节点管全局参数下面若干个user节点管账号。最常改的几个系统参数sequnceHandlerType决定全局序列的生成方式0 是本地文件、1 是数据库、2 是时间戳算法、3 和 4 是基于协调服务的分布式 ID做分片表并且需要自增主键的话这个必须配否则插入时主键会冲突defaultSqlParser指定 SQL 解析器1.6 默认用 druid 解析器兼容性最好useOffHeapForMerge控制结果集合并是否走堆外内存数据量大的时候打开能减少 GC 压力。用户配置是这样的user nameapp_user defaultAccounttrue property namepasswordyour_password/property property nameschemasORDER_DB/property property namereadOnlyfalse/property /userschemas是授权给这个用户的逻辑库列表多个用逗号分隔。这里有个隐含的坑逻辑库名必须和schema.xml里schema节点的name属性严格对应大小写敏感写错了不会报配置错误但登录后show databases是空的会让人以为服务没起来。readOnly设成true时这个账号执行写操作会被拒绝适合做只读报表账号。5.2 schema.xml分片表、全局表与数据节点这份文件是整套配置的骨架三层结构从外到内schema定义逻辑库dataNode定义数据节点逻辑库里的一个分片dataHost定义物理数据源。中间用table节点把逻辑表和分片规则绑起来。schema nameORDER_DB checkSQLschemafalse sqlMaxLimit100 table namet_order dataNodedn1,dn2,dn3,dn4 rulemod-long primaryKeyorder_id/ table namet_user dataNodedn1 primaryKeyuser_id/ table namet_dict dataNodedn1,dn2,dn3,dn4 typeglobal primaryKeyid/ /schema dataNode namedn1 dataHosthost1 databaseorder_db_0/ dataNode namedn2 dataHosthost1 databaseorder_db_1/ dataNode namedn3 dataHosthost2 databaseorder_db_0/ dataNode namedn4 dataHosthost2 databaseorder_db_1/ dataHost namehost1 maxCon1000 minCon10 balance0 writeType0 dbTypemysql dbDrivernative switchType1 slaveThreshold100 heartbeatselect user()/heartbeat writeHost hosthostM1 url127.0.0.1:3306 userroot passwordpwd/ /dataHost几个参数值得单独解释。sqlMaxLimit是个保护阀客户端不带limit的查询会被自动加上这个上限防止一次拉回几百万行把内存打爆测试阶段可以调小到 10 方便观察生产上按业务定通常 100 到 1000 之间。checkSQLschema控制是否剥离 SQL 里的库名前缀如果你的应用习惯写ORDER_DB.t_order设成true更友好如果你的代码里混用了多种写法设false然后统一规范。balance控制读操作的分配策略0 是不分离、1 是所有从库参与读负载、2 是读写都随机分发、3 是只从从库读。writeType控制写操作的路由0 是只发第一个 writeHost1 是按双主随机发。switchType是主从切换策略1 是默认的自动切换。dbDriver我建议用native它走的是 MyCat 自己实现的后端连接比jdbc模式性能好一些代价是只能在 MySQL 协议下用。typeglobal的全局表是个很实用的设计字典表、配置表这类数据量小、几乎不变的表在每个节点上都存一份完整副本跨节点 join 的时候只在本地做不需要数据搬运。代价是写操作要同步到所有节点所以只适合读多写极少的数据。5.3 rule.xml分片算法的选择与参数rule.xml里分成两段tableRule定义哪张表的哪个字段用什么算法function定义这个算法具体怎么算。tableRule namemod-long rule columnsorder_id/columns algorithmmod-long/algorithm /rule /tableRule function namemod-long classio.mycat.route.function.PartitionByMod property namecount4/property /functioncolumns是分片字段count是分片数量。这里的count必须和schema.xml里dataNode列出的节点数严格一致写 4 但只配了 2 个节点落不到的节点上会直接报错。这是最常见的配置错误之一改分片的时候两边一定要同步改。如果要按字符串哈希分片用PartitionByHash它有个hashSlice参数控制对字符串的哪一段做哈希格式是start:end的切片写法比如0:3表示取前三个字符-4:0表示取后四个字符。这个参数调得好不好直接影响数据分布是否均匀。我见过用手机号做分片字段但只取前 3 位的配置结果所有 138 开头的号码全挤在一个分片上等于没分。按日期分片用PartitionByDate需要配dateFormat、beginDate、partionDay三个参数。beginDate是起始日期partionDay是每个分片覆盖的天数。这里最坑的地方是一旦数据写入beginDate就绝对不能改改了会导致旧数据算出来的分片位置对不上查询直接查不到。所以配这个参数的时候起始日期要往前留足余量宁可多分几个空片也别事后想改。5.4 一个两库四表的分片实例与参数计算光看配置没感觉走一遍完整的例子。假设场景是订单表规划两个物理库order_db_0和order_db_1每个库里建两张表t_order_0和t_order_1总共四个数据节点按order_id取模分片。先建库建表两个库结构完全一致CREATE DATABASE order_db_0 DEFAULT CHARACTER SET utf8mb4; CREATE DATABASE order_db_1 DEFAULT CHARACTER SET utf8mb4; CREATE TABLE order_db_0.t_order_0 ( order_id BIGINT NOT NULL, user_id BIGINT NOT NULL, amount DECIMAL(12,2) NOT NULL, create_time DATETIME NOT NULL, PRIMARY KEY (order_id), KEY idx_user (user_id) ) ENGINEInnoDB;其余三张表照抄只改库名和表名。注意这里的主键是order_id没有用自增因为分片环境下自增主键会冲突要么用全局序列要么用业务侧生成的雪花 ID。接着配dataNode四个节点分别指向两个库里的两张表dataNode namedn1 dataHosthost1 databaseorder_db_0 tablet_order_0/这里有个细节dataNode的database属性可以写成order_db_0.t_order_0的合体形式也可以用单独的table属性两种写法等价选一种保持统一就行。然后是rule.xml里配mod-longcount设成 4。算法很简单order_id % 4的结果决定路由。我们来算几条order_idorder_id % 4目标节点物理位置10011dn2order_db_0.t_order_110022dn3order_db_1.t_order_010033dn4order_db_1.t_order_110040dn1order_db_0.t_order_0注意节点编号和取模结果差一位dn1对应余数 0。这个对应关系是由schema.xml里dataNode属性的书写顺序决定的写dataNodedn1,dn2,dn3,dn4就意味着余数 0 落dn1、余数 1 落dn2以此类推。这个顺序一旦上线就不能随便调整调整等于全量数据重分布。最后验证。连 8066往t_order插四条数据然后分别去四个物理表里select count(*)每个表应该正好一条。再执行select * from t_order where order_id 1002看是不是只返回一条同时去 9066 执行show sql之类的命令看执行记录确认只打到了一个节点上。这一步验证通过分片就算真正跑通了。6. 实测中踩过的坑与排查路径6.1 启动阶段起不来先看这三处启动失败的表现形式很多但排查顺序基本固定。第一步看logs/wrapper.log如果连 JVM 都没拉起来这个文件里会有明确的原因最常见的是JAVA_HOME没配或者路径里有空格。第二步看logs/mycat.logJVM 起来了但应用初始化失败日志会打在这里配置文件的 XML 语法错误、端口被占用、依赖 jar 缺失都会在这一层暴露。第三步才是看控制台输出因为前面两个文件通常已经把话说清楚了。XML 语法错误是高频问题尤其是手改配置的时候多删了个标签闭合。有个快速自检的办法用任何支持 XML 格式化的编辑器打开格式化一遍如果结构乱了说明括号不配对。另外注意server.xml和schema.xml里的注释不能嵌套!-- !-- -- --这种写法会直接解析失败。端口占用也遇到过几次表现是启动日志里刷一串Address already in use但进程看着还在。这时候先netstat -ano | findstr 8066Windows或者lsof -i:8066Linux确认谁占着别急着重启先把占用进程处理掉。6.2 客户端连不上或者连上就断能 ping 通端口但客户端连不上问题通常出在认证环节。最典型的是用较新版本的 MySQL 客户端连接时客户端默认走的是较新的认证插件而 MyCat 只支持传统的密码认证方式握手阶段直接失败报错信息还相当含糊。解决办法是在连接串里显式指定认证插件或者在服务端把账号的认证方式改掉。这个坑在升级客户端版本之后特别容易撞上因为老客户端能连、新客户端不能连很容易误判成服务端坏了。另一类是连上之后过一会儿自动断开。检查dataHost里的maxCon和minConminCon是连接池的保活下限设得太小会导致连接频繁创建销毁加大后端压力maxCon设得太大则可能把后端 MySQL 的连接数打满。一般minCon给 10maxCon按单机 500 到 1000 起步然后观察后端show processlist的实际占用。还有一种情况是连上了、查询也返回了但客户端会报一些协议层面的警告。这类问题通常和字符集有关检查连接串里的characterEncoding和后端库的字符集是否一致不一致的时候中文数据会出现截断。6.3 路由结果和预期对不上明明order_id 1002应该落在dn3结果查不到数据或者查出来是空的。排查的第一步是在 9066 端口执行show datanode看四个节点的状态是不是都是OK有ERROR的先解决连通性。第二步是确认数据到底写进了哪个物理表用后端账号直连四个表挨个select count(*)如果数据实际落在别的表里说明分片字段的值和你以为的不一样——比如order_id在应用侧是字符串1002取模前做了类型转换结果可能和你手算的不一致。还有一种更隐蔽的情况分片字段在 SQL 里被函数包裹了。where abs(order_id) 1002这种写法解析器识别不出分片字段的原始形态只能退化成全节点广播结果虽然对但性能损失巨大从 9066 的show sql里能明显看到一条 SQL 被打到了四个节点。这类写法要在代码评审阶段就拦住分片字段上不要套任何函数。6.4 跨库查询和结果合并的陷阱跨分片的order by加limit是最容易出问题的组合。上面说过limit m, n会被改写成每个分片取m n条再内存裁剪如果m特别大比如翻到第 100 万条那每个分片都要取回 100 万条内存直接崩。大偏移量的深分页在分片环境下几乎必然出问题正确的做法是改成基于游标的翻页用上一页最后一条的 ID 作为下一页的起始条件把offset消掉。count(distinct xxx)也要小心。如果去重的字段不是分片字段每个分片算出来的去重结果可能包含重复值MyCat 需要在内存里再做一次去重数据量大时同样是内存风险。group by也是类似道理分组键不是分片键时必须把所有分片的数据拉回来统一分组。跨库 join 干脆就别指望。1.6 只支持基于父子表关系的有限 join需要你在schema.xml里用childTable显式声明关联关系而且关联条件必须严格匹配。任意表之间的 join 会退化成广播性能惨不忍睹。这种查询老老实实拆成两次单表查询在应用层做组装比自己跟中间件较劲省事得多。6.5 常见问题速查表现象大概率原因排查动作启动无输出进程消失JAVA_HOME 未配或路径含空格查 wrapper.log检查环境变量8066 连不上9066 正常server.xml 用户或 schemas 配错核对逻辑库名大小写客户端握手失败认证插件不兼容连接串显式指定传统认证方式查询返回空但数据存在分片字段被函数包裹导致广播失败直连物理库核实数据落点跨分片分页越翻越慢深分页改写放大改为游标翻页主键冲突未配置全局序列检查 sequnceHandlerType 与序列表主从切换后写入失败switchType 与主从状态不匹配查 show heartbeat 与后端主从状态内存持续上涨结果集合并占用堆内内存开堆外合并或缩小 sqlMaxLimit7. 上线之前值得想清楚的几件事配置跑通和能在生产上跑中间还差着一段距离。我自己的经验是这套东西的复杂度大头不在启动而在出事的时候你能不能快速定位。所以上线前有件事必须做把 9066 端口的常用命令整理成一页纸贴在团队文档里尤其是show sql、show connection、show heartbeat、reload config这几条出问题的时候能省下大量时间。reload config特别值得记住改完schema.xml和rule.xml之后不用重启进程就能生效但server.xml的改动一般还是要重启这一点别搞混。扩容这件事要提前想。取模分片从 4 个节点扩到 8 个所有数据都要重新分布这个迁移量在大表上可能是几十小时。如果预判到数据会持续快速增长一开始就该选一致性哈希或者预留足够的范围分片哪怕前期节点数少、有些节点是空的也比后期停机迁移划算。这个判断没有标准答案取决于你的数据增长曲线和可接受的停机窗口。最后一点也是我个人体会最深的中间件这层一定要有降级方案。当 MyCat 出问题的时候你的应用能不能快速切回直连某个物理库哪怕只能保证部分核心功能可用也比全站不可用强。我见过没有降级预案的团队中间件一挂排查和恢复的时间全部变成了故障时长。提前在配置里留好直连的开关把切换步骤写进预案并演练一遍这件事的价值在你真正用上它的那天才会体现出来。