Mycat 1.6.x 不推荐用于新项目，因其长期缺乏维护、不兼容 MySQL 8.0 默认认证协议（caching_sha2_password），且分片配置易错、事务与跨节点 JOIN 支持弱，数据一致性风险高；应优先选用 ShardingSphere-Proxy。
直接说结论：Mycat 在当前（2024 年）已不推荐用于新项目做 MySQL 水平分库分表，它长期缺乏活跃维护、对 MySQL 8.0+ 认证协议和新特性支持滞后，且真实生产中极易因配置错位、事务/跨节点 JOIN / 全局自增 ID 等问题引发数据不一致。
为什么 mycat-server 启动后连不上 MySQL 8.0？
Mycat 1.6.x 默认使用 MySQL 5.x 的 mysql_native_password 插件认证，而 MySQL 8.0 默认启用 caching_sha2_password，导致连接被拒绝，错误典型为：Access denied for user 'root'@'192.168.x.x' (using password: YES)，但实际密码正确。
实操建议：
- MySQL 侧临时降级认证插件：
ALTER USER 'mycat_user'@'%' IDENTIFIED WITH mysql_native_password BY 'pwd'; FLUSH PRIVILEGES; - 或升级到 Mycat 2.x（注意：它已重构成 Java + Netty + YAML 配置，与 1.x 完全不兼容，
schema.xml和rule.xml彻底废弃） - 更稳妥的替代方案是改用
ShardingSphere-Proxy（支持 MySQL/PostgreSQL 协议，兼容 8.0+，事务和分布式查询能力更强）
dataNode 和 dataHost 配置错位导致路由失败
Mycat 1.x 的路由逻辑依赖两层映射：逻辑库/表 → dataNode（物理库名+实例）→ dataHost（实际数据库连接池）。常见错误是把多个 MySQL 实例写进同一个 dataHost 的 host 标签里，误以为能自动负载均衡——实际上 Mycat 不做读写分离或主从切换，dataHost 只允许配一个写库地址，其余必须通过 writeHost/readHost 显式声明，且 readHost 不参与分片路由。
关键点：
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
-
dataNode名必须唯一，且格式为dn1、dn2，不能含下划线或大写字母 -
dataHost中的balance属性仅控制读请求分发，对分片 SQL 路由无影响 - 若某
dataNode对应的 MySQL 实例宕机，Mycat 默认不自动摘除，需配合heartbeatSQL（如select user()）和switchType手动触发切换
分片键（sharding key）选错让 INSERT 直接报错
Mycat 要求所有分片表的 INSERT 必须显式包含分片字段（如 user_id），否则抛出 java.lang.NullPointerException 或 can't find table rule。这不是语法错误，而是路由引擎找不到分片策略入口。
典型场景与处理：
- 用
mod-long规则但插入user_id为NULL或字符串 → 改用auto-sharding-long并确保字段类型为BIGINT - 跨分片
UPDATE或DELETE（WHERE 条件不含分片键）→ Mycat 会广播到所有节点，性能极差，且无法保证原子性；必须改写成带分片键的语句 - 全局序列（
MYCAT_SEQ）未初始化或sequence_db_conf.properties配置路径错误 → 插入时卡住或返回负数 ID
真正棘手的是二级分片（比如先按 province 分库、再按 user_id 分表）：Mycat 1.x 的 sharding-by-murmur 或 sharding-by-intfile 不支持嵌套规则，必须手动拼 dataNode 名并硬编码映射，一旦扩容几乎无法平滑迁移。这点在设计初期就容易被忽略，等数据量上来才发现改不动。
