我们不是为了使用 TiDB 而使用，而是去解决一些 MySQL 无法满足的场景，关系型数据库我们还是优先推荐 MySQL。能用分库分表能解决的问题尽量选择 MySQL，毕竟运维成本相对较低、数据库版本更加稳定、单点查询速度更快、单机 QPS 性能更高这些特性是分布式数据库无法满足的。

非分片查询场景：上游 MySQL 采用了分库分表的设计，但部分业务查询无法利用分片。通过自建 DTS 将 MySQL 数据同步到 TiDB 集群，非分片 / 聚合查询则使用 TiDB 处理，能够在不依赖原始分片结构的情况下，实现高效的数据查询和分析。

分析 SQL

多场景：业务逻辑比较复杂，往往存在并发查询和分析查询的需求。通过自建 DTS 将 MySQL 数据同步到 TiDB，复杂查询在 TiDB 执行、点查在 MySQL 执行。TiDB 支持水平扩展，其分布式计算和存储能力使其能够高效处理大量的并发查询请求。既保障了 MySQL 的稳定性，又提升了整体的查询能力。

展开剩余39%

磁盘使用大场景：在磁盘使用率较高的情况下，可能会出现 CPU 和内存使用率低，但磁盘容量已达到 MySQL 的瓶颈。TiDB 能够自动进行数据分片和负载均衡，将数据分布在多个节点上， 缓解单一节点的磁盘压力，避免了传统 MySQL 中常见的存储瓶颈问题，从而提高系统的可扩展性和灵活性。

数据倾斜场景：在电商业务场景上，每个电商平台都会有一些销量很好的头部卖家，数据量会很大。即使采取了进行分库分表的策略，仍难以避免大卖家的数据会存储在同一实例中，这样会导致热点查询和慢 SQL 问题，尽管可以通过添加索引或进一步分库分表来优化，但效果有限。采用分布式数据库能够有效解决这一问题。可以将数据均匀地分散存储在多个节点上，在查询时则能够并发执行，从而将流量分散，避免热点现象的出现。随着业务的快速发展和数据量的不断增长，借助简单地增加节点，即可实现水平扩展，满足海量数据及高并发的需求。

发布于：湖南省