企业官网建设流程全解析

目录

1. 数据量巨大，分片规则频繁变更，分片运维成本爆炸

MySQL 现状

什么时候要分布式数据库

2. 强一致性的分布式事务，跨分片高频事务

MySQL 现状

需要分布式数据库场景

3. 全局唯一索引、跨分片复杂查询、跨库 join 大量使用

MySQL+Sharding 痛点

适合分布式库场景

4. 高可用：多机房部署、机房级容灾

MySQL 现状

需要分布式数据库场景

5. 海量数据下，同时要求 OLTP 联机写入 + OLAP 实时分析

MySQL 现状

分布式数据库场景

6. 数据规模极大，单表超亿，并且没有合适分片键

7. 不适合继续 MySQL 的业务特征总结表

8. 误区澄清：不要上来就选分布式数据库

面试高频反问：既然 TiDB 兼容 MySQL，为什么很多企业还是 Sharding‑JDBC+MySQL？

前提：单机 MySQL、主从、分库分表（Sharding‑JDBC/Sharding‑Proxy）都属于MySQL 生态扩展，本质还是 MySQL；分布式数据库指：TiDB、OceanBase、CockroachDB 这类原生分布式数据库。 Sharding‑JDBC 只是中间件做分片，没有解决 MySQL 原生架构的很多短板，很多场景即便做了分库分表依然很难受，这时就要换原生分布式库。

1. 数据量巨大，分片规则频繁变更，分片运维成本爆炸

MySQL 现状

通过 Sharding‑JDBC 做分库分表，分片键一旦选定很难修改。

• 如果业务变化，需要重新选分片键：要全量迁移数据、重分布数据，需要自己写迁移脚本、双写、校验数据，业务停机 / 灰度工作量巨大。
• 扩缩容：新增节点，需要人工迁移分片数据，手动 resharding，运维重。
• 冷热分离需要自己做，MySQL 本身不支持。

什么时候要分布式数据库

• 数据量几十 TB～百 TB 级别，业务经常调整分片逻辑
• 需要在线水平扩缩容：加节点自动做数据重分布，不需要业务改代码、不需要人工迁移。

TiDB/OceanBase 可以自动分裂、迁移 region，扩节点自动匀数据，业务几乎无感知。

反例：分片键稳定（user_id、order_id），业务不会换分片键，可以继续 Sharding‑JDBC+MySQL。

2. 强一致性的分布式事务，跨分片高频事务

MySQL 现状

• 单库事务很好；跨库 / 跨分片事务，MySQL 原生不支持分布式事务。
• Sharding‑JDBC 支持 XA，但 XA 性能差、锁粒度大，大并发场景性能暴跌；Seata AT 最终一致性，只能做到最终一致，有窗口期不一致，无法满足强一致。
• 如果业务大量请求需要同时修改多个分片的数据，XA/Seata 会成为性能瓶颈，还会出现死锁、回滚复杂。

需要分布式数据库场景

业务存在高频跨分片强一致事务，要求 ACID 强一致，不能容忍最终一致性的短暂数据不一致。

例如金融核心账务，一笔交易同时修改多个用户账户，必须原子成功 / 失败。 原生分布式数据库底层 Raft/Paxos，原生支持跨节点分布式事务，性能远高于 MySQL+XA。

反例：跨分片事务很少，可以用 Seata AT 最终一致，继续 MySQL 分库分表。

3. 全局唯一索引、跨分片复杂查询、跨库 join 大量使用

MySQL+Sharding 痛点

1. 全局唯一索引很难实现：MySQL 各分片独立，无法全局唯一约束，只能业务层或者 Redis 做去重，容易漏。
2. 跨分片join、子查询、聚合sum/count/group by：中间件只能做内存归并，数据量大时性能极差；很多 SQL 语法不支持。
3. 无法做全局排序，大结果集内存溢出。

适合分布式库场景

业务大量：

• 需要全局唯一约束（手机号、身份证全局唯一）
• 经常跨分片 join、复杂统计、多表聚合，不想在应用层自己做归并逻辑。

TiDB 完全兼容 MySQL 语法，原生支持跨节点 join、全局索引，不需要业务改造 SQL。

反例：业务 SQL 简单，尽量按分片键查询，极少跨分片 join，可以继续 MySQL 分库。

4. 高可用：多机房部署、机房级容灾

MySQL 现状

MySQL 主从复制是异步 / 半同步：

• 传统 MGR 最多 9 节点；跨机房部署延迟高；机房故障，半同步有可能丢数据。
• 想要多机房写，MySQL 原生做不到多写；只能单写节点，其他机房只读。
• 要实现跨机房强一致容灾，需要非常复杂的架构：MGR + 中间件，运维难度极高。

需要分布式数据库场景

• 两地三中心、多机房同时容灾，机房整体宕机不丢数据，业务持续写入。
• 需要多机房读写，Raft 协议保证多副本强一致。

TiDB、OB 天然支持多副本跨机房部署，副本自动同步，故障自动选主，不需要人工切换主从。

反例：单机房部署，一主多从，机房故障允许短暂不可用，MySQL 足够。

5. 海量数据下，同时要求 OLTP 联机写入 + OLAP 实时分析

MySQL 现状

MySQL 是 OLTP 库，大量写入同时跑大查询，会把实例打挂。 分库分表后统计分析更麻烦，需要把数据同步到 ES/Hive 做分析链路。

分布式数据库场景

业务既要高并发联机交易，又要实时做大量统计分析，不想维护一套同步链路把数据同步到数仓。

TiDB HTAP 混合负载，一份数据既支持高并发事务，又支持实时分析，省去同步 ETL 链路。

反例：OLTP 和 OLAP 严格隔离，业务通过 binlog 同步到专门分析引擎，MySQL 可以继续用。

6. 数据规模极大，单表超亿，并且没有合适分片键

这是非常典型场景：找不到好的分片键。

• 例如：日志、设备上报表，经常按照time查询，又要按照device_id查询；没有字段可以作为分片键，无论按哪个分片，总有场景出现跨分片爆炸。 MySQL 分库分表会出现热点分片，很难解决。 原生分布式数据库：支持全局索引，同一份数据可以多个索引，避免热点。

7. 不适合继续 MySQL 的业务特征总结表

8. 误区澄清：不要上来就选分布式数据库

分布式数据库也有代价：

1. 网络开销大，单分片简单查询性能略低于单机 MySQL
2. 运维复杂度高于单机 MySQL；
3. 事务越大，跨节点越多性能衰减明显。

优先顺序：单机 MySQL → MySQL 主从 → MySQL 分库分表 (Sharding‑JDBC) → 原生分布式数据库。 只有当分库分表带来的业务开发成本、运维成本已经无法接受，才切换分布式数据库。

面试高频反问：既然 TiDB 兼容 MySQL，为什么很多企业还是 Sharding‑JDBC+MySQL？

1. 分片键稳定，业务 SQL 约束好，很少跨分片操作，Sharding 足够，成本更低；
2. 简单业务，不需要自动重分布、全局索引；
3. 团队 MySQL 运维栈成熟，不想引入全新分布式数据库组件；
4. 原生分布式数据库硬件资源消耗更高。