企业官网建设流程全解析

简介：Mycat2基础安装包面向需要构建分布式数据层的中高级后端开发与数据库运维人员，解决单机数据库在高并发、海量数据场景下的扩展瓶颈。压缩包共收录51个文件，主要涵盖Mycat Server启动脚本、schema.xml等核心配置、SQL初始化脚本、多平台运行库（so/dll/jnilib）以及日志与状态管理模块，整体仅1.2MB，轻量且便于快速分发部署。包内还附带wrapper.jar与跨平台守护进程组件，可帮助读者在Linux、Windows或macOS环境搭建完整的Mycat2服务实例。通过部署该安装包，使用者可逐步掌握数据分片、读写分离、SQL路由等关键机制，并结合server.json、state.json等配置理解Mycat2的动态扩展与高可用设计思路。目前已有1056人学习浏览该资源，适合正在调研数据库中间件选型或准备自建分布式数据层的开发者参考使用。

1. 为什么一个基础安装包值得专门讲：Mycat2 到底解决了什么问题

MySQL 单实例表数据量冲到几千万甚至上亿行以后，索引优化开始失效，读写延迟肉眼可见地变高，分库分表基本是绕不开的坎。但让业务团队把 DAO 层 SQL 全部改一遍，成本高、风险大；更常见的做法是引入 Mycat2 这样的数据库中间件，用一套“假装自己还是 MySQL 服务”的协议端口，把分片、读写分离、分布式序列都挡在应用后面，业务连接串只改一个端口就能接入。本文要做的，是把我经手的 mycat2 基础安装包从下载、解压、配置到第一次连上 8066 数据端口的完整过程讲透。适合正在做分库分表选型，或者被 Mycat1.x 的 XML 配置折腾过的人。

2. 先把包看明白再动手：mycat2 基础安装包的目录结构与前置环境

2.1 发行包形态：tar.gz 和 zip 里到底装了什么

拿到安装包后最忌讳的就是“解压即跑”，我见过不少人把包解压后直接执行 bin 下的脚本，结果报错，然后对着屏幕发愁。实际上，Mycat2 的发布包结构非常传统，继承了老 Mycat 的布局，主要目录就那么几个，每个目录的职责在安装前花十分钟搞清楚，能省下后面很多排查时间。以 Linux 服务器上的 tar.gz 发行包为例，解压后通常长这样：

tar -zxvf mycat2-xxx.tar.gz ls -l mycat/

解压完成后，我一般会按下表逐项核对目录和文件。这也是基础安装包“基础”二字的含义——它不包含业务配置，只给你一套能跑起来的中间件骨架，剩下的数据源、逻辑库、分片规则都要在这个骨架上长出来。

bin 目录是入口，Linux 下最常见的启动命令是./bin/mycat start，Windows 下对应bin\mycat.bat。conf 目录里放着 yml 格式的配置文件，是基础安装包里面最需要动手的地方。lib 目录在安装阶段几乎不用碰，但如果你后续要接入非 MySQL 数据库、发现缺驱动，最终还是要回来往这个目录放 jar 包。logs 目录平时没人看，一旦连不上 8066，它就是你唯一的抓手，后面避坑章节会反复提到它。

这里有个容易忽略的细节：基础安装包自带的是 MySQL 连接驱动，如果你要连 PostgreSQL 或 Oracle，得另外找对应驱动放进 lib 目录。我一般会先查包的 README 或发行说明，确认它内置了哪些驱动，而不是盲目按网络教程操作。另外，下载完压缩包后花十几秒做一次完整性校验是值得的，常见做法是用 sha256sum 和发布页给出的校验值比对，这一步能过滤掉下载中断导致的包损坏。

2.2 JDK 版本是第一道门槛：装之前先确认两件事

Mycat2 是纯 Java 服务，所以“装好了以后跑不起来”的最常见原因，不是安装包坏了，而是 JDK 环境不对。不同时期的 Mycat2 对 JDK 版本要求不一样：早期版本在 JDK 8 上运行是主流，后期的版本因为依赖升级，会要求 JDK 11 甚至 17。这意味着你在下载基础安装包之前，应该先确认服务器上装的是哪个版本，而不是等到启动报错再回来补课。

检查命令非常简单，下面这组命令是我每台新机器上都会跑一遍的：

which java java -version echo $JAVA_HOME $JAVA_HOME/bin/java -version

第一条看系统默认 java 的位置；第二条看默认 JVM 版本；第三条看环境变量是否指向 JDK 根目录；第四条最关键——如果这条命令报错，说明 JAVA_HOME 没生效；如果第三条和java -version输出的版本不一致，说明 PATH 和 JAVA_HOME 指向了不同 JDK。这种“系统命令正常但服务起不来”的情况在中间件场景里最迷惑人。

启动脚本最终用的是$JAVA_HOME/bin/java，而不是 PATH 里的 java。所以如果你发现java -version正常但中间件启动失败，请先检查echo $JAVA_HOME的输出。改完 JAVA_HOME 后，要么重开一个 ssh 会话，要么执行source /etc/profile让它生效，否则变量值不会自动刷新。

提示：如果服务器上装了多个 JDK，可以用update-alternatives --config java（Debian 系）或手动调整环境变量来切换默认版本，但启动脚本读的是 JAVA_HOME，两个位置必须对齐，不能只改其中一个。

2.3 Windows 与 Linux 启动脚本的差异

很多人在 Windows 上用 zip 包做本地验证，在 Linux 上跑生产。两个平台脚本文件不同，坑也有区别。Linux 上最常见的问题是解压后没有给脚本加执行权限，直接./bin/mycat start会报 Permission denied。这不是安装包的问题，是文件权限位没设置，执行下面两条命令即可：

chmod +x bin/* ./bin/mycat start

Windows 上我用的是bin\mycat.bat start，一般不会缺权限。但 Windows 有个特殊问题：JAVA_HOME 路径里如果带空格（比如装在C:\Program Files\Java\jdk8），或者环境变量末尾多了一个分号，mycat.bat 在解析路径时会得到错误结果，轻则提示找不到 java，重则把一串乱码塞进 classpath。这是因为 Windows 批处理对引号和分号的错误容忍度比 Linux 差很多，属于一踩一个准的“血泪经验”。

我自己的习惯是：本地开发装 JDK 时，直接用不带空格的目录，比如D:\jdk8；服务器上则统一用/usr/local/jdk这样的路径，配合 symlink 指向实际安装目录。另外还有一类真实存在的坑：服务器上解压了多个基础安装包，两个实例抢同一个 8066 端口。第二个启动的会报端口被占用，但它可能只打印一条错误就悄悄退出，日志很难第一时间看到。排查时用ss -lntp | grep 8066，看清占用端口的进程路径，账就一目了然了。

3. 解压到连上 8066：mycat2 基础安装包的最小启动步骤

3.1 先改哪两个配置再启动

第一次启动我的经验是：能不改的东西尽量不改。基础安装包自带的默认配置，通常可以让你先把服务拉起来，确认包是好的。需要优先检查的是端口和 JVM 堆内存这两项，其他配置等验证完再慢慢调。

端口方面，Mycat2 对外提供数据端口，默认值沿用 Mycat 时代的 8066，应用连接的是它。如果你的服务器上已经有其他服务占了 8066，启动会报绑定失败。所以在启动之前，我习惯先扫一遍配置里的端口值：

grep -rn "8066" conf/ | head -20

找到端口配置后，如果 8066 被占用，就把所有出现 8066 的地方统一改成比如 8067。注意不要只改一处，数据端口和管理端口可能同时存在，漏改会导致连上去之后行为很怪，比如能连上却拿不到逻辑库列表。JVM 堆内存方面，基础安装包默认堆大小一般是给开发场景用的，生产环境必然要调。但第一次启动，我建议保持默认，先把流程跑通再回头调。如果机器内存很小，比如只有 2GB，那就需要把启动脚本里-Xmx的值调小一点，否则 JVM 可能因为申请不到内存直接退出。

内存参数我一般直接在启动脚本或 conf 下的 JVM 参数文件里找-Xms、-Xmx。开发机场景下把-Xmx设成 512m 足够跑通流程；生产环境按每个物理库连接数去估算，起步给 1g 到 2g，后续用 jstat 监控 GC 情况再继续调。注意 Mycat2 的 JVM 参数可能不集中在同一个文件里，用grep -rn "Xmx" bin/ conf/全局搜一下最保险，别凭记忆去翻某一个文件。

3.2 前台启动看日志：console 模式是第一选择

第一次启动，我不建议用后台方式，因为后台模式下日志被写进文件，出错时你只能去翻日志文件。更高效的做法是用前台模式，让日志直接打到终端，Ctrl+C 可以随时停掉，方便边看边改，这个模式下出错原因会直接在眼前展开。

cd mycat ./bin/mycat console

如果一切正常，你会看到类似 server started 的日志，然后终端卡在前台等待，意思是服务已经在 8066 上监听。这个模式非常适合安装后的第一轮验证。等确认无误，再退出、改用后台方式启动。有一点要注意：console 模式不是所有发行版都提供，如果你的包没有这个参数，那就用./bin/mycat start启动，然后用tail -f logs/wrapper.log实时跟踪日志。

wrapper.log 是中间件运行的核心日志，启动失败的原因、端口绑定的异常、SQL 路由的报错基本都在里面。前台日志里如果出现 NoClassDefFoundError 或 ClassNotFoundException，多半是 lib 目录缺失依赖 jar，或者 JDK 小版本不匹配。这两种情况不要急着重装，先核对发行说明里要求的 JDK 确切版本，再决定是换 JDK 还是换安装包。把日志当成第一信源，而不是反复重启服务去猜。

3.3 后台启动与端口连通性验证

确认前台能正常起来之后，就可以切到后台模式，让服务常驻。后台启动后需要用命令确认状态，而不是凭感觉认为 start 过了就完了。三条命令一起执行，可以避免“脚本说启动成功，实际端口没监听”的假阳性：

./bin/mycat start ./bin/mycat status ss -lntp | grep 8066

第一条是后台启动；第二条查看进程状态，输出里应该能看到运行中的标识；第三条检查端口监听，确认中间件确实占住了 8066。如果ss -lntp看不到监听，很可能服务起了但没绑定成功，按下文避坑章节的思路查。

端口确认后，用 MySQL 客户端连上去，做最基础的连通性测试：

mysql -h127.0.0.1 -P8066 -uroot -p123456

默认账号密码以发行说明为准，Mycat 系列的传统默认值是 root/123456，很多基础安装包沿用这套组合。连上后如果能进入 MySQL 命令行提示符，基础安装包的使命就完成了一大半。如果报错，先去 logs 目录翻 wrapper.log 的最后几十行。连接成功之后，第一件事是执行SELECT VERSION();——如果返回的版本字符串和中间件版本一致，说明你连的是中间件而不是物理 MySQL。这个动作虽然简单，但能立刻排除“中间件没启动、客户端偷偷直连了物理库”这种乌龙场景。

4. 把逻辑库接到物理库：Mycat2 数据源配置与透传验证

4.1 Mycat2 的配置哲学：文件配置退居二线，管理 SQL 做主

这是从 Mycat1 迁移过来的用户最不适应的一点。Mycat1.x 把分片规则、数据源、库表关系都写在 XML 文件里，改完要重启才生效。Mycat2 换了一套思路：配置文件仍然存在，但更核心的配置动作是通过连上中间件执行管理 SQL 来完成的。数据源、逻辑库、分片表这些对象，都可以在运行时动态创建和修改，不需要重启。

对基础安装包的使用者来说，这意味着两件事：第一，你不再需要打开一堆 XML 去手写路由规则；第二，你要适应“用 SQL 管理配置”的新习惯。Mycat2 把持久化机制做成黑匣子，你只管发 SQL，它负责把配置落到元数据里。我不建议去纠结持久化文件的具体格式，因为它在不同小版本里变化过，把时间花在熟悉管理 SQL 上更值。

老用户最容易卡在“配置文件写在哪儿”这个问题上。Mycat2 的答案是：一部分配置仍然在 yml 里，另一部分通过 SQL 运行后持久化为元数据对象。具体哪些走文件、哪些走 SQL，各版本有各自的分工。我后来养成的习惯是：凡是数据源、逻辑库这类运行时对象，都用管理 SQL；凡是端口、JVM、日志级别这类进程级参数，都看 yml。这样在基础安装包阶段不会走偏。

4.2 添加数据源：先用 SHOW 看现状，再决定用哪种写法

连上 8066 后，先看一下当前有哪些数据源：

SHOW DATASOURCES;

如果输出为空或只有系统内置数据源，说明还没有任何真实物理库接入。接下来要做的，是把一个真实 MySQL 实例注册成中间件的数据源。Mycat2 在这块的语法在不同小版本里有差异，我整理两种常见写法，你可以在自己的版本上试：

-- 写法一：注解形式 /*+ mycat:createDatasource{ "name":"ds0", "url":"jdbc:mysql://127.0.0.1:3306/testdb", "user":"root", "password":"123456" } */

-- 写法二：自然 SQL 形式 CREATE DATASOURCE ds0 WITH "jdbc:mysql://127.0.0.1:3306/testdb", "root", "123456";

第一种写法是 Mycat2 特有的注解 SQL，把数据源参数写成 JSON 结构；第二种更接近用户习惯的 SQL 语法。两种都可能在某个版本收到“语法不支持”的报错，遇到这种情况不要慌，用SHOW HELP在当前版本上确认支持的命令列表。管理 SQL 语法跟小版本绑定，这是事实，不是玄学。

无论用哪种写法，几个参数是通用的：name是数据源在逻辑层的名字，url要写 JDBC 连接串，user和password是物理库的账号密码。连接串里的 3306 指向真实 MySQL，可别把 IP 写成 127.0.0.1 却指向了中间件自己，那会形成循环连接，连接池会被慢慢耗尽。如果SHOW DATASOURCES看不到你想找的数据源，也不要急着再建一次，先执行SHOW HELP看当前版本支持的命令清单，网上教程的语法很可能已经过时了。

4.3 透传验证：执行一条真实 SQL 并确认路由分发

数据源注册成功之后，还要建逻辑库和逻辑表，才能让业务 SQL 走到物理库。最小验证方式是：创建一个逻辑库，再执行一条真实 SQL，看结果是不是从物理库查回来的。基础安装包阶段，我不建议立刻上复杂的自定义分片算法，先把全局表建起来做透传验证。

CREATE DATABASE testdb; CREATE TABLE testdb.t_user ( id bigint primary key, name varchar(64) ); USE testdb; SELECT COUNT(*) FROM t_user;

全局表意味着每个分片节点都有一份完整数据，中间件负责写扩散和读聚合。它和普通分片表的区别在于，你不需要指定分片键，逻辑最简单，适合安装阶段验证数据源连通性。如果SELECT COUNT(*)报“表不存在”，说明中间件没有把逻辑表映射到物理表，需要检查数据源配置里的物理库名和逻辑库名是否一致。

想确认 SQL 真的被路由到预期节点，可以用 EXPLAIN 类命令看执行计划：

EXPLAIN SELECT COUNT(*) FROM t_user;

输出会显示这个 SQL 被路由到了哪个数据节点、命中了哪些分片。透传验证通过后，业务连接串就可以从原来的 3306 换成 8066，基础安装包的接入工作基本完成。至于分片键选择、分片算法这些更高阶的内容，那是下一步的事，不应该在安装阶段盲目铺开。

5. 安装启动避坑清单：五个常见翻车现场与修复路径

下面五条是我在帮人排查和自己在测试环境里反复踩过的坑。每一条都按现象、原因、解决三步拆开写。

5.1 启动脚本报错：JAVA_HOME 明明配了，脚本还是找不到

现象：执行./bin/mycat start后，终端直接提示找不到 JAVA_HOME 或找不到 java，但 ssh 里echo $JAVA_HOME能打印出路径。

原因：环境变量虽然在当前会话可见，但启动脚本如果是通过 su、sudo 或 systemd 方式调用的，子进程环境里不一定继承了你手动 export 的变量。另一个常见原因是 JAVA_HOME 末尾带了/bin，脚本再拼一次/bin/java，实际去执行的是一个不存在的路径。

解决：把环境变量写进/etc/profile或~/.bash_profile，并保证指向 JDK 根目录而不是 bin 子目录，然后用source /etc/profile刷新。如果是 systemd 管理服务，在 service 文件里显式声明Environment=JAVA_HOME=...，不要依赖全局 profile。

5.2 status 显示运行中，但 8066 端口就是连不上

现象：./bin/mycat status输出显示进程在跑，ss -lntp | grep 8066却看不到监听端口，MySQL 客户端连接直接超时。

原因：最多见的情况是端口绑定失败但进程没有退出。JVM 已经起来，但 Socket 绑定报错后进入异常状态，脚本的状态检查只看进程是否存活，不看端口是否监听。其次是防火墙或云安全组拦截了 8066 入站，本地连接没事，远程连接一直卡住。

解决：先看logs/wrapper.log，搜索 bind 或 IOException 关键字；再用ss -lntp确认监听。如果绑定失败，改端口后重启；如果是防火墙问题，在安全组放行 8066。用tail -f logs/wrapper.log实时跟踪，比反复重启脚本高效得多。

5.3 把 Mycat1 的 schema.xml 直接搬到 Mycat2

现象：老项目从 Mycat1 升级，把原来的 schema.xml、rule.xml、server.xml 复制到 Mycat2 的 conf 目录，重启后配置完全不生效，或者启动直接报错。

原因：Mycat2 的配置模型不是 Mycat1 的延续，是重构过的。Mycat2 以数据源、逻辑库、分片表等运行时对象为核心，配置文件以 yml 形式存在，XML 式的 schema 和 rule 在 Mycat2 里没有对应位置。直接复制文件等于把旧钥匙插进新锁芯，当然打不开。

解决：不要迁移配置文件，要迁移配置语义。把 Mycat1 里的 schema 表结构、分片规则翻译成 Mycat2 的数据源加逻辑库加建表语句，通过管理 SQL 重建。这个翻译过程确实琐碎，但它能逼你把旧配置里含糊不清的规则重新捋一遍，改完反而更清楚自己的分片逻辑到底是怎么设计的。

5.4 连接中间件用的是 8066，却看到一堆物理库的库名

现象：mysql -h127.0.0.1 -P8066 ...连上去之后，SHOW DATABASES能看到物理 MySQL 里所有的数据库，误以为中间件只是透传。

原因：连接串虽然写的是 8066，但如果你用的账号和配置恰好绕过了中间件的库级权限控制，中间件会把你直接带到原型数据源或默认绑定库上，展示物理库全貌。这不一定代表配置错误，但确实容易被误读为“中间件没有生效”。

解决：用SHOW DATASOURCES确认当前连接落在哪个数据源上，再USE到具体逻辑库去验证。如果确实希望限制可见库列表，需要在逻辑库和数据源映射上做权限收敛，而不是只在 MySQL 侧改账号权限，两边要同时收紧。

5.5 JVM 堆内存不足导致启动后频繁 OOM

现象：服务能启动，业务量稍大就卡顿，日志里大量出现 OutOfMemoryError，GC 线程占用 CPU 高居不下。

原因：基础安装包默认堆内存设置是按“能跑起来”标准给的，不是按业务压力给的。生产环境连接数一多，分片路由和 SQL 解析都会吃掉堆空间，默认值不够用。

解决：调启动脚本里的-Xms和-Xmx，建议把两者设成相同的值，避免 JVM 动态扩容带来的停顿；同时给 Metaspace 留足配额。改完重启，用jstat -gc <pid>观察 GC 频率，确认调参后堆使用曲线是否平稳。注意不要一次把堆开得太离谱，超过物理内存反而会频繁 swap，性能更差。

6. 安装之后先做这组自检：我常用的四个验证点

6.1 进程、日志、数据源、路由，四步确认包可用

安装完成后，很多人习惯直接拿业务 SQL 来试，连不上就怀疑安装包有问题。我更倾向于先做一组自检，把“包是好的、数据源是通的、路由是对的”三个结论逐个坐实，再让业务代码进场。

第一步，确认进程与监听端口。./bin/mycat status和ss -lntp | grep 8066两条命令返回正常，并且logs/wrapper.log末尾没有 ERROR 级别日志。第二步，用 MySQL 客户端连 8066，执行下面两条管理 SQL：

SHOW DATASOURCES; EXPLAIN SELECT COUNT(*) FROM t_user;

第一条确认数据源是 ONLINE 状态；第二条确认业务表确实被路由到了预期节点，而不是在一个空逻辑库上打转。第三步，执行一条真实的查询 SQL，核对返回的行数与直接连物理库时一致。第四步，在中间件日志里搜索这条 SQL 的路由关键字，确认它走了中间件解析链路，而不是客户端直连。

我现在每换一个环境装 Mycat2，都会先跑这套自检，再决定要不要把业务流量切过来。尤其是不熟悉的服务器，前两步能过滤掉八成环境类问题；后两步才是中间件本身工作是否正常的证明。希望这一套自检习惯也能帮到你。

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