简介这份「mycat2基础安装包」面向需要快速搭建分布式数据库中间件环境的Java开发、DBA与运维人员重点解决Mycat2部署时依赖库、配置模板与启动脚本分散、环境准备繁琐的问题。压缩包共51个文件约1.2MB包含SQL脚本、JSON与XML配置、JAR依赖、跨平台启动脚本及各类本地库文件覆盖从服务启动到分片规则、数据源与序列配置的基础要素目录组织相对完整。已有1072人学习说明其在Mycat2入门部署场景中具有一定参考价值。读者可据此获得一套可直接解压使用的Mycat2基础运行环境结合其中的配置样例与SQL文件较快开展数据分片、读写分离、SQL路由等功能的本地验证也为后续节点扩展、监控管理和故障切换实验提供统一的起点适合作为学习分布式数据库中间件部署与配置的实践材料。1. 先弄明白一件事mycat2 到底是个什么东西新手第一次听到 mycat2第一反应常是“又一个要装的软件”接着就卡住它不是数据库也不是写业务的框架那装它图什么。生活里有个很像的场景一家小店只有一个收银台人一多就排队老板没把柜台拆了重建而是在门口放了个调度员告诉你该去几号台结账。mycat2 干的就是调度员的活应用照常连它、照常写 SQL它在中间决定这条语句去哪个库、哪张表上执行。一句话版本mycat2 是开源的数据库中间件对上层把自己伪装成 MySQL对下层管着一堆真实数据库。适合后端开发、运维和做课程设计的人尤其碰到单表数据涨得快、单库连接吃紧、想拆又不想改业务代码的时候。入门阶段先做到三件事就够安装包跑起来、端口连得上、一条查询被它转给后面的库。这三步通了后面再谈分片规则就不发怵了。2. 为什么值得学从单库顶不住到多库协作的那道坎2.1 单库什么时候开始难受三个信号很多新手以为“分库分表”是大公司才玩的东西其实它更像一个容量问题和公司大小关系不大。你可以把单库想成一个仓库刚开始几十件货随手一翻就找到等到货物堆到天花板找一件货要绕三圈进出库还要排队这时候不是员工不努力是仓库的结构到边界了。数据库也一样下面三个信号出现得越多越说明你该了解中间件了。第一个信号是单表数据量涨得很快。几十万行以内大多数单库单表配合合理索引都很轻松到了千万级、往亿级走哪怕索引建得不错慢查询也会开始变多加字段、改索引这类操作要等的窗口越来越长。第二个信号是连接数吃紧应用一扩容数据库连接池就被打满报错里开始出现 too many connections 之类的字样。第三个信号是备份和迁移越来越不敢做一次全量备份要跑很久出问题回滚的成本高得让人犹豫。这三个信号不需要同时出现中一个就值得往下看。入门时你不需要立刻动手拆先建立判断我现在这套库是在“还能撑”的阶段还是已经进了“再扛下去要出事”的阶段。判断清楚学 mycat2 才有目标不然装完也不知道拿它干嘛。提示先别急着把现有库拆开拿一张增长最快的表估一下半年后的行数这个数字比任何教程都更能告诉你该不该学。2.2 mycat2 在中间补了哪四样能力第一样是“逻辑库、逻辑表”。应用看到的是一个库、一张表名字和原来一样SQL 也照原样写真实数据被拆到几个物理库里这个对应关系由 mycat2 维护。类比一下你在前台报“我要找三号货架”前台知道三号货架其实分在 A、B 两个仓但不需要你操心。第二样是分片路由。同一张逻辑表按某个字段的规则拆到不同节点比如按用户 ID 取模、按时间范围切。应用写select * from orders where user_id 1001mycat2 算出 1001 落在哪个分片只把这条语句发到那个库而不是把所有库都扫一遍。这一步做对查询才不会退化成“广播”。第三样是读写分离。写操作走主库读操作按配置分发到从库应用侧通常不用改代码。对新手的意义在于你可以在本地用一台机器起一个主库加一个从库把这条链路跑通理解“写主读从”到底是怎么落地的。第四样是 MySQL 协议兼容。应用原本用 MySQL 驱动连数据库换成连 mycat2 的端口驱动和大部分 SQL 写法不用换。这一条对入门特别友好你不需要先学一套新 API就能把原来的连接串改个端口试起来。这四样能力叠在一起才构成“中间件”三个字。单独看每一样都不复杂难的是它们要一起工作所以入门顺序建议是先连一个库、一张表把协议兼容跑通再加第二个节点看路由有没有按预期走最后才碰读写分离和复杂分片。顺序反了容易在一堆报错里失去方向。2.3 入门为什么先学它而不是自己写分片逻辑有人会问分片规则我在应用层自己写不就行了多一个中间件不是多一层故障点吗。这话不算错但要看你处在什么阶段。应用层自己写路由最直接的代价是代码侵入每个查询都要带分片键跨库聚合要自己拼改一次规则要动很多地方业务代码和分片逻辑搅在一起新人接手时像看黑匣子。mycat2 这类中间件的思路是把路由收敛到配置里业务代码尽量保持原样。对入门者来说这个特点很关键你可以先把“分片”当成一个配置问题来理解而不是一上来就写一堆路由代码。配置错了改配置重启就能验证规则想换主要动配置文件。学习反馈快踩坑成本也低。但它不是银弹这一点新手越早接受越好。跨库 join、跨库事务、全局排序、分页深翻这些在单库里理所当然的事到了多库环境会变得麻烦中间件只能缓解不能变魔术。我第一次配跨库查询的时候理所当然地写了个 join结果翻车日志里提示要下发的节点不对才意识到“逻辑上是一张表物理上是两张表”。所以入门的目标不是“学会所有高级特性”而是先建立边界感哪些事它帮你做了哪些事它做不了、需要你在设计上绕开。3. 第一个例子跑起来装好之后连上 8066 端口3.1 装之前先确认三件事JDK、MySQL、端口动手之前先把环境摸清楚比装到一半再回头查要省时间。mycat2 是 Java 写的跑起来要有 JDK它后面要接真实数据库所以本机或局域网里得有一个能连的 MySQL 实例它对外要监听一个端口默认常见是 8066这个端口别和已有服务撞上。先在终端里跑三条检查命令看清楚现状再往下走# 看 JDK 版本mycat2 需要 Java 运行环境版本要求以安装包说明为准 java -version # 看本机 MySQL 客户端和服务是否可用后面要用它做后端库 mysql --version # 看 8066 端口有没有被占用有输出说明已被别的程序占了 ss -lntp | grep 8066第一条命令输出里会带版本号重点看主版本别拿系统里最新的 JDK 硬试安装包说明里写支持哪个大版本就装哪个这是最省事的做法。第二条只确认客户端存在还不够你还要有一个能登录的账号和密码后面配置里要填。第三条如果没有输出说明 8066 空着可以直接用有输出就换个端口或者先把占用它的进程停掉。注意JDK 装完后确认JAVA_HOME指向的是你要用的那个版本机器上装了多个 JDK 时命令行java -version和实际启动脚本用的可能不是同一个这是后面“启动一闪而过”的常见原因。3.2 解压之后先认目录bin、conf、lib、logs安装包解压出来先别急着改配置花两分钟把目录认一遍。不同打包方式目录名可能略有差异但职责基本是这几块目录放什么新手先看什么bin启动、停止脚本确认启动脚本的实际文件名conf服务配置、数据源配置、逻辑库表配置模板文件和注释先读再改lib依赖的 jar 包一般不动别随手删logs运行日志启动失败时第一时间来这里认目录的意义在于建立“出问题去哪找”的直觉。启动脚本叫什么、配置放在哪个文件、日志落在哪里这三件事清楚了后面遇到报错就不会满目录乱翻。conf 里的模板通常带注释哪怕注释是英文也建议先扫一遍里面往往写着“这一项必填”“这一项不填走默认”比你猜要快。3.3 写一份最小配置先只连一个库、只放一张表第一份配置的目标不是“把生产环境搬进来”而是“让一条查询能走通”。所以先只配一个后端 MySQL、一个逻辑库、一张逻辑表分片先不拆所有数据落在一个节点上。这样做的好处是变量少出了问题容易定位等你看到查询成功返回再加第二个节点验证路由。改配置前先备份原文件这是血泪经验模板被覆盖后想找回默认值很麻烦。步骤按下面走进入 conf 目录把要改的模板文件复制一份带日期后缀的备份。打开数据源相关配置填后端 MySQL 的地址、端口、库名、账号、密码。打开逻辑库配置给应用定义一个库名比如demo_db并关联到刚才的数据源。打开逻辑表配置把一张真实存在的表登记成逻辑表指向那个数据节点。保存先不启动回头把改过的每一项对一遍。配置项的名字各版本会有差异下面用一份示意的键值清单说明“要填哪些东西”字段名以安装包里的模板为准# 以下为示意实际键名以 conf 目录里的模板为准 # 后端真实数据库连接信息 datasource.urljdbc:mysql://127.0.0.1:3306/demo datasource.usernamedemo_user datasource.password改成你自己的密码 # 应用连接 mycat2 时看到的逻辑库名 schema.namedemo_db # 逻辑表名与它所在的数据节点 table.nameorders table.dataNodedn1这段配置里datasource.url指向的是真实 MySQL库名demo必须已经存在否则启动后第一次查询就会报连不上datasource.username和密码是 MySQL 侧的账号不是 mycat2 自己的登录账号这两个概念新手特别容易混。schema.name是应用侧看到的库名可以和你原来的库名保持一致这样连接串只改端口就能跑。table.name要先在真实库里存在逻辑表不是凭空建表它只是给真实表起一个对外的名字。如果你想让应用连上来时用的账号也可控还要在用户配置里加一个登录账号指定它能看到哪个逻辑库。入门阶段可以先沿用模板里的默认账号等跑通之后再改成自己的。3.4 启动与验证在客户端里看到你的逻辑库启动脚本在 bin 目录里名字以安装包为准常见是mycat或startup这类先ls看一眼再执行别照着教程硬敲# 进入 bin 目录先看实际脚本名 ls -l # 启动服务脚本名以 ls 结果为准 ./mycat start # 启动后立刻看日志尾部确认没有异常堆栈 tail -n 50 ../logs/wrapper.log启动命令执行完不要假设它成功了马上去看日志。日志文件常见名字是wrapper.log或console.log以目录里实际存在的为准。看到类似“started”“listening”这类字样再往下走看到异常堆栈先解决堆栈别急着连客户端否则你会在“连不上”和“启动失败”之间来回怀疑。服务起来后用 MySQL 客户端连 mycat2 的端口注意这里连的不是后端 MySQL# -P 是大写指的是 mycat2 的服务端口不是后端 MySQL 的 3306 mysql -h 127.0.0.1 -P 8066 -u 你的逻辑账号 -p连上之后依次执行三条语句每一步都在验证一件事-- 1. 看逻辑库是否出现在列表里 show databases; -- 2. 切到你配置的逻辑库 use demo_db; -- 3. 看逻辑表是否可见再查一条数据 show tables; select count(*) from orders;第一条show databases能看到你在配置里定义的demo_db说明逻辑库这一层生效了如果只看到信息库、没有你的库回去检查逻辑库配置有没有加载。第二条use能切进去说明账号对这个库有权限。第三条show tables能看到orders说明逻辑表登记成功select count(*)能返回数字说明请求确实被转发到了后端 MySQL 并拿回了结果。到这一步第一个例子就算跑通了。跑通之后建议做一个小实验把后端 MySQL 停掉再执行一次select count(*)看报错长什么样然后恢复。这个动作能让你记住“中间件本身活着”和“后端库活着”是两回事后面排查问题时这个区分能省很多时间。4. 新手避坑五个最容易翻车的地方入门阶段大部分时间不是花在“写对”而是花在“排错”。下面五条是新手最容易撞上的每条按现象、原因、解决写遇到时照着对。4.1 启动脚本一闪而过日志里报类找不到现象是执行启动命令后没有任何输出或者只打印一行就退出ps里看不到进程。打开日志往往能看到ClassNotFoundException、UnsupportedClassVersionError这类字样。原因基本落在 Java 环境上要么机器上没装 JDK、只装了 JRE要么JAVA_HOME指向的版本和安装包要求的不一致要么启动脚本里写死的路径和你实际安装路径对不上。解决顺序是先用java -version和echo $JAVA_HOME确认当前用的是哪个版本再对照安装包说明里写的版本要求。版本不对就换别抱着“新版应该兼容”的侥幸心理硬试。路径不对就改启动脚本里的变量或者把 JDK 装到脚本期望的位置。改完再启动仍然失败就继续看日志最上面那段堆栈的第一行通常就写着根因。4.2 客户端连 8066 被拒绝现象是mysql -h 127.0.0.1 -P 8066报Cant connect to MySQL server或Connection refused。原因有三种常见情况服务根本没启动成功你以为它起来了其实进程已经退出端口被别的程序占用启动时绑定失败或者服务只监听了某个网卡地址你用的地址不在监听范围内。解决时先确认进程在不在再看端口有没有在监听最后看日志里有没有绑定失败的记录。如果是端口冲突改配置里的端口同时记得客户端连接时也要改成新端口。如果是监听地址问题把配置里的绑定地址改成0.0.0.0或你实际使用的地址重启后再连。这里不要凭感觉改防火墙先在服务端本机用127.0.0.1连一次能连上就说明是网络层的事连不上就还是服务自身的问题。4.3 后端 MySQL 报 Access denied现象是客户端能连上 mycat2但一查表就报错日志里出现Access denied for user。原因是数据源配置里的账号密码不对或者这个 MySQL 账号只允许从特定主机登录而 mycat2 所在机器的地址不在允许列表里。还有一种情况是账号密码里含有特殊字符在配置文件里没有转义。解决时先用同一个账号密码直接用 MySQL 客户端连后端库验证一次排除密码记错的可能。能连上但 mycat2 连不上就去看账号的授权主机范围需要在 MySQL 侧给这个来源地址授权。密码含特殊字符的按配置文件的转义规则处理或者先换一个简单密码验证链路通了再改回去。4.4 配置改完像没改一样现象是明明改了逻辑库名或者数据源地址重启后行为还是旧的。原因通常是改错了文件conf 目录下可能有多个相似文件一个是模板、一个是实际加载的你改的那份没被读取或者改完没有真正重启进程还是旧的再或者配置有语法错误加载失败后回退到了默认值。解决办法是先确认服务加载的是哪个配置文件日志启动阶段一般会打印出来。改之前备份、改之后对比能避免改错文件。重启要用停止再启动的方式确认旧进程已经退出别只看启动命令返回成功。配置语法错误会在日志里留下解析异常照着行号改就行。4.5 表能连上但查询报找不到表现象是show tables能看到逻辑表但一查就报Table doesnt exist。原因是逻辑表登记了但后端真实库里没有这张表或者表名大小写不一致或者数据节点指向的库不对。逻辑表只是对外的名字它不会替你在后端建表。解决时直接去后端 MySQL 里确认这张表存不存在、在哪个库、表名大小写是什么。存在但查不到就核对数据节点配置里的库名和表名映射。需要强调的是入门阶段别指望中间件帮你建表建表这件事仍然在后端库做中间件只负责路由。5. 下一步学什么从能跑通到能改对一条分片规则第一个例子跑通之后最容易犯的错是马上扎进复杂分片配了一堆规则结果一条查询对不上就卡住。比较稳的路径是按“先能看懂一条 SQL 去哪了再能改对一条规则”的顺序推进下面这张表可以当作接下来两三周的学习路线。顺序学什么具体做法判断学会的标准1SQL 路由打开日志观察一条带分片键的查询被发到哪个节点能说出这条语句为什么去这个库2分片规则先试按 ID 取模再试按时间范围能自己加一个节点并让数据落对3读写分离本地起一主一从配好写走主、读走从能通过日志区分读写走了哪边4边界问题故意写一个跨库 join、一个跨库分页能说清它为什么不好使、怎么绕第一步的重点不是背配置而是建立“语句和节点”的对应关系。你可以只配两个节点写几条不同分片键的查询然后去日志里找它们分别落到哪。看懂这一层后面改规则才不会瞎试。第二步开始碰分片规则时建议从取模开始因为它最直观用户 ID 对节点数取余余数就是节点编号。跑通之后再加一个节点观察已有数据会不会重新分布这个动作能让你直观理解“扩容为什么要迁移数据”。范围分片可以放在后面按时间切在日志、订单这类场景里很常见但它对“热点落在同一个节点”更敏感需要你提前想到。第三步是读写分离。本地用两个 MySQL 实例一个主一个从把复制关系建起来再在配置里指定写库和读库。这里有个细节值得反复确认同一条连接里先写后读读会不会因为走了从库而看不到刚写的数据。这个现象不是 bug是主从延迟理解它比记住配置项更有用。第四步是主动找边界。自己写一个跨库 join、一个不带分片键的查询、一个跨库分页看它们分别怎么表现日志里报什么。这些“不顺手”的地方才是你真正理解中间件定位的地方。我第一次配分片规则的时候改完配置直接重启就连结果数据全落到一个节点上查了半天才发现规则里引用的字段名和表里实际字段对不上配置不报错只是默默走了默认路由。从那以后我每次改完规则都强制自己先插三条不同分片键的数据再去每个节点里数一遍行数确认分布对了才继续。这个习惯看着笨但能省掉大量“以为配好了其实没生效”的时间。希望帮到你。本文还有配套的精品资源点击获取