企业官网建设流程全解析

简介：mycat2基础安装包是一个面向开源数据库中间件Mycat2的基础部署资源，主要服务于需要在分布式数据库场景中搭建访问层、学习数据分片与读写分离的开发者或运维人员。压缩包内共51个文件，整体约1.2MB，包含schema.xml、server.json等核心配置，以及覆盖Linux、Windows、Solaris、macOS等多平台的wrapper启动组件和动态链接库，用户解压后即可按需调整数据库分片规则、连接池参数与路由策略，快速在当前环境中启动Mycat2服务。目前该资源已有1054人学习下载，在Mycat2相关部署资料中具备一定的实践参考热度。通过这份安装包，读者不仅能获得完整的Mycat2运行骨架，还能结合自带SQL脚本和日志配置理解节点、用户、序列等关键定义，从而减少从零搭建的摸索成本，更高效地完成本地或服务器上的中间件部署与基础验证。

1. MyCat2基础安装包：数据库中间件的第一块起跳板

MyCat2 是站在 Java 与 MySQL 之间的一层数据库中间件，业务代码把 SQL 发给它，它按分片规则把 SQL 路由到真正存储数据的那台 MySQL 上。对于还没上云、又想把大表横向拆开的中小团队，MyCat2 基础安装包是当前成本最低的切入点：下载一个 zip、解压、配一个 yml、启动，就能把一个逻辑库映射到多台 MySQL 实例上。这篇笔记把安装包从下载到跑通讲细：JDK 环境、目录结构、启动脚本、日志定位、数据源配通，按实际部署顺序来，把这一路遇到的坑提前给你标好。

2. 装之前先想清楚三件事：JDK 版本、目录结构、安装包形态怎么选

2.1 为什么 MyCat2 安装包开口就要 JDK 1.8，而不是越新越好

MyCat2 用 Java 写成，bin 目录底下的启动脚本本质就是一段 java -cp 的封装。最省事的方式是把 JDK 装在默认路径，然后配好 JAVA_HOME 和 PATH。注意，网上大量安装失败案例都出在 JDK 版本上，而且出错的姿势出奇一致：装了高版本 JDK，启动直接报 UnsupportedClassVersionError。

先看当前环境到底有什么：

java -version echo ${JAVA_HOME}

如果 java -version 输出的是 17 或 21，第一次启动 MyCat2 十有八九会在日志里甩出 UnsupportedClassVersionError：安装包里的 class 文件是按 JDK 1.8 的目标字节码编译的，低版本 JDK 跑高版本字节码会直接拒绝。反过来，高版本 JVM 跑 1.8 的 class 理论可行，可 MyCat2 内部用了一些反射和线程模型，在高版本 JDK 下会触发模块化访问限制，启动日志里全是 warning，甚至起不来。

我的建议是别挣扎：直接装 JDK 8，设置 JAVA_HOME 指向它。装完之后把环境变量写进 /etc/profile：

export JAVA_HOME=/usr/local/jdk1.8.0_202 export PATH=${JAVA_HOME}/bin:$PATH source /etc/profile

这里有一层容易被新手忽略：PATH 里如果还有别的 java，比如 CentOS 预装的 openjdk 11，那 mycat 启动脚本优先用的是 PATH 上的 java，而不是 JAVA_HOME。所以两层要同时确认。怎么确认环境已经就位？一条命令组合就够：

which java java -version echo ${JAVA_HOME}

三个命令的输出要能对得上：JAVA_HOME 指向的目录里有 bin/java，且版本是 1.8.x。这一步做好，后面启动阶段省掉一半的坑。别小看这个环境准备，我见过太多同事把时间耗在后期排错上，回头一看根因就是 JDK 没钉死。

2.2 解压后的目录结构：bin、conf、lib、logs 各管哪一段

拿到基础安装包之后，不要急着点启动，先花两分钟把目录认一遍。MyCat2 的 release 包解压以后，核心目录就这四个，每个职责都很清晰：

bin 目录下面，Linux 环境跑 ./bin/mycat，Windows 跑 mycat.bat。脚本支持 start、stop、restart、status、console 五个子命令，其中 console 会让 Java 进程在前台运行，所有日志直接打在终端上，适合第一次启动排错用。这一节先记住 console 的存在，后面会反复用到。

conf 目录是配置重地。MyCat2 相比 MyCat1 把一堆 XML 拆成了更少的 YAML 文件，安装包默认带一份完整配置，正常情况下直接启动就能连。我会在启动之前先把 conf 里的 mycat.yml 打开看一眼，重点确认两个键：服务端口和默认用户密码。不同版本默认值有差异，按我的经验端口默认 8066，用户 root，密码 123456，但以你安装包里的实际内容为准，不要背参数，要养成看现场的习惯。

lib 目录几百 MB，放的是运行所需依赖。如果下载安装包时网络中断，解压时发现 lib 里某个 jar 是 0 字节或者名字带 .download 后缀，那启动就会在 ClassNotFoundException 上报错。后面第 4 章我会专门展开这个坑，这里先记住一个判断标准：正常安装包的 lib 目录下应该有几百个 jar 文件，如果只有几十个，说明包有问题，重新下载。

2.3 Release 包、源码包、Docker 包：基础安装包到底选哪个

下载页面提供的资产一般有三类，选错会直接拉长排错链路。

源码包是 tar.gz 或 zip 的源码归档，需要自己有 Maven 构建环境，先编译再部署。适合要改 MyCat2 本身的团队，不适合只想把中间件跑起来的人。Release 二进制包解压即用，带完整 lib 和 conf，这就是标题里说的基础安装包，也是本文默认路径。容器镜像是另一条路线，适合已经把 Docker 作为标准交付方式的团队，但日志、数据卷、网络都要按容器思路处理，排错路径和整包部署完全不同。

选型上，没有现成 Java 环境、也没有统一配置管理工具的团队，直接用 Release 二进制包最省事。容器镜像适合对镜像仓库已经有习惯的团队，但生产环境建议把 conf 目录挂载出来，不然改配置只能进容器里动，容器一重建配置就丢了。

还有一层要额外考虑：后端 MySQL 版本和 MyCat2 的兼容性。MySQL 8.0 的 caching_sha2_password 认证插件曾经坑过一批人。如果你的后端 MySQL 是 8.0.x，记得确认 MyCat2 版本足够新，否则数据源连接时会报认证插件不支持。装之前先想清楚你的后端 MySQL 版本，这比纠结安装包本身大小更重要。选型这件事做扎实了，后面配数据源能少走两小时弯路。

3. 把 MyCat2 基础安装包跑起来：从校验到启动的完整动作

3.1 拿到安装包先校验完整性，别等启动报错再后悔

下载环节最容易出问题，二进制安装包动辄一两百 MB，中转网络一抖动就可能得到损坏文件。下载之后先做校验，尤其要对比官方给的校验值：

md5sum mycat2-xxx-bin.tar.gz sha256sum mycat2-xxx-bin.tar.gz

如果下载页面给出 SHA-256，优先对比 sha256sum 的输出。MD5 只能排除传输损坏，防不了换包。这一步看着多余，但装过几十台机器的人都明白：tar 解压到一半报 "gzip: stdin: unexpected end of file"，比启动报错更让人烦躁。与其解压到一半停下来猜原因，不如下载完先花十秒校验。

解压动作本身也有讲究。我习惯先解压到 /opt，再建一个不带版本号的软链，这样后面升级的时候不用改一堆脚本引用：

tar -zxf mycat2-xxx-bin.tar.gz -C /opt ln -s /opt/mycat2-xxx /opt/mycat ls -l /opt/mycat

以后想切版本，只需要把软链指到新目录。配置文件可以单独备份，不要和安装目录耦合得太死。我见过有人每次升级就把整个 conf 目录覆盖，结果把生产配置冲掉了，这种操作属于翻车概率最高的动作之一。

解压完成后，进入安装目录看一眼 lib 目录的大小和文件数。正常情况 lib 下应该有几百个 jar，如果只有几十个或者存在 0 字节文件，说明压缩包有问题，直接重新下载，不要继续。这一步做好，能省掉第 4 章里 ClassNotFoundException 的排查时间。校验和解压这两个动作加起来不到五分钟，换来的是后面启动和排错时不用怀疑安装包本身。

3.2 启动脚本的四个子命令：start、stop、restart、console

MyCat2 的启动脚本是 bin 下的 mycat。第一次启动，我强烈建议用 console 而不是 start，原因很简单：console 模式下 JVM 前台运行，报错直接吐在终端，不用去猜日志路径。

cd /opt/mycat ./bin/mycat console

看到类似下面这种输出，说明 JVM 已经起来了：

Loading class `com.mysql.jdbc.Driver' ... MyCat Server startup successfully. port:8066

如果终端一直不动，或出现大量异常堆栈，停下来看异常信息，别等。处理完再启动。console 模式还有个附加价值：它把日志级别直接呈现在终端上，刚好用来验证 JVM 参数和配置文件有没有被正确加载。这一条命令，能把第 4 章一半的坑提前暴露在眼前。

确认没有问题之后，再切回正式启动方式：

./bin/mycat start ./bin/mycat status

status 会告诉你当前进程是否存在。注意，start 之后命令立即返回，进程在后台运行。如果你马上执行 status 看到 not running，不要慌，多半是 JVM 启动需要几秒钟，等两秒再查。这里有个细节容易让人误判：后台启动模式下，进程退出不等于失败，要看日志才能确认是正常退出还是异常退出。

停止和重启同理：

./bin/mycat restart ./bin/mycat stop

restart 这个命令在改动 conf 配置之后用的频率最高。值得提醒的是，MyCat2 对配置文件的加载时机是启动阶段，所以任何配置改动都必须 restart，而不是等着热加载。个别参数支持运行时通过管理端口修改，但那是进阶玩法，基础安装部署阶段统一用 restart。养成「改完必 restart、restart 后必看日志」的习惯，能少踩很多坑。

3.3 启动后日志到底看哪个文件：logs 目录的正确打开方式

后台启动模式下，日志不会出现在你的终端里。MyCat2 的日志默认落在 logs 目录，文件名随版本略有差异，常见的是 mycat.log 和 wrapper.log。排错顺序我一般是这样：

cd /opt/mycat/logs ls -lt | head tail -200f mycat.log

ls -lt 按时间倒序排列，哪个文件刚刚被写过，哪个就是当次启动的日志。看日志的时候重点抓两类关键字：ERROR 和 Exception。如果整个文件只有 INFO 级别的内容，而日志的最后一行停在一个普通的初始化步骤上，那大概率是 JVM 还没退出，只是启动卡住了，这时要用 jstack 之类的工具去看线程状态，而不是反复重启。

启动成功的标志不是「日志文件生成了」，而是出现了 "server startup successfully" 或等效关键字，并且 status 命令返回 running。把这两件事同时确认了，才算跑通。有个实用技巧是启动后立刻执行 netstat 看端口监听：

netstat -anp | grep 8066

看到 LISTEN 状态就说明网络层就绪。日志和端口两个信号都亮，安装包的启动环节才算真正完成。这一步做完，你就从「下载了安装包」进阶到「安装包在我的机器上活着」。

4. MyCat2 安装与启动常见的 5 个坑：现象、原因、解决

4.1 现象：java.lang.UnsupportedClassVersionError，启动即退出

启动时终端直接甩出：

java.lang.UnsupportedClassVersionError: org/mycat/... has been compiled by a more recent version of the Java Runtime

原因只有一个：当前默认的 java 版本比安装包编译目标高太多，常见场景是系统自带 openjdk 17，而 MyCat2 按 JDK 1.8 编译。解决方式不是去装新版本 MyCat2，而是把启动脚本用的 java 指回 JDK 8。

操作顺序：先看 which java 指向哪，再看 JAVA_HOME 设没设。启动脚本一般会优先用 JAVA_HOME/bin/java，但很多系统没设 JAVA_HOME，于是脚本沿 PATH 找 java，找到的就是错的。解决：

export JAVA_HOME=/usr/local/jdk1.8.0_202 export PATH=${JAVA_HOME}/bin:$PATH ./bin/mycat restart

这个坑里最容易迷惑人的是：java -version 明明显示 1.8，但 mycat 启动还是报版本错误。出现这种情况请检查 mycat 脚本里是否有硬编码的 JAVA_HOME 路径，或者脚本里面用了 jre 目录而非 jdk 目录。有些安装包模板会在脚本头部写死 JAVA_HOME=/usr/jdk，安装路径不同时就会踩中。这类问题看脚本前三行比看日志更快定位。

4.2 现象：端口被占用，启动卡在 bind 阶段

启动日志出现：

java.net.BindException: Address already in use

MyCat2 默认要占 8066 端口，如果你的测试机上还有另一个 MyCat 实例、或者别的服务恰好用了 8066，就会撞上。解决方式有两种：改 MyCat 的端口，或者停掉占用端口的进程。

先定位谁占了端口：

netstat -anp | grep 8066

如果确认是残留的 Java 进程，kill 掉再启动。如果是因为测试环境端口冲突频繁，改配置更省心。MyCat2 的端口配置通常在 conf/bootstrap.yml 或者 mycat.yml 里，搜 serverPort 或类似键名。改完之后 restart，再用 netstat 确认监听端口已经变化。

这个坑容易被忽略的是：改完端口之后，客户端连接也要跟着改，连接串会从 8066 变成新端口。忘了改应用侧配置，看起来像是连接失败，实际是端口记混了。我建议把端口号写进你的部署文档，而不是依赖记忆。多实例部署时，端口规划提前做，能避免一半的 bind 冲突。

4.3 现象：ClassNotFoundException，lib 目录少了 jar

启动日志里出现：

java.lang.ClassNotFoundException: com.mysql.cj.jdbc.Driver

原因绝大多数是安装包下载不完整，或者解压时遗漏了部分 jar。不要试图去网上下单个 jar 塞进 lib，版本匹配问题会折磨你。正确做法是回到官方 release 地址重新下载，解压后对比文件数量。

如果多次重新下载都报同样的缺类，那要看是不是你改动了 lib 目录：比如为了「瘦身」删了几个看起来用不上的包。MyCat2 的基础安装包内部依赖关系没有文档给你列全，任何手动删除 jar 都属于负优化。我见过最离谱的一次是同事为了省空间删了 lib 下所有 test 开头的 jar，结果启动时缺了一个压缩工具类。回归基础包，是最稳的恢复手段。

这个坑的隐蔽之处在于：报错信息里提到的类名，和缺失的 jar 文件名往往对不上。你看到 ClassNotFoundException 时，第一反应应该是「重新解压一份原包对比 lib 目录」，而不是去搜这个类属于哪个 jar。把 lib 目录视为黑匣子，不要试图理解里面每个 jar 的用途，这是安装基础包应有的心态。

4.4 现象：进程起来了，但 mysql 客户端连不上

启动成功后，执行：

mysql -h127.0.0.1 -P8066 -uroot -p123456

提示 access denied 或 connect refused。这时候要拆成两层去看：先看网络层能不能到端口，再看认证层是否通过。

connect refused 大部分情况是 MyCat 监听在 127.0.0.1 之外的其他地址上。检查 conf 里绑定的 host 配置，如果绑的是 127.0.0.1 而客户端从别的机器连过来，自然被拒。access denied 则是用户或密码不对，MyCat2 默认 root/123456，但不同版本默认值不同，且如果之前改过 yml 里的 authentication 段，旧密码会失效。

排查顺序建议是 telnet 端口、确认监听地址、确认用户密码、检查防火墙。这四步里遇到最多的是防火墙，测试机上 firewalld 或 iptables 默认就拦了 8066，开了端口问题立刻消失：

firewall-cmd --add-port=8066/tcp --permanent firewall-cmd --reload

这个坑的教训是：不要一上来就怀疑配置文件的认证逻辑，先用 telnet 确认端口通不通。网络层不通时，用户名密码再对也没用。连接问题按层次排查，从底往上走，效率最高。

4.5 现象：YAML 配置解析失败，进程秒退

改动 conf 下的 yml 文件后，启动几秒就退出，日志里出现：

org.yaml.snakeyaml.parser.ParserException: while parsing a block mapping

原因基本是 YAML 缩进和冒号空格写错了。MyCat2 对格式敏感度比较高，key 和 value 之间必须有空格，列表项缩进必须对齐。解决方式是把改动的部分回退，逐行检查缩进。我自己的写法是：所有嵌套层级用两个空格缩进，不允许 Tab；字符串不加引号除非里面有特殊字符；注释不要写在行尾，单独起一行。

如果你用 IDE 改配置，尽量打开 YAML 校验插件，能在启动前就暴露问题。如果已经在生产环境改到一半，记住保留改动前的备份。MyCat2 没有帮你做配置自动备份的机制，改配置之前先 cp 一份 .bak，这是成本最低的后悔药：

cp conf/mycat.yml conf/mycat.yml.bak

以后每次改配置前都执行这一句，养成肌肉记忆。YAML 解析失败这个问题，90% 是手误，剩下 10% 是编辑器把 Tab 和空格混用了。把编辑器的 tab 键设置成插入空格，能直接消灭这一类问题。配置格式的坑最不值得浪费时间，因为原因永远那么几个。

5. 配通数据源和逻辑库：让安装包从能启动到能干活

5.1 最小可用的数据源配置：把 yml 从能启动改成能连库

装好只是第一步，安装包跑起来不等于能连上你的后端 MySQL。这一节把它接到真实库上。

打开 conf 下的 mycat.yml，找到数据源相关的配置段。MyCat2 把物理连接放在数据源这一层，一个数据源对应一个后端 MySQL 实例或者连接串。最小配置长这样：

datasource: mysql3306: url: jdbc:mysql://127.0.0.1:3306/db?useSSL=false&serverTimezone=Asia/Shanghai user: root password: 123456

这段的意思：定义一个名叫 mysql3306 的数据源，指向本机 3306 上的 MySQL。url 里的 useSSL=false 和 serverTimezone 是两类高频坑，前者对应 MySQL 8.0 对 SSL 的默认值变化，后者对应没有指定时区时的连接拒绝。配置改完执行 restart。

这里有个概念值得区分：数据源是物理连接描述，逻辑库才是应用看到的那层。MyCat2 的逻辑库可以理解为一个虚拟 database，应用连接 MyCat 后看到的 database 列表里，包含的是逻辑库而不是物理库。两者之间靠分片规则和数据源路由联系。配置数据源时，你要问自己的第一个问题不是「这个 yml 语法对不对」，而是「这个数据源对应哪台物理 MySQL、账号有没有权限」。

参数层面还有几个可以按需调整的：连接池大小、超时时间、是否自动重连。基础安装时先用默认值，不用一上来就调满。我见过有人一装完就把连接池拉到 500，结果后端 MySQL 的连接数被打爆。物理库的承载能力，决定了连接池参数的上限，这个判断需要基于你的实际库配置，而不是越大越好。

5.2 用命令行确认连接：mysql 客户端连上去到底看到什么

配置改完重启 MyCat，然后用 MySQL 客户端连上去看：

mysql -h127.0.0.1 -P8066 -uroot -p123456

进入命令行后先看逻辑库：

show databases;

如果能列出逻辑库列表，说明 MyCat 侧的用户认证已经通过。如果看不到你预期的库，最常见原因是逻辑库配置里没有把数据源关联进去，或者关联了但名字对不上。这一步只验证链路通不通，不验证分片效果。

想验证一条 SQL 真正落到后端 MySQL，可以在逻辑库执行：

use logic_db; select * from user_info limit 1;

如果 MyCat 返回正常数据，说明穿透连接已经打通。如果报错，回到第 4 章排查数据源配置里的 url、账号、密码是否和实际 MySQL 一致。这里有个细节：首次连接时 MyCat 会向后端 MySQL 发起连接，如果后端 MySQL 的防火墙拦了 3306，MyCat 日志里会报连接超时，但 MyCat 本身并不会退出。

命令行验证通过后，建议顺手测一下写操作：

insert into user_info(id, name) values (1, 'test');

只读查询通过不代表写路径正常，分片中间件的写路由往往比读路由更复杂。测试一条插入，能顺带验证全局序列号、分片键映射这些后续要用的机制，也确认你对基础安装包的掌控力又进了一步。

5.3 从单库到分片：安装包自带的模板怎么改

基础安装包通常带有一套默认分片模板或者全局序列号配置，不要一上来就推到重来。我建议的第一条分片表这样建：

create table t_order ( id bigint primary key, user_id int, amount decimal(10,2) ) broadcast = 'false' dataNode = 'dn1,dn2' shardingKey = 'id';

这种建表语法不是标准 MySQL，它是 MyCat2 对 DDL 的扩展。MySQL 客户端把这条语句发给 MyCat，MyCat 解析后在后端物理库建表，并按 id 做分片路由。dataNode 指定了这条表的数据落在哪几个物理节点上，shardingKey 指定了按哪个字段计算分片。

注意 shardingKey 只支持单键分片，如果你有联合唯一索引想按多列分片，基础安装包默认策略就要额外写分片算法。我先不给自定义算法代码，因为每个公司的表结构都不一样。正确的路径是先跑通单键分片，再根据业务需要替换算法。安装包自带的模板是学习分片规则的最好起点，比任何时候从零写都省力。

分片键的选择要谨慎，它决定了后续所有查询的分布方式。选错了，数据会倾斜到单个节点，分片失去意义。我见过有人把 status 字段当分片键，结果 90% 的数据落在第一个分片，其他分片几乎空闲。选分片键的原则是：区分度高、查询条件里频繁出现、不会频繁更新。理解了这个原则，你才算真正在用分片，而不是在装样子。

6. 验证安装的 3 个检查点，以及把 MyCat2 进程交给 systemd

6.1 三个检查点：端口、日志、SQL 一行都不能少

验证安装不是「启动成功就算完」，我每次装完新环境都会按固定顺序过三个检查点。第一，netstat 看 8066 端口处于 LISTEN 状态，这代表网络层就绪。第二，logs/mycat.log 里出现 startup 关键字，且没有 ERROR 堆栈，这代表进程层就绪。第三，mysql 客户端执行 show databases 能返回逻辑库列表，这代表业务层就绪。三个检查点全部通过，安装包才算真正落地。

6.2 进阶动作：调 JVM 堆内存后再交给 systemd 托管

安装包自带的启动脚本默认堆内存往往偏保守，生产环境建议在 bin/mycat 脚本里调整 Xms/Xmx。改完启动脚本后，最好把 MyCat2 注册为 systemd 服务，让它在机器重启后自动拉起：

[Unit] Description=MyCat2 Database Middleware After=network.target [Service] Type=forking ExecStart=/opt/mycat/bin/mycat start ExecStop=/opt/mycat/bin/mycat stop ExecReload=/opt/mycat/bin/mycat restart User=mycat Restart=on-failure [Install] WantedBy=multi-user.target

把这段存成 /etc/systemd/system/mycat.service，然后 systemctl daemon-reload，再用 systemctl enable mycat 设置开机自启。对后台常驻的中间件来说，这一步能让重启后不再手动逐个拉起，省掉不少运维琐事。

JVM 参数调整方面，我的经验是先用默认值跑起来，观察 GC 日志和内存占用，再逐步调整堆大小。不要一上来就追求大堆，大堆不等于高性能；频繁 Full GC 才是性能杀手。把 JVM 参数调整和 systemd 托管这两件事做完，安装包就从「能跑」变成了「能稳定跑」。

我个人的习惯是：每装一台新机器，都会顺手把启动脚本里的 JVM 参数和 systemd 单元文件备份到配置仓库里，下次换机器直接复用。MyCat2 本身不难装，难的是装完之后的配置资产能不能沉淀下来。这套流程帮你少踩几次我已经踩过的坑，希望帮到你。

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