MySQL不原生支持分布式部署，所谓“分布式MySQL”实为多个实例通过外部机制实现分片、高可用或读写分离；常见误区是将主从复制误作分布式数据库，真正可行方案仅有代理层分片（如ProxySQL）和存算分离架构（如Group Replication）。
MySQL 本身不原生支持分布式部署
MySQL 单实例是集中式架构，所谓“分布式 MySQL”实际指多个 MySQL 实例协同工作，靠外部机制实现数据分片、高可用或读写分离。直接用 mysqld 启动多个节点不会自动同步数据或路由请求——这点常被误认为“搭了集群就等于分布式”。
常见踩坑：把主从复制（CHANGE REPLICATION SOURCE TO）当成分布式数据库用，结果发现写还是只能打到主库，分库分表逻辑全得自己写、自己维护、自己处理跨分片事务。
真正能落地的分布式方案只有两类
一类是代理层分片（如 ProxySQL + 手动分库），另一类是存算分离架构（如 MySQL Group Replication 或 Percona XtraDB Cluster）。前者适合读多写少、业务能接受最终一致；后者强一致性但对网络延迟极其敏感，跨机房基本不可用。
-
MySQL Group Replication要求所有节点时钟误差 ERROR 3092 (HY000) -
ProxySQL的mysql_servers表必须手动维护权重和状态，故障后不会自动剔除宕机节点，得配monitor模块并调好ping_interval_ms - 用
Vitess或TiDB替代 MySQL？那是换数据库，不是“MySQL 分布式部署”
集群管理工具 ≠ 自动化分布式
像 Orchestrator、MHA、ClusterControl 这些工具只管高可用切换，不管分片、路由、全局事务。它们监听 SHOW SLAVE STATUS，发现 Seconds_Behind_Master > 60 就报警，但不会帮你把用户 ID 为奇数的请求发到 shard_1。
实操建议：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 别指望
ClusterControl点几下就生成分片策略——它连分片键都不认识 -
Orchestrator默认不接管 DNS 或 VIP，故障转移后应用连接仍可能打到旧主库，得自己写回调脚本更新haproxy.cfg或调用云厂商 API - 所有管理工具依赖
mysql.user表里的监控账号权限，漏授SUPER或REPLICATION CLIENT会导致检测失效
真正要动手的地方在应用层和中间件
MySQL 分布式最重的活不在 DBA 工具配置，而在应用怎么发 SQL。比如用 ShardingSphere-JDBC，就得在 application.yml 里明确写死 sharding-column: user_id 和 algorithm-expression: ds_${user_id % 2}.t_order_${user_id % 4}——这些规则一旦上线，改起来牵一发而动全身。
容易被忽略的点：
- 时间类型字段（
DATETIME）做分片键？时区不统一会导致路由错乱，NOW()在不同节点返回值不同 -
SELECT * FROM t_order WHERE order_id IN (1,2,3)看似简单，但若order_id不是分片键，中间件会广播到所有库，性能反不如单库 - 任何涉及
JOIN、GROUP BY、ORDER BY跨分片的查询，都得评估是否允许聚合层降级处理，还是直接禁止
分布式不是加几台机器、跑几个命令就完事的事。数据怎么切、切完怎么查、查错怎么兜底，每个环节都得有明确约定，而且得让开发和 DBA 都认这个账。
