湖南
我们不是为了使用 TiDB 而使用，而是去解决一些 MySQL 无法满足的场景，关系型数据库我们还是优先推荐 MySQL。能用分库分表能解决的问题尽量选择 MySQL，毕竟运维成本相对较低、数据库版本更加稳定、单点查询速度更快、单机 QPS 性能更高这些特性是分布式数据库无法满足的。
非分片查询场景：上游 MySQL 采用了分库分表的设计，但部分业务查询无法利用分片。通过自建 DTS 将 MySQL 数据同步到 TiDB 集群，非分片 / 聚合查询则使用 TiDB 处理，能够在不依赖原始分片结构的情况下，实现高效的数据查询和分析。
分析 SQL
多场景：业务逻辑比较复杂，往往存在并发查询和分析查询的需求。通过自建 DTS 将 MySQL 数据同步到 TiDB，复杂查询在 TiDB 执行、点查在 MySQL 执行。TiDB 支持水平扩展，其分布式计算和存储能力使其能够高效处理大量的并发查询请求。既保障了 MySQL 的稳定性，又提升了整体的查询能力。
磁盘使用大场景：在磁盘使用率较高的情况下，可能会出现 CPU 和内存使用率低，但磁盘容量已达到 MySQL 的瓶颈。TiDB 能够自动进行数据分片和负载均衡，将数据分布在多个节点上， 缓解单一节点的磁盘压力，避免了传统 MySQL 中常见的存储瓶颈问题，从而提高系统的可扩展性和灵活性。
数据倾斜场景：在电商业务场景上，每个电商平台都会有一些销量很好的头部卖家，数据量会很大。即使采取了进行分库分表的策略，仍难以避免大卖家的数据会存储在同一实例中，这样会导致热点查询和慢 SQL 问题，尽管可以通过添加索引或进一步分库分表来优化，但效果有限。采用分布式数据库能够有效解决这一问题。可以将数据均匀地分散存储在多个节点上，在查询时则能够并发执行，从而将流量分散，避免热点现象的出现。随着业务的快速发展和数据量的不断增长，借助简单地增加节点，即可实现水平扩展，满足海量数据及高并发的需求。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
