MySQL 本身不原生支持分布式架构
MySQL 单实例是集中式数据库，
mysqld进程天然不具备跨节点自动分片、全局事务协调或一致性哈希路由能力。所谓“MySQL 分布式”，实际是通过外围组件或中间层拼装出的逻辑分布式——不是 MySQL 自己变分布式的，而是你把它“搭成”分布式的。
常见路径有三类：
ShardingSphere-JDBC（客户端分片）、
ProxySQL或
MySQL Router（代理层路由）、
Vitess（面向云原生的规模化分片方案）。选哪条路，取决于你的数据规模、事务复杂度和运维能力。
分片键（shard key）选错，性能反而更差
分片不是加机器就提速，关键在请求是否能精准落到单个分片。如果
WHERE条件里总缺分片键（比如用
user_id分片，但查询只带
order_time），就会触发广播查询——所有分片都扫一遍，延迟翻倍、连接数暴涨。 高频查询字段优先作为分片键，例如
user_id、
tenant_id避免用自增主键（如
id）直接分片，会导致写入热点（新数据全挤在最后一个分片） 复合分片键需谨慎：多数中间件不支持多列哈希，
sharding-jdbc的
ComplexKeysShardingAlgorithm实现成本高且难调优 时间字段（如
create_time）适合按月/年分片，但必须配合
WHERE中显式过滤，否则无法剪枝
跨分片 JOIN 和事务基本不可靠
MySQL 分布式下，
JOIN涉及多个物理库时，要么由中间件拉取数据后内存拼接（OOM 风险），要么退化为多次单分片查询+应用层组装。而
XID级别的分布式事务（如
XA）在 MySQL 8.0+ 虽支持，但性能极低、死锁率高，生产环境极少启用。
更务实的做法：
业务层拆解：把JOIN user, order改成先查
user_id，再查对应
order列表 冗余必要字段：在订单表里冗余
user_name，避免反查用户表 用异步方式对账：跨分片更新失败时，靠消息队列+定时任务补偿，而非强一致事务 警惕
SELECT COUNT(*)、
ORDER BY ... LIMIT：这类聚合/排序需合并所有分片结果，数据量大时延迟陡增
读写分离 + 分片不是万能组合
很多人以为“主库写 + 多从库读 + 分片打散”，就能无限扩容。但现实是：
binlog复制延迟会导致从库读到旧数据；分片后每个主库仍是单点，故障仍会中断部分业务；而代理层（如
ShardingSphere-Proxy）本身可能成为瓶颈。
真正要稳住，得盯住这些细节：
监控Seconds_Behind_Master，读请求超 500ms 延迟时自动切回主库 分片元数据（如分片规则、节点列表）必须可热更新，不能改一次配置重启整个代理
SHOW PROCESSLIST在代理层看不到真实后端连接状态，得在每个 MySQL 实例上单独看 备份策略要适配分片：不能只 dump 一个库，得并发跑
mysqldump --databases多个分片，再统一归档
分布式从来不是“加机器就完事”，而是把单机问题放大十倍后，再一个个亲手拧紧螺丝。最常被跳过的一步：没做分片前的压测基线对比。上线后发现 QPS 没涨反跌，往往是因为分片键导致缓存命中率归零，或者代理解析 SQL 耗时吃掉了本该省下的 IO 时间。
