MySQL分布式系统必须用InnoDB而非MyISAM，因后者不支持事务、行级锁和崩溃恢复；binlog_format须统一设为ROW以保障复制一致性；XA事务需开启innodb_support_xa和innodb_strict_mode；读写分离应避免共享从库，优先按分片路由。
MySQL 分布式系统里别用 MyISAM
MyISAM 在分布式场景下基本不可用，核心原因是它不支持事务、行级锁和崩溃安全恢复。一旦网络分区或节点宕机，表容易损坏，且无法保证跨节点操作的一致性。InnoDB 是唯一现实选择，不是因为它完美，而是因为 MyISAM 根本没资格参与分布式事务链路。
InnoDB 的 binlog_format 必须设为 ROW
在主从复制或分库分表（如用 ShardingSphere 或 ProxySQL）中，如果 binlog_format 是 MIXED 或 STATEMENT，会出现主从数据不一致——尤其是涉及 NOW()、UUID()、用户变量或自增主键批量插入时。
-
ROW模式记录每一行变更，复制精确，但 binlog 体积大、写入稍慢 - 必须在所有节点统一配置，不能只改主库；检查命令：
SHOW VARIABLES LIKE 'binlog_format'; - 某些旧版中间件（如早期
Atlas）不兼容ROW，得升级或换型
分布式事务下 innodb_support_xa 和 innodb_strict_mode 要开
XA 事务（比如通过 Seata 或 Atomikos 协调多 MySQL 实例）依赖 InnoDB 的 XA 接口。关掉 innodb_support_xa 会导致 prepare 阶段失败，报错类似：ERROR 1399 (XAE05): XAER_RMFAIL: The command cannot be executed when global transaction is in the IDLE state。
-
innodb_support_xa=ON（MySQL 8.0.28+ 默认开启，但低版本需手动确认） -
innodb_strict_mode=ON防止隐式类型转换或截断导致 XA 提交后数据异常 - 注意：启用 XA 会略微增加事务延迟，高并发下需压测验证
读写分离时 slave_parallel_type=LOGICAL_CLOCK 不够用
单纯靠 MySQL 原生并行复制，在分布式系统中常出现从库延迟飙升——尤其当多个分片（shard）共用一个从库，或业务大量使用 INSERT ... SELECT、临时表时。
-
LOGICAL_CLOCK只对同一事务内并行有效，跨事务仍串行回放 - 更稳的做法是按分片路由：每个 shard 对应独立从库，避免日志混杂
- 若必须共享从库，建议配合
replica_parallel_workers > 4并监控performance_schema.replication_applier_status_by_coordinator
真正难的不是选引擎，而是让 InnoDB 在分布式链路里不暴露它的“单机惯性”——比如默认隔离级别 REPEATABLE-READ 下的间隙锁行为，在分库分表后可能引发意料外的死锁，这点很多人上线后才踩到。
