MySQL 云上架构怎么选：单库、读写分离和分库分表的决策指南

很多团队在 MySQL 压力变大时，会直接讨论“要不要分库分表”。这通常不是第一步。架构选择应该先看业务负载、数据增长、读写比例、故障容忍度和运维能力，再决定是继续优化单库、上读写分离，还是进入分片架构。

本文按云架构决策指南的方式，把 MySQL 常见架构拆成可判断的几个选项：单库增强、云 RDS 多可用区、读写分离、缓存辅助、分库分表。重点不是堆服务名，而是给出什么时候选、为什么选、选了以后要补哪些风险控制。

先定义业务负载：数据库到底哪里吃紧

架构决策的第一步不是画图，而是把负载说清楚。MySQL 的压力可能来自读多、写多、慢查询、连接数、热点行、表体积、备份窗口，也可能只是某几个接口没有索引。不同压力对应的方案完全不同。

建议先用一张表记录当前状态：

日均写入量：订单表 80 万行/天
高峰 QPS：读 3200，写 260
慢查询：top 10 接口集中在订单列表和库存扣减
最大单表：order_item 1.8 亿行
可接受恢复时间：5 分钟内
团队能力：2 名后端，暂无专职 DBA

有了这些信息，才知道瓶颈是查询路径、写入链路、存储容量还是高可用能力。如果没有这一步，读写分离可能掩盖慢查询，分库分表可能把简单问题变成长期运维成本。

约束条件：成本、可靠性和团队能力

同样的 QPS，在不同团队里会得到不同答案。一个有 DBA 和平台团队的业务可以承受复杂分片；一个小团队更适合先用云数据库托管高可用、备份、监控和故障切换。

成本约束

成本不只是机器费用，还包括研发改造、回归测试、数据迁移、故障处理和后续值班。分库分表会把成本长期放大，读写分离会增加一致性处理成本，单库增强则需要持续关注容量上限。

可靠性约束

如果业务要求故障后几分钟内恢复，单台自建 MySQL 通常不够。此时优先考虑云 RDS 多可用区、自动备份、只读实例和跨区容灾，而不是先改业务分片。

团队能力约束

分布式数据库架构不是一次改造，而是一套长期流程：分片键选择、跨分片查询、全局 ID、数据迁移、灰度、回滚、容量规划都需要人维护。团队能力不足时，架构越复杂，故障排查越慢。

方案对比：单库、读写分离、分库分表分别解决什么

下面这张对比表可以作为初筛：

推荐架构：从保守路径开始扩展

大多数业务可以按“先治理单库，再增强高可用，再拆读压力，最后考虑分片”的顺序推进。这个路径的好处是每一步都有可验证收益，也能避免过早引入分布式复杂度。

第一阶段：单库治理

先把慢 SQL、缺失索引、无边界分页、过大的事务处理掉。可以从这些检查开始：

SHOW GLOBAL STATUS LIKE 'Threads_running';
SHOW GLOBAL STATUS LIKE 'Questions';

SELECT *
FROM sys.schema_table_statistics
ORDER BY rows_fetched DESC
LIMIT 10;

如果优化后 CPU、IO、连接数都回到稳定区间，就没有必要立刻做分片。

第二阶段：云 RDS 多可用区

当业务对恢复时间有要求时，优先把单点风险交给托管能力处理：自动备份、主备切换、监控告警、实例规格扩容、存储扩容。这一步通常对业务代码侵入较小。

第三阶段：读写分离和缓存辅助

如果读压力明显高于写压力，可以把列表页、详情页、报表查询路由到只读实例；对热点数据增加缓存。这里必须保留强一致读的直连主库路径，例如支付结果、库存扣减后的确认查询。

第四阶段：分库分表

当单表容量和写入吞吐成为硬瓶颈，且业务分片键稳定时，再考虑分库分表。典型分片键包括用户 ID、租户 ID、订单 ID 的某个稳定前缀。不要用经常变化、查询维度很多的字段做分片键。

风险点：选错架构常见的四个后果

风险 1：读写分离后读到旧数据

复制延迟会让刚写入的数据在只读实例上短时间不可见。解决方式是对关键链路做主库读、会话内读主、或在业务层等待复制位点，但不要默认所有读都走从库。

风险 2：分片键选错导致跨库查询变多

如果订单按用户分片，但后台主要按商家、地区和时间查询，就会出现大量跨分片聚合。分片前必须盘点核心查询维度，并为后台查询准备异步汇总表或搜索索引。

风险 3：只加缓存，没有治理数据库

缓存可以削峰，但不能替代数据库治理。缓存失效、回源峰值、热点 key 都可能把压力重新打回 MySQL。缓存方案必须配合限流、互斥加载和降级页面。

风险 4：只关注峰值，不关注恢复流程

高可用架构要能切换，也要能恢复。备份是否可用、回滚是否演练、只读实例是否跟上、告警是否有人处理，这些比架构图本身更重要。

落地清单：上线前逐项确认

• 负载数据已记录：读写 QPS、慢查询、连接数、最大表、增长速度。
• 单库优化已完成：核心 SQL 有索引，分页有边界，大事务已拆小。
• 高可用已验证：备份可恢复，主备切换有演练记录，告警能触达值班人。
• 读写分离已标记强一致路径：下单、支付、库存、权限变更后读取主库。
• 缓存有失效策略：热点 key 有保护，回源有并发控制，数据过期可接受。
• 分库分表前完成查询盘点：分片键稳定，跨分片查询有替代方案。
• 发布有回退路径：连接串、路由规则、只读开关和缓存开关都能快速调整。

总结一下，MySQL 云上架构选择的核心是“用当前约束选择足够简单的方案”。读多先看读写分离和缓存，可靠性先看云 RDS 多可用区，容量和写入真的触顶再考虑分库分表。每一步都要配合指标、风险和回退路径，这样架构扩展才是可控的。