目录1. 数据量巨大分片规则频繁变更分片运维成本爆炸MySQL 现状什么时候要分布式数据库2. 强一致性的分布式事务跨分片高频事务MySQL 现状需要分布式数据库场景3. 全局唯一索引、跨分片复杂查询、跨库 join 大量使用MySQLSharding 痛点适合分布式库场景4. 高可用多机房部署、机房级容灾MySQL 现状需要分布式数据库场景5. 海量数据下同时要求 OLTP 联机写入 OLAP 实时分析MySQL 现状分布式数据库场景6. 数据规模极大单表超亿并且没有合适分片键7. 不适合继续 MySQL 的业务特征总结表8. 误区澄清不要上来就选分布式数据库面试高频反问既然 TiDB 兼容 MySQL为什么很多企业还是 Sharding‑JDBCMySQL前提单机 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‑JDBCMySQL。2. 强一致性的分布式事务跨分片高频事务MySQL 现状单库事务很好跨库 / 跨分片事务MySQL 原生不支持分布式事务。Sharding‑JDBC 支持 XA但 XA 性能差、锁粒度大大并发场景性能暴跌Seata AT 最终一致性只能做到最终一致有窗口期不一致无法满足强一致。如果业务大量请求需要同时修改多个分片的数据XA/Seata 会成为性能瓶颈还会出现死锁、回滚复杂。需要分布式数据库场景业务存在高频跨分片强一致事务要求 ACID 强一致不能容忍最终一致性的短暂数据不一致。例如金融核心账务一笔交易同时修改多个用户账户必须原子成功 / 失败。 原生分布式数据库底层 Raft/Paxos原生支持跨节点分布式事务性能远高于 MySQLXA。反例跨分片事务很少可以用 Seata AT 最终一致继续 MySQL 分库分表。3. 全局唯一索引、跨分片复杂查询、跨库 join 大量使用MySQLSharding 痛点全局唯一索引很难实现MySQL 各分片独立无法全局唯一约束只能业务层或者 Redis 做去重容易漏。跨分片join、子查询、聚合sum/count/group by中间件只能做内存归并数据量大时性能极差很多 SQL 语法不支持。无法做全局排序大结果集内存溢出。适合分布式库场景业务大量需要全局唯一约束手机号、身份证全局唯一经常跨分片 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 的业务特征总结表业务特征MySQL含 Sharding‑JDBC原生分布式数据库分片键稳定极少跨分片事务、join✅适合没必要需要频繁扩缩容、自动数据重分布❌人工成本极高✅高频跨分片强一致分布式事务❌XA 性能差Seata 仅最终一致✅需要全局唯一索引、大量跨分片 join❌能力弱大量逻辑下压业务✅多机房部署、机房级故障容灾❌架构复杂容易丢数据✅HTAP 混合负载读写 实时统计❌需要搭建额外同步链路✅找不到合适分片键❌分片倾斜、热点严重✅8. 误区澄清不要上来就选分布式数据库分布式数据库也有代价网络开销大单分片简单查询性能略低于单机 MySQL运维复杂度高于单机 MySQL事务越大跨节点越多性能衰减明显。优先顺序单机 MySQL → MySQL 主从 → MySQL 分库分表 (Sharding‑JDBC) → 原生分布式数据库。 只有当分库分表带来的业务开发成本、运维成本已经无法接受才切换分布式数据库。面试高频反问既然 TiDB 兼容 MySQL为什么很多企业还是 Sharding‑JDBCMySQL分片键稳定业务 SQL 约束好很少跨分片操作Sharding 足够成本更低简单业务不需要自动重分布、全局索引团队 MySQL 运维栈成熟不想引入全新分布式数据库组件原生分布式数据库硬件资源消耗更高。