TDSQL 分布式数据库

01 它是干嘛的

TDSQL 是面向海量数据与高并发的分布式关系型数据库，兼容 MySQL 协议，在腾讯内部长期支撑支付等核心业务。它解决的是「单台数据库的容量与性能存在天花板」这个硬问题：把数据横向拆分到多个节点，用多副本保证高可用与强一致，而对应用来说，连接方式与普通 MySQL 几乎没有区别。

02 为什么会有它

当一张表有几十亿行，你就知道单台数据库的极限在哪了

所有关系型数据库最初都跑在一台机器上：数据存在这台机器的磁盘里，查询也由它执行。数据量小的时候一切顺利，但当一张表涨到几亿、几十亿行，麻烦就来了——磁盘塞不下、查询越来越慢，而你想给这台机器加 CPU、加内存、换更快的磁盘，都是有物理上限的。

业界的传统解法是「分库分表」：程序员自己按用户编号，把一张大表手动拆成几十张小表，分别放在不同的数据库里。这套办法能撑住业务，但成本极高——应用代码里到处是路由逻辑，扩容时要人工搬数据，一旦拆错几乎无法回头，出了问题排查也像在迷宫里找路。

TDSQL 的思路是把这件事交给数据库自己去做：你照常写建表和查询的语句，数据按分片键自动被分散到多个节点，查询时由数据库负责路由、汇总与合并。对应用来说它仍然像一台普通的 MySQL，但它背后是一整个集群，容量和性能都能通过加节点继续往上走。

03 它怎么工作

核心是三件事：按分片键把数据水平拆到多个节点、每个节点保留多份副本保证不丢、再靠一致性协议让多份副本随时保持同步。

看图时盯住两样东西：一是数据被按分片键切到多个节点（横向扩展的根源），二是每个分片都拖着若干副本（高可用的根源）。只要这两条成立，容量和可靠性就能同时随节点数增长，而不是彼此牺牲。

数据是怎么被分散到多台机器、又保证不丢的

1
① 按分片键拆分数据
建表时指定一个分片键（例如用户编号），数据会按照某种规则分散到不同的分片节点上，单个节点只承担总数据量的一部分。
2
② 查询自动路由与合并
应用发出普通的 SQL，调度层先判断这条查询会落在哪些分片，再把请求分发过去，并把各分片的结果汇总后再返回。
3
③ 多副本保证不丢数据
每份数据同时保存多个副本、分布在不同的机器上，某一台突然宕机，其他副本仍在，服务不会因此中断。
4
④ 一致性协议维持副本同步
写入时通过多数派确认等机制，保证多份副本改的是同一份事实，避免出现「不同机器读到不同结果」。
5
⑤ 在线扩容与自动重平衡
容量不足时增加节点，数据库会把一部分数据在线搬到新节点上，扩容过程应用基本无感，不需要人工停机搬库。

04 谁在用它

金融与支付类核心业务

账户、账单、交易流水等要求数据不丢、不错、可对账的场景，分布式数据库的多副本与强一致是刚需。

海量数据的互联网业务

用户量上亿、日增数据量巨大的应用，单台数据库早已装不下，必须靠横向扩展来消化。

高并发写入场景

订单、日志、消息类写入密集的业务，写入压力被分散到多个节点，不再挤在一台机器上排队。

要求在线平滑扩容的系统

业务增长快、需要不断加容量却又不能停机的系统，分布式数据库能在线扩容而不中断服务。

从单机 MySQL 迁移上来的存量系统

兼容 MySQL 协议意味着应用改动小，是原有单机数据库遇到瓶颈时比较平滑的一条升级路径。

05 怎么用

对应用开发者而言，用起来和普通 MySQL 差别不大，难点主要在建库建表时如何选择分片键。

01在控制台购买一个分布式数据库实例，选择地域、规格与副本数量。
02创建数据库与账号，配置好允许访问的网络（通常是私有网络的 IP 段）。
03设计表结构时先确定分片键，挑选分布均匀、查询时最常带上的字段，例如用户编号。
04用任意 MySQL 客户端或驱动连接实例，像用普通 MySQL 一样建表、写查询。
05把应用的数据源地址指向这个实例，测试读写是否正常，再逐步把流量切换过来。
06上线后关注慢查询与分片分布是否均匀，必要时调整分片策略或增加节点。

连接分布式实例并按分片键建表sql

-- 用普通 MySQL 客户端连接（对应用而言就像连一个普通 MySQL）
-- mysql -h <TDSQL实例地址> -P <端口> -u <用户> -p

-- 建表时指定分片键（shardkey），数据会按键被分散到多个分片
CREATE TABLE orders (
  order_id   BIGINT        NOT NULL,
  user_id    BIGINT        NOT NULL,
  amount     DECIMAL(10,2) NOT NULL,
  created_at DATETIME      NOT NULL,
  PRIMARY KEY (order_id),
  KEY idx_user (user_id)
) ENGINE=InnoDB;

-- 查询照常写，路由与结果合并由分布式数据库完成
SELECT user_id, SUM(amount) FROM orders WHERE user_id = 1001;

避坑提示

!分片键一旦选定就很难更改，务必挑那些「分布均匀、且查询最常作为条件带上」的字段，选错会导致数据倾斜到一个节点上。
!不要指望它能替代所有场景：数据量不大的业务用普通关系型数据库更简单便宜，分布式数据库的复杂度只有在真正遇到瓶颈时才值得付出。
!跨分片的复杂查询与事务开销更大，设计时尽量让高频操作能落到单个分片内完成。

06 关键概念

分片（Sharding）: 把一大份数据按规则切成很多小份，分别放在不同机器上，合起来仍是完整的数据。
分片键: 决定一条数据该放进哪个分片的字段，类似按姓氏把通讯录分成若干本。
副本与强一致: 同一份数据存多份以防丢失；强一致指所有副本对外呈现的结果相同，不会出现读到旧值。
水平扩展: 通过增加机器数量提升整体能力，而不是只给单台机器升级配置。

07 容易混淆的对比

单机 MySQL + 手动分库分表成本低、可控，但扩容与维护都靠人力，代码侵入大，规模一大就难以为继。

云上托管的关系型数据库运维简单、价格更低，适合绝大多数中小规模业务；只有数据量与并发真正压到单机极限时，才需要分布式数据库。