简介这份 mycat2 基础安装包面向需要搭建分布式数据库中间件的 Java 后端开发与运维人员用于解决单机数据库在大数据量、高并发场景下的存储与访问瓶颈。包内共 51 个文件约 1.2MB涵盖 sql 脚本、json 与 xml 配置、properties 属性文件、jar 依赖以及覆盖 Linux、Windows、macOS、AIX、Solaris 等多平台的 wrapper 启动库并附带 mycat 与 mycat.bat 启停脚本解压配置后即可部署 Mycat2 服务实例。资源围绕数据分片、读写分离、SQL 路由、动态扩展与高可用等核心能力组织schema、server、datasources 等配置模块清晰便于理解分片规则与全局参数设置。目前已有 1069 人学习下载适合希望快速上手 Mycat2、搭建可扩展数据库架构的读者参考实践。1. 从一次数据库连接数打满说起mycat2 基础安装包到底装了什么上周有个做电商后端的朋友半夜找我说订单库的连接数突然被打满应用侧疯狂报Too many connections重启一次撑不过十分钟。排查下来不是慢查询是分片逻辑写在了应用层每个服务实例都自己维护一套路由规则扩容时连接池直接失控。这种场景下mycat2 基础安装包就是用来把分片、读写分离、连接管理从业务代码里剥出来的东西。它本质是一个数据库中间件站在应用和 MySQL 之间应用连它就像连一个单机库分片规则、路由、聚合由它内部完成。这份基础安装包解决的是「从零把 mycat2 跑起来」的问题适合正在做分库分表选型、或者已经被应用层分片逻辑折磨过的后端和运维。下面按我实际拆包和部署的顺序把安装、配置、启动、踩坑一条线讲透。2. 拆开基础安装包目录结构、依赖与运行前置条件2.1 安装包里到底有什么拿到 mycat2 基础安装包先别急着解压就启动。我一般会先tar -tzf看一眼结构确认版本和自带依赖避免解压完发现缺东西又回头找。典型的基础包解压后大致是这么几块目录/文件作用是否必须bin/启动、停止、重启脚本必须conf/核心配置数据源、分片规则、schema必须lib/依赖 jar 包含连接池、解析器必须logs/运行日志、SQL 审计日志自动生成mycat2.jar主程序入口必须这里有个容易忽略的点mycat2 和 mycat1.x 的配置体系差别很大1.x 那套server.xml、schema.xml、rule.xml三件套在 2.x 里被拆成了更细的配置文件还引入了类似datasource和cluster的独立描述。如果你拿的是 1.x 的教程去套 2.x 的包第一步配置就会卡住。基础安装包一般会带一份默认配置但默认配置连的是本地 3306生产环境必须改。2.2 运行前置条件JDK 和 MySQL 版本要对齐mycat2 是 Java 写的跑之前 JDK 版本必须确认。我踩过的坑是机器上默认java -version是 1.8但 mycat2 某些构建版本要求 JDK 11 及以上启动脚本里写死了JAVA_HOME检查版本不对直接退出日志里只留一行Unsupported class file major version不仔细看根本找不到原因。# 确认 JDK 版本mycat2 常见要求 JDK 11 java -version # 如果机器上有多个 JDK显式指定 export JAVA_HOME/usr/lib/jvm/java-11-openjdk export PATH$JAVA_HOME/bin:$PATH # 确认 MySQL 可达mycat2 后端连的是真实 MySQL mysql -h 127.0.0.1 -P 3306 -uroot -p -e select version();参数说明JAVA_HOME必须指向 JDK 根目录而不是binMySQL 版本建议 5.7 或 8.0mycat2 对 8.0 的caching_sha2_password认证插件支持取决于驱动版本基础包里自带的驱动如果偏旧连 8.0 会报认证失败这时候要么升级驱动要么给后端账号改用mysql_native_password。这一步不做后面配置写得再对也连不上。2.3 端口和防火墙8066 与 9066 的分工mycat2 默认开两个端口8066是数据端口应用连这个9066是管理端口用来执行show 系列命令看运行状态。基础安装包不会自动改防火墙云主机上如果安全组没放行 8066应用侧会一直超时但 mycat2 自己的日志里一切正常这种「服务活着但连不上」的情况最耗时间。# 确认端口监听 ss -lntp | grep -E 8066|9066 # 本机连通性测试 telnet 127.0.0.1 8066常见做法是先在本地telnet通再从应用机器测一次两层都通再往下走。别跳过这步我见过太多人配置改了半天最后发现是安全组没开。3. 配置数据源与分片规则从单库到分片的落地步骤3.1 配置后端数据源datasource 怎么写mycat2 的数据源配置和 1.x 完全不同它用独立的配置文件描述每个后端 MySQL 实例。基础包里一般有个conf/datasources/目录里面放.datasource.json或类似结构的文件。我一般先配一个最简单的单数据源跑通再加分片。{ name: ds0, type: mysql, url: jdbc:mysql://127.0.0.1:3306/order_db?useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8, user: mycat_user, password: your_password, minCon: 5, maxCon: 50, idleTimeout: 60000 }逻辑说明name是逻辑名后面分片规则里引用它url里的serverTimezone必须显式指定否则跨时区写入会出现时间偏移这个坑在订单场景里很致命minCon/maxCon是连接池上下限maxCon不是越大越好后端 MySQL 的max_connections要留余量否则 mycat2 自己会把后端打满。参数怎么改读多写少的库可以把minCon调大减少建连开销写多的库maxCon要结合后端max_connections除以 mycat2 实例数来算。3.2 分片规则取模、范围还是一致性哈希分片规则是 mycat2 的核心也是最容易配错的地方。基础安装包通常自带几种内置规则常见的有取模分片、范围分片、一致性哈希。选哪种取决于业务订单表按用户 ID 取模分布均匀但扩容要迁移数据按时间范围分片扩容方便但热点集中在新分片。-- 在 mycat2 管理端口 9066 里查看已加载的分片规则 show rule; show datasource;配置分片规则时我一般先在管理端口确认规则加载成功再连 8066 做实际查询验证。这里有个血泪经验分片字段的类型必须和后端表字段类型严格一致user_id是bigint分片配置里写成字符串路由会算错数据写到错误的分片查的时候又查不到现象是「明明插入了却查不出来」排查起来非常玄学。3.3 逻辑库与逻辑表schema 配置的对应关系mycat2 里应用看到的是逻辑库和逻辑表后端是真实库表。配置时要建立映射逻辑库名、逻辑表名、分片规则、数据源节点。基础包的默认 schema 配置一般只给了一个示例生产要按自己的表结构改。{ schemaName: order_schema, defaultDataNode: dn0, tables: [ { tableName: t_order, dataNodes: [dn0, dn1], rule: mod_rule, primaryKey: order_id } ] }逻辑说明dataNodes列出这张表分布在哪些节点rule引用分片规则名primaryKey用于主键路由优化。参数怎么改如果某张表是全局表比如字典表所有节点都要有一份配置方式不同别当成普通分片表配否则查询会漏数据。改完配置后 mycat2 需要重载管理端口执行reload config但重载不是所有配置都生效涉及数据源变更的建议重启这点后面避坑章会细说。4. 启动、验证与常见故障排查4.1 启动脚本与日志观察基础包的bin/下一般有mycat start、mycat stop、mycat restart。启动后别只看脚本返回的success一定要看日志。# 启动 ./bin/mycat start # 实时看启动日志 tail -f logs/mycat.log # 确认进程 ps -ef | grep mycat | grep -v grep日志里出现Mycat Server startup successfully才算真正起来。如果卡在Loading datasource多半是后端 MySQL 连不上或账号密码错如果报ClassNotFoundException是lib/下缺 jar。启动脚本返回成功但进程秒退的情况日志里一定有堆栈别忽略。4.2 用管理端口做健康检查9066 管理端口是排查利器连上去能看数据源状态、连接数、慢 SQL。-- 连接管理端口 mysql -h 127.0.0.1 -P 9066 -uroot -p -- 查看数据源心跳 show heartbeat; -- 查看后端连接池 show backend;show heartbeat里每个数据源的状态如果是OK说明心跳正常ERROR就要去看对应数据源的网络和账号。show backend能看到当前后端连接数如果接近maxCon说明连接池该调了或者有慢查询占着连接不放。4.3 避坑五条我实际踩过的记录现象一应用连 8066 报Unknown database但后端库明明存在。原因mycat2 的逻辑库名和后端真实库名不是一回事应用要连的是逻辑库名配置里schemaName写错或没加载。 解决管理端口show schema确认逻辑库列表应用连接串里的库名改成逻辑库名。现象二插入成功但查询查不到数据像丢了。原因分片字段类型不匹配或分片规则算错数据写到了 A 分片查询路由到了 B 分片。 解决管理端口开 SQL 审计看实际路由到哪个节点核对分片字段类型和规则配置。现象三改了配置reload config后不生效。原因mycat2 的热加载只覆盖部分配置数据源、分片规则这类核心配置变更热加载不一定生效。 解决涉及数据源和规则的改动直接restart别赌热加载。现象四后端 MySQL 连接数暴涨mycat2 自己把库打满。原因maxCon配太大或者多个 mycat2 实例连同一个后端连接数叠加。 解决后端max_connections除以 mycat2 实例数再留 20% 余量给运维连接反推每个实例的maxCon。现象五跨分片查询慢得离谱。原因没走分片字段的查询会广播到所有节点再聚合数据量大时聚合开销高。 解决业务查询尽量带分片字段必须跨片的用全局表或冗余字段别让 mycat2 做全节点扫描。5. 进阶用管理端口做 SQL 审计与连接池调优跑通基础安装只是开始真正让 mycat2 稳定的是后续的观测和调优。我习惯在管理端口常开几个命令做日常巡检。show sql能看到最近执行的 SQL 和耗时show sql.sum看汇总show connection看前端应用连接。这几个命令配合起来能快速定位是应用侧连接泄漏还是后端慢查询。连接池调优上我一般分两步走。第一步先压测用固定并发打 8066观察show backend的连接数曲线如果一直贴着maxCon且响应时间上升说明池子小了或者后端慢。第二步再调minCon/maxCon调完重启验证。这里有个后悔药式的习惯每次改连接池参数前先把当前show backend和show heartbeat的输出存一份改完对比不然出了问题连基线都没有。-- 巡检三连建议做成脚本定时采集 show sql; show sql.sum; show connection;还有一个容易被忽略的点是 SQL 审计日志。基础包默认可能没开审计生产环境建议开但要注意日志量和磁盘。我一般只审计慢 SQL 和跨分片 SQL全量审计在高并发下会把磁盘写满。审计日志的字段里路由节点和耗时是最有价值的排查分片问题时直接看这两个。从那以后我每次部署 mycat2都强制走一遍「管理端口健康检查 → 压测看连接池 → 开慢 SQL 审计」这三步不跳步。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/20 2:32:46 · 阅读 1.2k Mycat2基础安装包部署与分片配置实战：从连接数打满到SQL审计调优
简介这份 mycat2 基础安装包面向需要搭建分布式数据库中间件的 Java 后端开发与运维人员用于解决单机数据库在大数据量、高并发场景下的存储与访问瓶颈。包内共 51 个文件约 1.2MB涵盖 sql 脚本、json 与 xml 配置、properties 属性文件、jar 依赖以及覆盖 Linux、Windows、macOS、AIX、Solaris 等多平台的 wrapper 启动库并附带 mycat 与 mycat.bat 启停脚本解压配置后即可部署 Mycat2 服务实例。资源围绕数据分片、读写分离、SQL 路由、动态扩展与高可用等核心能力组织schema、server、datasources 等配置模块清晰便于理解分片规则与全局参数设置。目前已有 1069 人学习下载适合希望快速上手 Mycat2、搭建可扩展数据库架构的读者参考实践。1. 从一次数据库连接数打满说起mycat2 基础安装包到底装了什么上周有个做电商后端的朋友半夜找我说订单库的连接数突然被打满应用侧疯狂报Too many connections重启一次撑不过十分钟。排查下来不是慢查询是分片逻辑写在了应用层每个服务实例都自己维护一套路由规则扩容时连接池直接失控。这种场景下mycat2 基础安装包就是用来把分片、读写分离、连接管理从业务代码里剥出来的东西。它本质是一个数据库中间件站在应用和 MySQL 之间应用连它就像连一个单机库分片规则、路由、聚合由它内部完成。这份基础安装包解决的是「从零把 mycat2 跑起来」的问题适合正在做分库分表选型、或者已经被应用层分片逻辑折磨过的后端和运维。下面按我实际拆包和部署的顺序把安装、配置、启动、踩坑一条线讲透。2. 拆开基础安装包目录结构、依赖与运行前置条件2.1 安装包里到底有什么拿到 mycat2 基础安装包先别急着解压就启动。我一般会先tar -tzf看一眼结构确认版本和自带依赖避免解压完发现缺东西又回头找。典型的基础包解压后大致是这么几块目录/文件作用是否必须bin/启动、停止、重启脚本必须conf/核心配置数据源、分片规则、schema必须lib/依赖 jar 包含连接池、解析器必须logs/运行日志、SQL 审计日志自动生成mycat2.jar主程序入口必须这里有个容易忽略的点mycat2 和 mycat1.x 的配置体系差别很大1.x 那套server.xml、schema.xml、rule.xml三件套在 2.x 里被拆成了更细的配置文件还引入了类似datasource和cluster的独立描述。如果你拿的是 1.x 的教程去套 2.x 的包第一步配置就会卡住。基础安装包一般会带一份默认配置但默认配置连的是本地 3306生产环境必须改。2.2 运行前置条件JDK 和 MySQL 版本要对齐mycat2 是 Java 写的跑之前 JDK 版本必须确认。我踩过的坑是机器上默认java -version是 1.8但 mycat2 某些构建版本要求 JDK 11 及以上启动脚本里写死了JAVA_HOME检查版本不对直接退出日志里只留一行Unsupported class file major version不仔细看根本找不到原因。# 确认 JDK 版本mycat2 常见要求 JDK 11 java -version # 如果机器上有多个 JDK显式指定 export JAVA_HOME/usr/lib/jvm/java-11-openjdk export PATH$JAVA_HOME/bin:$PATH # 确认 MySQL 可达mycat2 后端连的是真实 MySQL mysql -h 127.0.0.1 -P 3306 -uroot -p -e select version();参数说明JAVA_HOME必须指向 JDK 根目录而不是binMySQL 版本建议 5.7 或 8.0mycat2 对 8.0 的caching_sha2_password认证插件支持取决于驱动版本基础包里自带的驱动如果偏旧连 8.0 会报认证失败这时候要么升级驱动要么给后端账号改用mysql_native_password。这一步不做后面配置写得再对也连不上。2.3 端口和防火墙8066 与 9066 的分工mycat2 默认开两个端口8066是数据端口应用连这个9066是管理端口用来执行show 系列命令看运行状态。基础安装包不会自动改防火墙云主机上如果安全组没放行 8066应用侧会一直超时但 mycat2 自己的日志里一切正常这种「服务活着但连不上」的情况最耗时间。# 确认端口监听 ss -lntp | grep -E 8066|9066 # 本机连通性测试 telnet 127.0.0.1 8066常见做法是先在本地telnet通再从应用机器测一次两层都通再往下走。别跳过这步我见过太多人配置改了半天最后发现是安全组没开。3. 配置数据源与分片规则从单库到分片的落地步骤3.1 配置后端数据源datasource 怎么写mycat2 的数据源配置和 1.x 完全不同它用独立的配置文件描述每个后端 MySQL 实例。基础包里一般有个conf/datasources/目录里面放.datasource.json或类似结构的文件。我一般先配一个最简单的单数据源跑通再加分片。{ name: ds0, type: mysql, url: jdbc:mysql://127.0.0.1:3306/order_db?useSSLfalseserverTimezoneAsia/ShanghaicharacterEncodingutf8, user: mycat_user, password: your_password, minCon: 5, maxCon: 50, idleTimeout: 60000 }逻辑说明name是逻辑名后面分片规则里引用它url里的serverTimezone必须显式指定否则跨时区写入会出现时间偏移这个坑在订单场景里很致命minCon/maxCon是连接池上下限maxCon不是越大越好后端 MySQL 的max_connections要留余量否则 mycat2 自己会把后端打满。参数怎么改读多写少的库可以把minCon调大减少建连开销写多的库maxCon要结合后端max_connections除以 mycat2 实例数来算。3.2 分片规则取模、范围还是一致性哈希分片规则是 mycat2 的核心也是最容易配错的地方。基础安装包通常自带几种内置规则常见的有取模分片、范围分片、一致性哈希。选哪种取决于业务订单表按用户 ID 取模分布均匀但扩容要迁移数据按时间范围分片扩容方便但热点集中在新分片。-- 在 mycat2 管理端口 9066 里查看已加载的分片规则 show rule; show datasource;配置分片规则时我一般先在管理端口确认规则加载成功再连 8066 做实际查询验证。这里有个血泪经验分片字段的类型必须和后端表字段类型严格一致user_id是bigint分片配置里写成字符串路由会算错数据写到错误的分片查的时候又查不到现象是「明明插入了却查不出来」排查起来非常玄学。3.3 逻辑库与逻辑表schema 配置的对应关系mycat2 里应用看到的是逻辑库和逻辑表后端是真实库表。配置时要建立映射逻辑库名、逻辑表名、分片规则、数据源节点。基础包的默认 schema 配置一般只给了一个示例生产要按自己的表结构改。{ schemaName: order_schema, defaultDataNode: dn0, tables: [ { tableName: t_order, dataNodes: [dn0, dn1], rule: mod_rule, primaryKey: order_id } ] }逻辑说明dataNodes列出这张表分布在哪些节点rule引用分片规则名primaryKey用于主键路由优化。参数怎么改如果某张表是全局表比如字典表所有节点都要有一份配置方式不同别当成普通分片表配否则查询会漏数据。改完配置后 mycat2 需要重载管理端口执行reload config但重载不是所有配置都生效涉及数据源变更的建议重启这点后面避坑章会细说。4. 启动、验证与常见故障排查4.1 启动脚本与日志观察基础包的bin/下一般有mycat start、mycat stop、mycat restart。启动后别只看脚本返回的success一定要看日志。# 启动 ./bin/mycat start # 实时看启动日志 tail -f logs/mycat.log # 确认进程 ps -ef | grep mycat | grep -v grep日志里出现Mycat Server startup successfully才算真正起来。如果卡在Loading datasource多半是后端 MySQL 连不上或账号密码错如果报ClassNotFoundException是lib/下缺 jar。启动脚本返回成功但进程秒退的情况日志里一定有堆栈别忽略。4.2 用管理端口做健康检查9066 管理端口是排查利器连上去能看数据源状态、连接数、慢 SQL。-- 连接管理端口 mysql -h 127.0.0.1 -P 9066 -uroot -p -- 查看数据源心跳 show heartbeat; -- 查看后端连接池 show backend;show heartbeat里每个数据源的状态如果是OK说明心跳正常ERROR就要去看对应数据源的网络和账号。show backend能看到当前后端连接数如果接近maxCon说明连接池该调了或者有慢查询占着连接不放。4.3 避坑五条我实际踩过的记录现象一应用连 8066 报Unknown database但后端库明明存在。原因mycat2 的逻辑库名和后端真实库名不是一回事应用要连的是逻辑库名配置里schemaName写错或没加载。 解决管理端口show schema确认逻辑库列表应用连接串里的库名改成逻辑库名。现象二插入成功但查询查不到数据像丢了。原因分片字段类型不匹配或分片规则算错数据写到了 A 分片查询路由到了 B 分片。 解决管理端口开 SQL 审计看实际路由到哪个节点核对分片字段类型和规则配置。现象三改了配置reload config后不生效。原因mycat2 的热加载只覆盖部分配置数据源、分片规则这类核心配置变更热加载不一定生效。 解决涉及数据源和规则的改动直接restart别赌热加载。现象四后端 MySQL 连接数暴涨mycat2 自己把库打满。原因maxCon配太大或者多个 mycat2 实例连同一个后端连接数叠加。 解决后端max_connections除以 mycat2 实例数再留 20% 余量给运维连接反推每个实例的maxCon。现象五跨分片查询慢得离谱。原因没走分片字段的查询会广播到所有节点再聚合数据量大时聚合开销高。 解决业务查询尽量带分片字段必须跨片的用全局表或冗余字段别让 mycat2 做全节点扫描。5. 进阶用管理端口做 SQL 审计与连接池调优跑通基础安装只是开始真正让 mycat2 稳定的是后续的观测和调优。我习惯在管理端口常开几个命令做日常巡检。show sql能看到最近执行的 SQL 和耗时show sql.sum看汇总show connection看前端应用连接。这几个命令配合起来能快速定位是应用侧连接泄漏还是后端慢查询。连接池调优上我一般分两步走。第一步先压测用固定并发打 8066观察show backend的连接数曲线如果一直贴着maxCon且响应时间上升说明池子小了或者后端慢。第二步再调minCon/maxCon调完重启验证。这里有个后悔药式的习惯每次改连接池参数前先把当前show backend和show heartbeat的输出存一份改完对比不然出了问题连基线都没有。-- 巡检三连建议做成脚本定时采集 show sql; show sql.sum; show connection;还有一个容易被忽略的点是 SQL 审计日志。基础包默认可能没开审计生产环境建议开但要注意日志量和磁盘。我一般只审计慢 SQL 和跨分片 SQL全量审计在高并发下会把磁盘写满。审计日志的字段里路由节点和耗时是最有价值的排查分片问题时直接看这两个。从那以后我每次部署 mycat2都强制走一遍「管理端口健康检查 → 压测看连接池 → 开慢 SQL 审计」这三步不跳步。希望帮到你。本文还有配套的精品资源点击获取