TDSQL分布式数据库：分片键、迁移与选型实战拆解

去年帮一个做订单系统的团队做架构评审，他们的MySQL主库是8核64G，日订单量刚过三百万，慢查询日志里排第一的永远是那条"按用户ID加时间范围查历史订单"的SQL。当时的方案是应用层分库分表：按用户ID哈希分32个库，每个库再按月份分子表，中间件跑在业务进程里。这套东西跑了半年没出大问题，但等到要加一个字段、要改一次分片规则、要做一次跨月对账的时候，团队里没人敢动那份配置——改错一行就是全站订单查不出来。后来他们把数据迁到了腾讯云TDSQL，分片规则从应用层挪到了数据库层，扩容这件事从"停机两天搬数据"变成了控制台上几步操作。这篇文章就想把TDSQL这类企业级分布式数据库拆开讲清楚：它是什么、靠什么撑住高并发和大数据量、分片键怎么选、存量业务怎么迁、线上怎么盯，以及最关键的——什么情况下你根本不需要它。

1. 从一台撑不住的MySQL主库说起：TDSQL要解决的真问题

单机MySQL的瓶颈从来不是单一维度的。CPU、内存、磁盘IO、连接数、单表行数、DDL耗时，这几样东西会在同一个时间段一起找上门。我见过最典型的场景是：业务量涨到某个点之后，写入开始堆积，主从延迟从毫秒级跳到十几秒，报表查询把Buffer Pool冲得七零八落，DBA只能不断加只读实例，但主库的写压力一点没减。这个时候的常规解法就是分片，而分片的位置决定了后面几年的运维成本。

1.1 应用层分库分表的天花板在哪里

用ShardingSphere这类中间件在应用层分片，前期确实快，改改配置就能跑。但它的代价是延迟支付的，通常在这几个时刻集中爆发。

第一是跨片查询。业务发展过程中总会出现按非分片键查询的需求，比如运营要查某个订单号、财务要按支付流水号对账。中间件只能把查询广播到所有分片再归并，分片数越多，尾延迟越难看。32个分片广播一次，如果每个分片500微秒，理论上最慢的那条要等所有分片返回，实际观测到的P99往往是单分片的十几倍。

第二是扩容。分片数从32扩到64，中间件支持不一致的路由规则，但历史数据要重新分布。你得写一套迁移工具，做双写，做数据校验，最后挑一个凌晨切换。整个过程里业务代码要兼容"新旧两套路由"，这种技术债会一直留在代码库里。

第三是DDL和分布式事务。加一个字段要执行32次，加一个唯一索引要考虑全局唯一性，跨片的事务得靠应用层补偿或者Seata这类框架兜底，而这些框架本身又引入了新的可用性风险点。我个人的判断是：分片数超过16、或者团队里没有专人维护这套中间件，就该考虑把分片下沉到数据库层了。

1.2 TDSQL的产品家族与三种不同取舍

腾讯云TDSQL不是一个单一产品，而是一个家族，选型前必须分清楚它们各自解决什么问题。按我实际接触到的部署形态，大致可以分成三条线：

产品形态	架构特点	适合什么场景	需要注意什么
TDSQL MySQL版（分片形态）	计算与存储分离，多个SET存储节点，接入层负责路由	单表上亿行、写入QPS很高、需要线性扩容的OLTP业务	分片键设计是不可逆决策，改起来很痛
TDSQL-C（云原生形态）	计算存储分离，共享分布式存储，一主多读	单库能扛住、但需要快速扩缩容和秒级只读扩展的业务	本质仍是单实例逻辑，不做水平分片
TDSQL PG版	基于PostgreSQL生态，支持较复杂的查询与混合负载	既有事务又有一定分析诉求、SQL较重的系统	与MySQL生态的语法差异需要重新评估

这三条线的共同点是高可用和备份能力由平台兜底：多副本、跨可用区部署、时间点恢复、故障自动切换，这些本来需要DBA手工搭建的东西变成了默认能力。区别在于扩展方式——分片形态靠加SET横向扩展，云原生形态靠提升单实例规格和加只读节点纵向扩展。

提示：不要把"分布式数据库"默认理解成"一定要分片"。我见过好几个团队，业务量其实只要一个高规格实例加两个只读节点就能解决，却硬上了分片形态，结果把简单问题复杂化了。

1.3 哪些业务别急着上分布式

分布式不是免费的。它换来扩展性的同时，代价是跨片操作的性能损耗、分片键的长期约束、以及更复杂的排查链路。以我的经验，下面这几种情况先别上：

• 单表数据量在千万级以内，且未来两年增长可预期。用分区表加归档策略就能撑很久。
• 查询模式高度不规则，大量按不同维度做聚合。分片键选不出来，硬选就是给自己挖坑。
• 团队里没有能看懂执行计划、能定位慢查询根因的人。分布式数据库出问题时的排查门槛比单机高一个量级。
• 业务对强一致的要求集中在单行更新，实际上没有跨行、跨表的事务场景。这种情况读写分离加合理索引往往就够了。

反过来，如果你的业务呈现"数据量持续线性增长 + 写入按某个业务维度天然可分 + 有明显的峰值流量"这三个特征，那分布式带来的收益会很快覆盖掉它的复杂度成本。

2. 拆开TDSQL的骨架：SQL路由、分布式事务与存储节点怎么配合

理解一个分布式数据库，最好的方式是跟着一条SQL走一遍。从客户端发出请求，到结果返回，中间经过了哪些组件、每个组件做了什么决策，搞清楚了这一条链路，后面排查问题就不会盲人摸象。

2.1 接入层与SQL引擎做了什么

客户端连上来第一站是接入层（通常叫Proxy或网关）。这一层的核心职责是SQL解析和路由决策：解析出这条SQL涉及哪张表、条件里有没有分片键、需不需要广播。它本身不存业务数据，是一个无状态的转发层，可以横向扩多个实例，前面挂负载均衡。

路由决策大致分三类结果：

1. 单分片路由：SQL条件里带了完整的分片键，直接定位到一个SET。这是最快路径，性能基本等价于单机。
2. 有限分片路由：条件里带了分片键的IN列表，命中若干分片，并发下发后归并。
3. 全分片广播：条件里没有分片键，只能发给所有SET，再在接入层做排序、聚合、分页。这是最慢的路径，也是慢查询的主要来源。

SQL引擎再往下还有一层调度和元数据管理，负责维护分片规则、表结构版本、节点拓扑。这部分是平台自己管的，业务侧感知不到，但它决定了DDL能不能在线执行、扩容时路由能不能平滑切换。

2.2 分布式事务：两阶段提交与多数派落盘

跨SET的写操作靠两阶段提交保证原子性。流程可以简化成这样：接入层拿到全局事务ID，向所有涉及的分片下发prepare，每个分片在本地执行但不提交，把undo和redo都落盘；所有分片都prepare成功后，再统一下发commit；只要有一个失败，就集体回滚。

这里有个容易被忽略的细节：prepare阶段必须把日志刷到磁盘，否则协调者宕机后恢复不出来。所以分布式事务的写入延迟天然比单机高，通常在毫秒到十几毫秒这个量级。业务上如果有一条SQL更新了三张分片表，别指望它的延迟和单表更新一样。

数据可靠性靠的是副本间的同步复制。写入需要在多数派副本落盘之后才向客户端返回成功，这样即使某一个副本所在的物理机整体宕机，也不会丢已经提交的数据。代价是写入延迟取决于副本之间的网络往返时间，所以跨可用区部署时，机房间的网络质量直接决定了写入性能。

2.3 强一致与可用性之间那道选择题

分布式系统里绕不开CAP的取舍，TDSQL的做法是默认偏强一致，把选择权交给部署形态。

• 同城双可用区部署：副本分布在两个可用区，写入需要多数派确认，任意一个可用区故障不影响服务，数据不丢。
• 三副本跨三可用区：容灾能力最强，但跨区网络往返会拉高写入延迟，适合对RPO要求极高的核心账务类业务。
• 单可用区多副本：延迟最低，但机房级故障时恢复时间更长。

我的建议是先把业务的RTO和RPO写清楚，再去选部署形态。核心交易链路选强一致、跨可用区；日志、埋点、推荐特征这类可重算的数据，用最终一致甚至异步同步就够了，没必要为它们付强一致的性能成本。

3. 分片键选错，后面全是修车的活

分片键是分布式数据库里唯一一个"改了要还债"的决策。表建好了、数据进去了、业务跑起来了，再想换分片键，基本等于重做一次迁移项目。所以在建表之前，值得花两天时间把这件事想透。

3.1 分片键的四个硬指标

我评估一个候选分片键，习惯用四个维度打分：

• 基数：取值必须足够多。用"省份"当分片键，最多三十几个值，分成32片就等于按省摊派，广东一个省可能占掉一半流量。用"用户ID""订单ID"这种高基数字段才合理。
• 离散度：数据要均匀落片。自增ID直接用会出问题——新写入全部集中在最后一个分片，其他分片处于闲置状态。要么用哈希，要么用带随机前缀的ID生成策略。
• 查询命中率：绝大多数高频SQL的条件里是否包含这个字段。这一点最容易被忽略。如果分片键是用户ID，但80%的查询是按订单号来的，那这80%的请求全部走广播，分片反而比不分片还慢。
• 不可变性：分片键一旦确定就不能更新，否则意味着数据要在分片之间搬家。选一个业务上永远不会变的字段。

3.2 写入热点与数据倾斜的处理手法

即使分片键选对了，热点问题还是会出现。比较常见的两种情况：

一是时间维度的热点。订单表按月分表、按订单ID分片，结果新数据总是落在同一个分片（因为ID单调递增）。解决思路是给分片键加盐，比如用 hash(order_id, 16) 这种带取模因子的方式，让相邻ID散到不同分片。代价是范围查询会退化成广播，需要权衡。

二是业务维度的倾斜。某个大客户贡献了40%的写入量，按租户ID分片就会有一个分片明显更热。这时候可以做二级拆分：先按租户分组，大租户单独成组再细分片，小租户合并共享分片。TDSQL这类产品一般支持在一级分片之上再配置子分片规则，用来处理这类长尾分布。

提示：上线前一定要拿真实业务数据跑一遍分布统计，看看每个分片的数据量和QPS偏差。我一般要求偏差控制在30%以内，超过这个数就要重新考虑分片策略。

3.3 全局唯一ID、跨片JOIN与二级索引的现实做法

全局唯一ID有三个主流方案。雪花算法依赖时钟，需要处理时钟回拨；号段模式性能好，但需要中心化分配服务；数据库自增序列最省心，但每次取号有网络开销。实践中我会根据业务对ID连续性的要求来选：订单号要求单调递增就用数据库序列，用户表主键要求唯一但不要求单调就用雪花。

跨片JOIN是分布式数据库最容易踩的坑。下面这条SQL如果订单表和商品表不在同一个分片：

引擎只能把商品表的数据拉到接入层再做关联，如果商品表很大，这次关联就会变成内存杀手。现实里通常有三种处理方式：把商品表设置成广播表（每个分片存一份全量），在订单表里冗余商品名称等少量字段，或者把关联拆到应用层用两次单分片查询拼装。我个人的偏好是优先冗余，把商品名称、类目这类不常变的字段直接写进订单快照，既解决了JOIN问题，也顺带解决了历史数据一致性问题。

二级索引要分清楚本地索引和全局索引。本地索引只在单个分片内有效，如果查询条件不含分片键，索引也用不上；全局索引由引擎维护，能支持非分片键的等值查询，但写入时需要额外维护一份索引数据，写放大明显。策略是：只给真正高频且必须的查询建全局索引，其余查询引导业务侧带上分片键。

4. 把存量业务搬上去：兼容性摸底与迁移演练

迁移这件事，我的态度一直是"当项目做，不当任务做"。我见过太多团队把迁移当成一次数据拷贝，结果切完发现存储过程报错、字符集乱码、自增主键冲突，凌晨三点在群里找人。

4.1 兼容性摸底清单

TDSQL MySQL版对MySQL协议和语法的兼容度很高，但分布式形态下确实有些限制。上线前我会跑一份自查清单：

检查项	常见问题	处理方式
存储过程与函数	跨分片调用不支持，逻辑可能失效	尽量把业务逻辑上移到应用层
触发器	分布式环境中行为不确定	迁移前全部下线，用应用层替代
外键约束	跨分片外键无法保证	改为应用层校验
跨库跨表查询	不同分片表之间的JOIN代价高	冗余字段或广播表
自增主键	分布式自增需要引擎配合	评估是否改成序列或雪花ID
字符集与排序规则	迁移后排序结果不一致	统一为utf8mb4，明确排序规则
大小写敏感	部分环境区分表名大小写	提前规范命名，全部小写
权限与账号模型	用户权限在多个节点上分别生效	用统一账号管理，避免逐节点授权

这份清单我一般会让开发和DBA各过一遍，开发关注SQL语法和业务逻辑，DBA关注参数、字符集、账号和备份策略。

4.2 双写、全量校验与回滚预案

正式切换之前，最少要跑一轮完整的演练，流程大致是这样：

1. 结构迁移：把源库的表结构、索引、账号导到目标实例，先确认DDL能执行成功。
2. 全量迁移：用数据同步工具把存量数据搬过去，大表按分片并行搬，控制好并发避免把源库压垮。
3. 增量追平：开启增量同步，让目标库持续跟随源库的变更。这一步要盯住延迟，延迟稳定在秒级以内才算追平。
4. 数据校验：全量比对用分片级checksum，抽样比对用行数加关键字段哈希。校验不通过的地方逐条追查，别放过"就几十行差异"这种说法，差异背后往往是类型转换或者编码问题。
5. 双写验证：让业务侧同时写源库和目标库，读走源库，观察一段时间内两边是否一致。这一步能暴露出增量同步覆盖不到的场景，比如某些批量任务、定时脚本。
6. 回滚预案：反向同步通道必须提前配好并测试过。切换失败时最怕的是"数据已经写进新库但回不去"，所以反向通道要和正向通道同时准备好。

4.3 切换窗口的操作顺序

切换那天最忌讳临场发挥，所有动作都应该提前写好，按秒表执行。我习惯的顺序是：

• 停写业务入口（或者切到只读降级页），记录停写时间点。
• 等增量同步把延迟追到零，确认源库和目标库的位点一致。
• 校验一次关键业务表的数据。
• 切换应用连接串，先切读流量，观察五分钟确认查询正常。
• 再切写流量，观察写入延迟和错误率。
• 保留反向同步通道至少48小时，确认无异常后再关闭。

注意：连接串切换一定要走配置中心或者启动参数，不要在线改代码。我见过一次事故就是因为切换时代码和配置不一致，一半实例连了新库，一半还连着旧库，写入了两份数据。

5. 上线之后的日常：执行计划、连接数与容量规划

迁移完成只是起点，分布式数据库的日常运维和单机完全不是一个套路。单机时代你可能一年都不会去看一次执行计划，分布式环境下这个习惯必须改。

5.1 看懂分布式执行计划

在单机上，EXPLAIN 告诉你用没用索引。在分布式环境下，你需要先确认的是这条SQL能不能下推。看下面这个例子：

这条SQL的条件里没有分片键，执行计划里会体现"下发到全部分片 -> 各分片局部聚合 -> 接入层归并排序"。分页查询更麻烦，LIMIT 10 OFFSET 10000 在每个分片都要取10010行再归并，深分页的性能会随偏移量线性下降。实践中我会把深分页改造成"游标翻页"，用上一页最后一条的排序字段做条件，避免大偏移。

另一个要盯的是返回数据量。跨分片查询如果返回几十万行，接入层的内存和网络都会成为瓶颈。看到执行计划里出现大规模数据拉取，第一反应应该是改SQL，而不是加内存。

5.2 连接池与后端连接数的水位

分布式架构里连接数要分两段看：前端连接（应用连接入层）和后端连接（接入层连存储节点）。前者可以很多，接入层本身就是为海量连接设计的；后者受限于每个存储节点的处理能力。

一个粗略的估算方式：假设应用有200个实例，每个实例的连接池上限20，那前端峰值是4000。接入层到后端通常会做连接复用，但如果每个分片节点配置的连接池上限是500，32个分片就是16000个后端连接的潜在上限——这个数字远超前端，说明配置用不上，实际瓶颈会在存储节点的CPU上。

真实的水位要这样看：活跃连接数而不是总连接数。我一般会盯 Threads_running 这个指标，如果它长期接近节点的CPU核数，说明是计算瓶颈；如果活跃连接很低但响应变慢，那瓶颈很可能在磁盘IO或者锁等待上。

5.3 扩容、备份与恢复演练

扩容在分片形态下分两种：加资源（提升现有节点规格）和加分片（增加SET数量）。前者通常需要短暂的主从切换，后者涉及数据重分布，工作量更大。我的经验是别等到水位到80%才动手，留出30%以上的余量，把扩容变成计划内的操作。

容量估算有个简单的算式可以参考。假设订单表3亿行、单行平均300字节，原始数据约90GB，加上索引和事务日志，实际占用按1.6倍算大概145GB。分32片，每片不到5GB，非常轻松。日增100万行，每天新增原始数据约300MB，一年也就100GB出头。把这份账算清楚，扩容节奏自然就出来了。

备份恢复这块，重点是别只验证备份成功，要验证能恢复。我参与的每个项目都会做恢复演练：从备份里恢复出一个新实例，跑一遍关键业务的查询，对比数据。演练频率至少每季度一次。很多人只盯着"备份任务状态成功"，但真正出事的时候才发现备份文件恢复不回来，这种情况在真实事故里占比不低。

6. 成本这笔账怎么算：什么时候值得上分布式

最后说一个很现实的问题：分布式数据库比单机贵，而且贵得不是一星半点。它贵在节点数量、贵在运维复杂度、贵在人。所以选型的时候要把这三笔账都算进去，而不是只看实例单价。

6.1 三种方案的成本对照

方案	资源成本	人力成本	扩展上限	适用阶段
单机高规格 + 只读实例	低	低，现有DBA就能维护	受单机硬件上限约束	数据量千万级、QPS数千
云原生形态（计算存储分离）	中	低，扩容是控制台操作	单实例规格上限较高，只读可快速扩展	数据量亿级以内、读多写少
分片形态（分布式）	高	高，需要懂分片设计的人	理论上线性扩展	数据持续增长、写入压力大

举个具体的对比：单机8核64G加两个只读实例的方案，可能只占分片方案成本的三分之一，但它能撑到什么时候？如果当前数据量是5000万行、日增30万行，按这个速度三年后也就4亿行，单表4亿行在合理索引下并非不能跑。真正逼你上分片的，往往是写入QPS而不是数据量。

6.2 我的选型判断顺序

我一般按这个顺序问自己几个问题，问完基本就有答案了：

1. 写入QPS峰值是多少？ 低于5000，多半不需要分片，读写分离加缓存能解决。
2. 最大的表三年后会有多少行？ 低于2亿且增长平稳，先考虑分区表和归档，别急着分片。
3. 高频查询能不能收敛到一个分片键上？ 不能，那分布式的好处会被广播查询吃掉一大半。
4. 团队有没有人能长期维护分片规则？ 没有，那就选托管程度更高、分片规则更简单的形态，或者干脆用云原生单实例。
5. 业务能否接受更高的写入延迟？ 跨分片事务的延迟是物理限制，不是调优能绕过去的。

实际做过的几个项目里，我印象最深的是一次"反向决策"：一个团队原本已经规划好了分片方案，评审时我们重新统计了写入分布，发现95%的流量集中在最近7天的数据上，历史数据基本只读。最后改成热数据留在高规格主库、冷数据按月归档到只读实例，成本降了六成，性能还更好。分布式是一个强有力的工具，但它的正确使用方式，是先证明自己真的需要它。

如果你现在正卡在"要不要上分布式"这个决策上，我的建议是先做两件事：把未来两年的数据增长和QPS增长画成曲线，再把所有慢查询按是否包含候选分片键分个类。这两件事做完，答案通常就摆在桌面上了。