简介mycat2基础安装包是面向分布式数据库中间件Mycat2的部署资源适用于需要引入数据分片、读写分离与SQL路由能力的开发运维人员。安装包体积仅1.2MB共51个文件主要包含conf配置、jar依赖、sql初始化脚本、xml/json配置以及跨平台启动脚本含wrapper组件可帮助用户在本地或远程服务器快速搭建Mycat2服务实例。已有1054人学习下载。通过解压、修改配置并启动服务可以直观理解Mycat2的分片规则、表结构定义、连接池参数等核心配置结合内置SQL脚本与日志文件还能练习主从读写分离、多节点数据分布以及动态扩容的常见策略。资源包目录结构清晰适合作为入门级参考包方便对照官方文档熟悉默认配置与运行机制为进一步定制分库分表方案、排查路由问题打下基础。1. Mycat2基础安装包一次拆包就能判断生产能不能用的数据库中间件分库分表做到一半单库连接数打满、慢查询拖垮主库的时候很多团队会把目光转向 Mycat2基础安装包。它是一个可直接解压运行的数据库中间件部署包核心作用是替业务挡住后端多实例的复杂性前端连接 MySQL 协议后端按规则路由到不同物理库。适合的人群很明确被单库容量和连接数逼到墙角的后端开发以及想用一套统一入口管理多个 MySQL 实例的 DBA。这篇文章只做一件事——把这套基础安装包从拆包、部署、配置到踩坑完整拆开哪怕你手里只有一个空包也能照着把它跑起来并验证分片路由。2. 先把包拆开看结构目录布局、JDK 匹配与离线部署准备2.1 基础安装包的解压与目录认知拿到基础安装包后不要急着启动先把它看成三个黑匣子bin 里是启动脚本conf 里是核心配置lib 里是整个 Java 运行依赖。解压命令很简单tar -zxvf mycat2-基础安装包.tar.gz -C /usr/local/ cd /usr/local/mycat ls -lh解压后第一件事是确认顶层目录结构。常见布局是 bin、conf、lib、logs 四个目录有的版本还会带 version.txt 或 readme。bin 目录里是启动脚本conf 目录里存放 yml 系列配置文件lib 目录存放全套依赖 jar 包logs 目录存放运行日志。这四块少了谁都会在启动阶段暴露问题缺少 lib 会导致缺类缺少 conf 会导致创建默认配置失败。我一般会先执行一次目录完整性检查把 conf 下的文件全部列出来确认 mycat.yml、cluster.yml 这类核心配置文件存在。基础安装包通常默认带一套可运行的本地配置直接启动会连本机 3306 端口所以后续所有改动都围绕“把默认连接改到你的物理 MySQL”展开。2.2 环境核对JAVA_HOME、端口与最低内存Mycat2 是 Java 服务JDK 版本直接影响启动成败。基础安装包对 JDK8 支持最稳建议使用 1.8.0_211 以上版本低版本 JDK 在并发线程、SSL 握手上有已知问题排查起来非常耗时。先核对环境java -version echo $JAVA_HOME如果 java 能找到而 JAVA_HOME 为空启动脚本里依赖 JAVA_HOME 拼接 classpath 的逻辑就会出问题。常见做法是把 JDK 路径直接写进 /etc/profile然后 source 一下。确认 JAVA_HOME 后再检查端口Mycat2 默认对外服务端口是 8066管理端口是 1982这两个端口必须事先确认空闲。内存方面基础安装包默认 JVM 参数一般够开发环境使用但生产环境建议给 4G 以上堆内存。小规格服务器上用默认参数也能跑只是连接数上来后频繁 GC日志里会出现明显的停顿。可以在启动脚本里调整 -Xmx 参数比如改成 2048m 或 4096m调完重启才生效。2.3 离线环境的快速部署步骤基础安装包最常见的落地场景是内网离线部署没有外网拉依赖的条件这时候整个包里的 lib 目录就是最大价值。部署顺序我一般按四步走先装 JDK 并配置 JAVA_HOME再拷贝安装包到目标目录然后修改 conf 里连接物理库的地址最后执行启动脚本。export JAVA_HOME/usr/local/jdk1.8.0_211 export PATH$JAVA_HOME/bin:$PATH cp mycat2-基础安装包.tar.gz /usr/local/ cd /usr/local tar -zxvf mycat2-基础安装包.tar.gz拷贝完成后先看 conf 下核心配置里的数据源地址把 localhost 改成物理 MySQL 的 IP用户名、密码也同步改掉。这一步最容易漏的是时区参数物理库如果跑在云上连接串里没有 serverTimezone后面查时间字段会发现差了 8 小时这种问题最难定位因为 Mycat 本身日志是正常的。3. 启动与自检三种启动方式、端口验证和日志定位3.1 前台启动与后台守护的选择Mycat2 基础安装包的 bin 目录下通常提供两种启动方式前台启动用于首次调试后台运行用于正式部署。首次部署我强烈建议先用前台方式跑因为所有异常会直接打在终端上不用去日志里翻。启动命令如下cd /usr/local/mycat/bin sh startup.sh如果脚本执行后终端持续输出日志说明进程已经在前台运行。确认无异常后 CtrlC 停掉再用后台方式正式拉起。后台方式的好处是脱离终端SSH 断开也不影响进程但排错时要把输出重定向到日志文件命令大概是cd /usr/local/mycat/bin sh mycat start tail -f /usr/local/mycat/logs/mycat.log注意不同小版本的可执行脚本名称可能有差异以安装包内 bin 目录实际文件为准。启动不成功时最先看的应该是 logs 目录里最新的 mycat.log 和 wrapper.log前者记录业务路由日志后者记录 JVM 启动过程堆内存不足、端口占用这类问题都会在这两个文件里留下明确痕迹。3.2 端口与进程验证8066、1982 到底听没听进程起来不等于服务可用Mycat2 的 Java 进程可能活着但端口没监听原因通常是配置加载失败后线程池没起来。验证端口是最直接的手段ps -ef | grep mycat netstat -tlnp | grep -E 8066|1982正常输出应该能看到两个端口都在 LISTEN 状态。8066 是业务连接入口1982 是管理端口。如果只有 8066 没有 1982说明管理模块初始化失败如果两个都没有说明服务启动未能完成。这时候别反复重启先去看日志里有没有 bind 异常或者配置解析异常。端口验证通过后用 MySQL 客户端连一次 8066这是最接近真实业务行为的自检mysql -h127.0.0.1 -P8066 -uroot -p123456能进入 MySQL 命令行不代表数据源连接正常。输入show databases;看能否返回物理库列表如果可以说明 Mycat 到物理 MySQL 的连接是通的。这一步卡住的话问题基本集中在 conf 里的数据源连接串上。3.3 从日志确认集群与数据源状态连接 8066 后执行查询同时另开一个终端 tail 日志能直观看到 Mycat2 是否成功路由到物理库。日志中会出现 SQL 原文和目标库信息如果只看到接收 SQL 没有路由结果说明后端数据源连接没建立。此时检查物理 MySQL 的用户权限Mycat 用来连物理库的账号必须有目标库的增删改查权限。基础安装包默认日志级别通常覆盖 info足够日常排查。需要更细的调试信息时可以在 conf 中调整日志级别到 debug改完重启后再复现一次问题日志会输出完整的连接建立过程。生产环境务必改回 infodebug 级别下日志量非常大磁盘增长很快。4. 配置文件落地改动mycat.yml、cluster.yml 与账号体系4.1 mycat.yml服务端口、线程池与数据源连接mycat.yml 是 Mycat2 最核心的配置文件服务端口、线程池大小、数据源连接信息都在这里。不同小版本文件名可能不同但职责一样定义这个中间件实例如何对外服务、如何连接后端数据库。先看关键参数server: port: 8066 managerPort: 1982 threadPool: corePoolSize: 8 maxPoolSize: 64 datasource: prototypeDs: url: jdbc:mysql://127.0.0.1:3306/mysql?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456corePoolSize 是常驻线程数maxPoolSize 是峰值线程数。开发环境保持 8/64 没问题生产环境要根据并发量上调但别盲目调到几百线程数超过 CPU 核数太多反而增加上下文切换开销。连接串里的 serverTimezone 必须显式指定时区否则 MySQL 驱动会拿本地时区去解析时间字段容易出现 8 小时偏移。改完配置文件后不要直接重启了事先执行一次配置校验——Mycat2 部分版本支持通过启动脚本做配置预检如果不支持就用java -jar手动加载 yml 看是否抛解析异常。能跑过解析再重启可以省掉不少往返时间。4.2 cluster.yml 与多实例配置基础安装包默认是单机模式但 conf 里通常也携带 cluster.yml 模板为后续扩展多实例做准备。cluster.yml 解决的核心问题是多台 Mycat2 之间的元数据一致性。在单机场景下这个文件保持默认即可不用过度改动。如果确实要组建集群需要把 cluster.yml 里的实例标识改成唯一值并配置集群成员地址。改动重点是有两个一是每个 Mycat 实例的 server 节点配置要指向各自本机的 IP二是所有实例的账号体系必须一致否则同一个客户端连接不同的实例会出现行为不一致。需要说明的是基础安装包一般不带完整的集群协调组件yml 模板只是预留了扩展位置。刚接手时先按单机跑通后续有需要再加集群不然容易踩进元数据同步失败的坑里。4.3 账号、权限与字符集陷阱Mycat2 有两个层级的账号概念客户端连接 8066 时使用的业务账号以及 Mycat 连接物理 MySQL 时使用的数据源账号。基础安装包默认业务账号通常是 root/123456物理数据源账号根据 mycat.yml 里的配置决定。这两个账号经常被混淆排查认证问题时必须分清楚是卡在哪个环节。我一般的做法是新建独立业务账号避免所有连接都挤在 root 上user: root: password: 123456 app_user: password: App2024改完后用业务账号重新连接验证。字符集方面物理库连接串加上 characterEncodingutf8 只是第一步物理库本身的库表字符集也得是 utf8mb4否则一旦业务写入 emoji 或生僻字MySQL 层就报 Incorrect string valueMycat 日志里只能看到路由成功看不到字符集错误排查链路非常容易走偏。5. 避坑排查注意Mycat2 最常见的五个翻车现场5.1 连接 8066 报 Access denied默认密码与认证插件不一致现象使用默认账号 root/123456 连接时报Access denied for user root但直接连物理 MySQL 却能通过。原因基础安装包默认业务账号密码与物理库账号密码不是一回事业务层认证完全由 Mycat 自己的账号体系接管。另一个常见原因是物理 MySQL 使用 MySQL8 的 caching_sha2_password 认证插件Mycat 内置的 JDBC 驱动不认识导致数据源连接失败。解决先确认连的是 8066 还是 3306如果确认在 8066 报错去 mycat.yml 里查业务账号和密码并修改。如果问题是无法连物理库在物理 MySQL 上执行ALTER USER mycat_user% IDENTIFIED WITH mysql_native_password BY 密码;然后重启 Mycat。5.2 能 show databases 但查询报 1064分片键未进入 SQL现象show databases 正常执行SELECT * FROM order_info WHERE status1报 1064 语法错误但物理库单独执行没问题。原因Mycat2 对分片表的查询强制要求 where 条件里带上分片键。status1 没有命中分片键中间件无法确定该去哪个物理分片执行直接拒绝。解决把分片键加进查询条件例如WHERE order_id 123 AND status 1。如果业务场景确实需要按 status 全局查询就得配置全局表或广播表让每个分片都存一份完整数据这是设计阶段的取舍靠 SQL 补是补不回来的。5.3 8066 端口没监听conf 加载失败与 JVM 内存不足现象ps 能看到 java 进程但 netstat 查不到 8066日志里也没有明确报错。原因常见原因是 yml 文件里某个字段缩进错误或引号配对错误配置解析静默失败。另一个场景是机器内存太小默认堆参数把内存吃满JVM 卡在启动阶段。解决先用java -jar方式单独加载 yml 做语法校验。内存不足时在启动脚本里调低 -Xmx比如 512m 起步跑通后再逐步上调。同时确认 swap 是否开启内存不足时 swap 能兜底否则进程很容易被操作系统杀掉。5.4 时间字段差 8 小时连接串缺时区参数现象业务查询返回的时间比实际时间早 8 小时Mycat 日志和物理库日志都查不出异常。原因Mycat 连接串里的 serverTimezone 与实际物理库时区不一致驱动在转换 Timestamp 时按默认时区处理。这个问题在云数据库场景特别常见物理库在云上应用在本地时区天然不一致。解决在 mycat.yml 的数据源连接串里追加上serverTimezoneAsia/Shanghai同时确认物理库SELECT NOW()返回的时间是否正确。改完重启后用一个带时间戳的 INSERT 和 SELECT 做前后对比验证。5.5 改完 conf 不生效conf 不是热加载现象修改 mycat.yml 里的端口或数据源后业务连接还是走旧配置日志里看不到变化。原因Mycat2 的 yml 配置在启动时一次性加载运行期间改动不会自动生效。有人用 kill -9 强杀进程后重启反而导致数据目录和日志状态异常。解决改完配置后通过脚本正常停止再启动。停止命令优先用 bin 目录下的 stop 脚本而不是 kill -9。如果习惯手工管理先ps -ef | grep mycat找到 PID用kill PID发送终止信号确认进程退出后再启动。6. 一个能直接复现的端到端验证分库分表后的路由验证与回退技巧6.1 用 MySQL 客户端走通建库、建表、插数基础安装包跑起来后先用标准客户端把链路打通。连接 8066执行以下操作CREATE DATABASE IF NOT EXISTS demo_db; USE demo_db; CREATE TABLE IF NOT EXISTS t_user ( id BIGINT PRIMARY KEY, name VARCHAR(64), created_at DATETIME ); INSERT INTO t_user (id, name, created_at) VALUES (1, engineer, NOW()); SELECT * FROM t_user WHERE id 1;这条链路验证的是默认数据源能否正常承接建库建表请求。大多数小版本会把未匹配的库表请求路由到 prototypeDs所以只要物理库权限正确这组 SQL 会真实落库。完成后直接去物理 MySQL 查一下 demo_db.t_user确认数据确实落地而不是只停留在 Mycat 内存里。6.2 从 EXPLAIN 和日志验证路由结果分库分表配置完成后验证路由是否正确的成本最低的方式是用 EXPLAINEXPLAIN SELECT * FROM t_user WHERE id 1;观察返回结果里的 target 信息它会显示该 SQL 被路由到哪个物理目标。如果 target 是单值说明路由收敛正常如果出现多个目标就要确认是不是配置了广播表导致。配合日志看一遍完整链路物理库插入一条数据在 Mycat 端查询两侧时间戳一致说明路由和返回链路都没问题。6.3 后悔药配置回退与重启检查清单改动配置前先备份整个 conf 目录这是我踩过坑后养成的习惯。回退流程非常简单停掉服务把备份的 conf 目录覆盖回去重启再走一遍端口和数据源验证。不要只备份单个文件因为 Mycat2 的配置之间存在互相引用只回退一个文件可能导致版本不一致。从那以后我每次动 conf 前都强制走一遍备份、记录变更点、重启验证三步宁可多花一分钟备份也不愿在深夜为一条错误的配置反复翻日志。基础安装包本身不复杂复杂的是配置变更后留下的不确定性。希望这篇拆包笔记能帮你在第一次部署时就避开我走过的弯路。本文还有配套的精品资源点击获取
Mycat2基础安装包部署与配置实战：分库分表路由避坑指南
简介mycat2基础安装包是面向分布式数据库中间件Mycat2的部署资源适用于需要引入数据分片、读写分离与SQL路由能力的开发运维人员。安装包体积仅1.2MB共51个文件主要包含conf配置、jar依赖、sql初始化脚本、xml/json配置以及跨平台启动脚本含wrapper组件可帮助用户在本地或远程服务器快速搭建Mycat2服务实例。已有1054人学习下载。通过解压、修改配置并启动服务可以直观理解Mycat2的分片规则、表结构定义、连接池参数等核心配置结合内置SQL脚本与日志文件还能练习主从读写分离、多节点数据分布以及动态扩容的常见策略。资源包目录结构清晰适合作为入门级参考包方便对照官方文档熟悉默认配置与运行机制为进一步定制分库分表方案、排查路由问题打下基础。1. Mycat2基础安装包一次拆包就能判断生产能不能用的数据库中间件分库分表做到一半单库连接数打满、慢查询拖垮主库的时候很多团队会把目光转向 Mycat2基础安装包。它是一个可直接解压运行的数据库中间件部署包核心作用是替业务挡住后端多实例的复杂性前端连接 MySQL 协议后端按规则路由到不同物理库。适合的人群很明确被单库容量和连接数逼到墙角的后端开发以及想用一套统一入口管理多个 MySQL 实例的 DBA。这篇文章只做一件事——把这套基础安装包从拆包、部署、配置到踩坑完整拆开哪怕你手里只有一个空包也能照着把它跑起来并验证分片路由。2. 先把包拆开看结构目录布局、JDK 匹配与离线部署准备2.1 基础安装包的解压与目录认知拿到基础安装包后不要急着启动先把它看成三个黑匣子bin 里是启动脚本conf 里是核心配置lib 里是整个 Java 运行依赖。解压命令很简单tar -zxvf mycat2-基础安装包.tar.gz -C /usr/local/ cd /usr/local/mycat ls -lh解压后第一件事是确认顶层目录结构。常见布局是 bin、conf、lib、logs 四个目录有的版本还会带 version.txt 或 readme。bin 目录里是启动脚本conf 目录里存放 yml 系列配置文件lib 目录存放全套依赖 jar 包logs 目录存放运行日志。这四块少了谁都会在启动阶段暴露问题缺少 lib 会导致缺类缺少 conf 会导致创建默认配置失败。我一般会先执行一次目录完整性检查把 conf 下的文件全部列出来确认 mycat.yml、cluster.yml 这类核心配置文件存在。基础安装包通常默认带一套可运行的本地配置直接启动会连本机 3306 端口所以后续所有改动都围绕“把默认连接改到你的物理 MySQL”展开。2.2 环境核对JAVA_HOME、端口与最低内存Mycat2 是 Java 服务JDK 版本直接影响启动成败。基础安装包对 JDK8 支持最稳建议使用 1.8.0_211 以上版本低版本 JDK 在并发线程、SSL 握手上有已知问题排查起来非常耗时。先核对环境java -version echo $JAVA_HOME如果 java 能找到而 JAVA_HOME 为空启动脚本里依赖 JAVA_HOME 拼接 classpath 的逻辑就会出问题。常见做法是把 JDK 路径直接写进 /etc/profile然后 source 一下。确认 JAVA_HOME 后再检查端口Mycat2 默认对外服务端口是 8066管理端口是 1982这两个端口必须事先确认空闲。内存方面基础安装包默认 JVM 参数一般够开发环境使用但生产环境建议给 4G 以上堆内存。小规格服务器上用默认参数也能跑只是连接数上来后频繁 GC日志里会出现明显的停顿。可以在启动脚本里调整 -Xmx 参数比如改成 2048m 或 4096m调完重启才生效。2.3 离线环境的快速部署步骤基础安装包最常见的落地场景是内网离线部署没有外网拉依赖的条件这时候整个包里的 lib 目录就是最大价值。部署顺序我一般按四步走先装 JDK 并配置 JAVA_HOME再拷贝安装包到目标目录然后修改 conf 里连接物理库的地址最后执行启动脚本。export JAVA_HOME/usr/local/jdk1.8.0_211 export PATH$JAVA_HOME/bin:$PATH cp mycat2-基础安装包.tar.gz /usr/local/ cd /usr/local tar -zxvf mycat2-基础安装包.tar.gz拷贝完成后先看 conf 下核心配置里的数据源地址把 localhost 改成物理 MySQL 的 IP用户名、密码也同步改掉。这一步最容易漏的是时区参数物理库如果跑在云上连接串里没有 serverTimezone后面查时间字段会发现差了 8 小时这种问题最难定位因为 Mycat 本身日志是正常的。3. 启动与自检三种启动方式、端口验证和日志定位3.1 前台启动与后台守护的选择Mycat2 基础安装包的 bin 目录下通常提供两种启动方式前台启动用于首次调试后台运行用于正式部署。首次部署我强烈建议先用前台方式跑因为所有异常会直接打在终端上不用去日志里翻。启动命令如下cd /usr/local/mycat/bin sh startup.sh如果脚本执行后终端持续输出日志说明进程已经在前台运行。确认无异常后 CtrlC 停掉再用后台方式正式拉起。后台方式的好处是脱离终端SSH 断开也不影响进程但排错时要把输出重定向到日志文件命令大概是cd /usr/local/mycat/bin sh mycat start tail -f /usr/local/mycat/logs/mycat.log注意不同小版本的可执行脚本名称可能有差异以安装包内 bin 目录实际文件为准。启动不成功时最先看的应该是 logs 目录里最新的 mycat.log 和 wrapper.log前者记录业务路由日志后者记录 JVM 启动过程堆内存不足、端口占用这类问题都会在这两个文件里留下明确痕迹。3.2 端口与进程验证8066、1982 到底听没听进程起来不等于服务可用Mycat2 的 Java 进程可能活着但端口没监听原因通常是配置加载失败后线程池没起来。验证端口是最直接的手段ps -ef | grep mycat netstat -tlnp | grep -E 8066|1982正常输出应该能看到两个端口都在 LISTEN 状态。8066 是业务连接入口1982 是管理端口。如果只有 8066 没有 1982说明管理模块初始化失败如果两个都没有说明服务启动未能完成。这时候别反复重启先去看日志里有没有 bind 异常或者配置解析异常。端口验证通过后用 MySQL 客户端连一次 8066这是最接近真实业务行为的自检mysql -h127.0.0.1 -P8066 -uroot -p123456能进入 MySQL 命令行不代表数据源连接正常。输入show databases;看能否返回物理库列表如果可以说明 Mycat 到物理 MySQL 的连接是通的。这一步卡住的话问题基本集中在 conf 里的数据源连接串上。3.3 从日志确认集群与数据源状态连接 8066 后执行查询同时另开一个终端 tail 日志能直观看到 Mycat2 是否成功路由到物理库。日志中会出现 SQL 原文和目标库信息如果只看到接收 SQL 没有路由结果说明后端数据源连接没建立。此时检查物理 MySQL 的用户权限Mycat 用来连物理库的账号必须有目标库的增删改查权限。基础安装包默认日志级别通常覆盖 info足够日常排查。需要更细的调试信息时可以在 conf 中调整日志级别到 debug改完重启后再复现一次问题日志会输出完整的连接建立过程。生产环境务必改回 infodebug 级别下日志量非常大磁盘增长很快。4. 配置文件落地改动mycat.yml、cluster.yml 与账号体系4.1 mycat.yml服务端口、线程池与数据源连接mycat.yml 是 Mycat2 最核心的配置文件服务端口、线程池大小、数据源连接信息都在这里。不同小版本文件名可能不同但职责一样定义这个中间件实例如何对外服务、如何连接后端数据库。先看关键参数server: port: 8066 managerPort: 1982 threadPool: corePoolSize: 8 maxPoolSize: 64 datasource: prototypeDs: url: jdbc:mysql://127.0.0.1:3306/mysql?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456corePoolSize 是常驻线程数maxPoolSize 是峰值线程数。开发环境保持 8/64 没问题生产环境要根据并发量上调但别盲目调到几百线程数超过 CPU 核数太多反而增加上下文切换开销。连接串里的 serverTimezone 必须显式指定时区否则 MySQL 驱动会拿本地时区去解析时间字段容易出现 8 小时偏移。改完配置文件后不要直接重启了事先执行一次配置校验——Mycat2 部分版本支持通过启动脚本做配置预检如果不支持就用java -jar手动加载 yml 看是否抛解析异常。能跑过解析再重启可以省掉不少往返时间。4.2 cluster.yml 与多实例配置基础安装包默认是单机模式但 conf 里通常也携带 cluster.yml 模板为后续扩展多实例做准备。cluster.yml 解决的核心问题是多台 Mycat2 之间的元数据一致性。在单机场景下这个文件保持默认即可不用过度改动。如果确实要组建集群需要把 cluster.yml 里的实例标识改成唯一值并配置集群成员地址。改动重点是有两个一是每个 Mycat 实例的 server 节点配置要指向各自本机的 IP二是所有实例的账号体系必须一致否则同一个客户端连接不同的实例会出现行为不一致。需要说明的是基础安装包一般不带完整的集群协调组件yml 模板只是预留了扩展位置。刚接手时先按单机跑通后续有需要再加集群不然容易踩进元数据同步失败的坑里。4.3 账号、权限与字符集陷阱Mycat2 有两个层级的账号概念客户端连接 8066 时使用的业务账号以及 Mycat 连接物理 MySQL 时使用的数据源账号。基础安装包默认业务账号通常是 root/123456物理数据源账号根据 mycat.yml 里的配置决定。这两个账号经常被混淆排查认证问题时必须分清楚是卡在哪个环节。我一般的做法是新建独立业务账号避免所有连接都挤在 root 上user: root: password: 123456 app_user: password: App2024改完后用业务账号重新连接验证。字符集方面物理库连接串加上 characterEncodingutf8 只是第一步物理库本身的库表字符集也得是 utf8mb4否则一旦业务写入 emoji 或生僻字MySQL 层就报 Incorrect string valueMycat 日志里只能看到路由成功看不到字符集错误排查链路非常容易走偏。5. 避坑排查注意Mycat2 最常见的五个翻车现场5.1 连接 8066 报 Access denied默认密码与认证插件不一致现象使用默认账号 root/123456 连接时报Access denied for user root但直接连物理 MySQL 却能通过。原因基础安装包默认业务账号密码与物理库账号密码不是一回事业务层认证完全由 Mycat 自己的账号体系接管。另一个常见原因是物理 MySQL 使用 MySQL8 的 caching_sha2_password 认证插件Mycat 内置的 JDBC 驱动不认识导致数据源连接失败。解决先确认连的是 8066 还是 3306如果确认在 8066 报错去 mycat.yml 里查业务账号和密码并修改。如果问题是无法连物理库在物理 MySQL 上执行ALTER USER mycat_user% IDENTIFIED WITH mysql_native_password BY 密码;然后重启 Mycat。5.2 能 show databases 但查询报 1064分片键未进入 SQL现象show databases 正常执行SELECT * FROM order_info WHERE status1报 1064 语法错误但物理库单独执行没问题。原因Mycat2 对分片表的查询强制要求 where 条件里带上分片键。status1 没有命中分片键中间件无法确定该去哪个物理分片执行直接拒绝。解决把分片键加进查询条件例如WHERE order_id 123 AND status 1。如果业务场景确实需要按 status 全局查询就得配置全局表或广播表让每个分片都存一份完整数据这是设计阶段的取舍靠 SQL 补是补不回来的。5.3 8066 端口没监听conf 加载失败与 JVM 内存不足现象ps 能看到 java 进程但 netstat 查不到 8066日志里也没有明确报错。原因常见原因是 yml 文件里某个字段缩进错误或引号配对错误配置解析静默失败。另一个场景是机器内存太小默认堆参数把内存吃满JVM 卡在启动阶段。解决先用java -jar方式单独加载 yml 做语法校验。内存不足时在启动脚本里调低 -Xmx比如 512m 起步跑通后再逐步上调。同时确认 swap 是否开启内存不足时 swap 能兜底否则进程很容易被操作系统杀掉。5.4 时间字段差 8 小时连接串缺时区参数现象业务查询返回的时间比实际时间早 8 小时Mycat 日志和物理库日志都查不出异常。原因Mycat 连接串里的 serverTimezone 与实际物理库时区不一致驱动在转换 Timestamp 时按默认时区处理。这个问题在云数据库场景特别常见物理库在云上应用在本地时区天然不一致。解决在 mycat.yml 的数据源连接串里追加上serverTimezoneAsia/Shanghai同时确认物理库SELECT NOW()返回的时间是否正确。改完重启后用一个带时间戳的 INSERT 和 SELECT 做前后对比验证。5.5 改完 conf 不生效conf 不是热加载现象修改 mycat.yml 里的端口或数据源后业务连接还是走旧配置日志里看不到变化。原因Mycat2 的 yml 配置在启动时一次性加载运行期间改动不会自动生效。有人用 kill -9 强杀进程后重启反而导致数据目录和日志状态异常。解决改完配置后通过脚本正常停止再启动。停止命令优先用 bin 目录下的 stop 脚本而不是 kill -9。如果习惯手工管理先ps -ef | grep mycat找到 PID用kill PID发送终止信号确认进程退出后再启动。6. 一个能直接复现的端到端验证分库分表后的路由验证与回退技巧6.1 用 MySQL 客户端走通建库、建表、插数基础安装包跑起来后先用标准客户端把链路打通。连接 8066执行以下操作CREATE DATABASE IF NOT EXISTS demo_db; USE demo_db; CREATE TABLE IF NOT EXISTS t_user ( id BIGINT PRIMARY KEY, name VARCHAR(64), created_at DATETIME ); INSERT INTO t_user (id, name, created_at) VALUES (1, engineer, NOW()); SELECT * FROM t_user WHERE id 1;这条链路验证的是默认数据源能否正常承接建库建表请求。大多数小版本会把未匹配的库表请求路由到 prototypeDs所以只要物理库权限正确这组 SQL 会真实落库。完成后直接去物理 MySQL 查一下 demo_db.t_user确认数据确实落地而不是只停留在 Mycat 内存里。6.2 从 EXPLAIN 和日志验证路由结果分库分表配置完成后验证路由是否正确的成本最低的方式是用 EXPLAINEXPLAIN SELECT * FROM t_user WHERE id 1;观察返回结果里的 target 信息它会显示该 SQL 被路由到哪个物理目标。如果 target 是单值说明路由收敛正常如果出现多个目标就要确认是不是配置了广播表导致。配合日志看一遍完整链路物理库插入一条数据在 Mycat 端查询两侧时间戳一致说明路由和返回链路都没问题。6.3 后悔药配置回退与重启检查清单改动配置前先备份整个 conf 目录这是我踩过坑后养成的习惯。回退流程非常简单停掉服务把备份的 conf 目录覆盖回去重启再走一遍端口和数据源验证。不要只备份单个文件因为 Mycat2 的配置之间存在互相引用只回退一个文件可能导致版本不一致。从那以后我每次动 conf 前都强制走一遍备份、记录变更点、重启验证三步宁可多花一分钟备份也不愿在深夜为一条错误的配置反复翻日志。基础安装包本身不复杂复杂的是配置变更后留下的不确定性。希望这篇拆包笔记能帮你在第一次部署时就避开我走过的弯路。本文还有配套的精品资源点击获取
