MyCat分库分表中间件该如何与新建的MySQL 5.7主从环境对接？

MyCat 1.6.x对接MySQL 5.7主从必须设binlog_format=ROW，禁用STATEMENT；dataHost中需硬编码writeHost/readHost角色，不支持自动故障转移；心跳须用select user()，balance="3"不感知延迟，读一致性需SQL hint控制。

MyCat 1.6.x 可以对接 MySQL 5.7 主从，但必须禁用 binlog_format=STATEMENT，且不能依赖 MyCat 自动识别主从切换——它不支持原生 MHA 或 Orchestrator 的故障转移感知。

MySQL 5.7 主从配置必须设为 binlog_format=ROW

MyCat 1.6（主流生产版本）的读写分离逻辑依赖从库能准确回放主库变更，而 STATEMENT 格式在函数、临时表、非确定性语句下容易导致主从不一致，MyCat 的 show slave status 解析和心跳检测可能误判同步延迟或中断。

1. 在主库和所有从库的 my.cnf 中显式设置：binlog_format=ROW
2. 重启 MySQL 后执行 SELECT @@binlog_format; 确认返回 ROW
3. 避免使用 SET GLOBAL binlog_format=... 临时修改——MyCat 连接建立后不会重新获取该变量值

schema.xml 中的 dataHost 需手动声明主从角色

MyCat 不自动发现主从拓扑，所有节点角色由配置文件硬编码决定。即使你用了 GTID + AUTO_POSITION=1，MyCat 仍只按 writeHost / readHost 标签静态路由。

1. writeHost 只能填主库地址，且仅允许 1 个（MyCat 1.6 不支持多主写入）
2. readHost 可配多个，但需确保每个都已开启 read_only=ON，否则 MyCat 的读请求可能误发到主库造成连接竞争
3. 示例片段：

   <dataHost name="mysql57" ...><writeHost host="master" url="192.168.10.10:3306" user="mycat" password="123456"><readHost host="slave1" url="192.168.10.11:3306" user="mycat" password="123456"/><readHost host="slave2" url="192.168.10.12:3306" user="mycat" password="123456"/></writeHost></dataHost>

心跳检测必须用 select user() 而非 select 1

MySQL 5.7 默认启用 sql_mode=STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION，部分 MyCat 版本内置的心跳语句 select 1 在某些权限模型下会因无数据库上下文被拒绝（尤其当用户只授予了特定 DB 权限时）。

1. 在 schema.xml 的 dataHost 内，显式设置：heartbeat="select user()"
2. 确保 MyCat 连接用户对任意库都有 USAGE 权限（至少能执行无库上下文的系统函数）
3. 不要依赖 switchType="1" 实现自动主从切换——它只响应 show slave status 中 Seconds_Behind_Master 为 NULL 或负数，而 MySQL 5.7 在复制中断时该值常为 NULL，易触发误切

主从延迟大时，balance="3" 会把读请求压向延迟更高的从库

MyCat 的 balance 参数控制读负载分发策略。balance="3" 表示“全部读节点参与负载均衡”，但它不感知实际复制延迟，只轮询可用节点。若某从库延迟达分钟级，查询仍可能命中它并返回过期数据。

1. 生产环境建议改用 balance="1"（只从第一个 readHost 读），配合监控工具（如 Prometheus + mysqld_exporter）单独告警延迟
2. 如需读一致性，应在应用层加 hint：/*#mycat:db_type=master*/ SELECT ...
3. 注意：MyCat 1.6 对 hint 的解析不支持空格或换行，/* #mycat... 会失效

真正麻烦的是跨分片事务与主从切换的耦合——MyCat 的 XA 支持极弱，一旦主库宕机期间有未提交的分布式事务，恢复后很难对齐各分片状态。这比配置本身更值得花时间设计补偿或规避方案。