腾讯云国际版分布式数据库TDSQL实战：分片表设计、读写分离与真实单价成本测算（2026最新）
Meta Description: 腾讯云国际版TDSQL for MySQL（DCDB）分布式数据库完整实战教程：分片表/广播表/单表三种建表方案怎么选、shardkey分片键设计原则、TProxy读写分离三种配置、真实节点单价与包年包月/按量计费算例、规格选型性能表与5条成本优化建议。
> 关键词：腾讯云国际版 TDSQL、分布式数据库、分库分表、DCDB、TProxy、shardkey、读写分离、TDSQL 价格
前言
一句话答案：当单机 MySQL 的容量或并发顶到天花板时，腾讯云国际版的 TDSQL for MySQL 是"业务代码基本不用改、却能水平扩展"的那条路——它用一个兼容 MySQL 协议的代理层（TProxy）把 N 个分片伪装成一台逻辑库，扩容时只需在控制台加分片，连接地址不变，业务侧最多重连一次。
但绝大多数"分库分表"文章只讲概念不讲师法，结果读者买完实例才发现三个坑：分片键（shardkey）选错了没法改、广播表忘了配导致 JOIN 全表扫描、只按 QPS 估规格但磁盘容量先爆。这篇把腾讯云国际站官方文档里的真实单价、真实 sysbench 压测表、真实的建表方案差异全部拉出来，按"概念 → 建库 → 分片键 → 规格 → 账单"的顺序走一遍，并在最后给出可直接抄的成本测算公式。
> 声明：本文价格数据采集于 2026 年 9 月，取自腾讯云国际站官方文档公开单价，仅作参考；产品定价、可用区与活动随时可能调整，请以腾讯云官网实时价格为准。除特别标注外，金额单位均为美元（USD）。
一、先搞清楚：TDSQL 和 TencentDB for MySQL 不是一回事
很多人第一次在国际站搜"腾讯云分布式数据库"会迷路，因为国际站的产品命名和国内站并不完全对齐：
| 项目 | TencentDB for MySQL | TDSQL for MySQL（DCDB） | |------|---------------------|--------------------------| | 架构 | 单机主从（一主一/二备） | 分布式：多分片 × 每分片主从 | | 扩展方式 | 纵向升配（CPU/内存/磁盘） | 纵向升配 + 横向加分片 | | 单实例容量上限 | 受单机磁盘限制 | 单分片最高约 6 TB，分片数可叠加 | | 跨节点事务 | 不涉及 | 支持两阶段提交（2PC），需 MySQL 5.7 | | 对应用的形态 | 标准 MySQL 连接 | 通过 TProxy 连接，仍是 MySQL 协议 | | 典型场景 | 中小业务、常规 OLTP | 单表破亿、分库分表改造、强一致交易 |
结论很简单：数据量在千万行以内、单表不超过 50 GB，用普通 TencentDB for MySQL 就够了，别为分布式多付管理成本；一旦出现"单表 2000 万行以上、磁盘不够升、或写入 QPS 单机扛不住"，才轮到 TDSQL 上场。
国际站上还有两个容易混的入口：intl.cloud.tencent.com/products/tdsql 指向的是 TencentDB for MariaDB（主打默认读写分离），而 intl.cloud.tencent.com/products/dcdb 才是本文主角 TDSQL for MySQL。按网址判断产品，别按名字猜。
二、核心概念：分片、节点、TProxy 到底各管什么
在控制台上买 TDSQL，你填的其实是一个"乘法算式"里的几个因子。先把名词对齐：
| 概念 | 含义 | 对成本/性能的影响 | |------|------|-------------------| | 分片（Shard） | 水平切分的一个逻辑数据单元，每个分片是一套独立的主从 | 分片数 × 每分片规格 = 实例总算力，分片数直接乘以账单 | | 节点（Node） | 分片内部的单个实例，一主一从 = 2 个节点 | 计费公式里节点数就是"1 主 + N 备"的总和 | | TProxy | 腾讯自研的数据库代理层，对外暴露统一接入地址 | 业务只连它，分片扩容/主从切换对业务透明 | | shardkey | 分片键，决定一行数据落在哪个分片 | 选错几乎无法在线修改，是全篇最重要的决策 | | 广播表 / 单表 | 不分片的表类型 | 广播表保证 JOIN 收敛到单节点，显著影响性能 |
官方给出的算力公式值得抄在便签上：
`text
实例读并发性能 = ∑ (某规格分片的性能 × 分片数)
实例事务性能 = ∑ (某规格分片的事务性能 × 70% × 分片数)
`
那个 70% 就是分布式事务的代价——跨分片两阶段提交（2PC）会吃掉约三成性能。官方文档明确写到：跨节点事务性能约为单节点的 70%，但比开源 XA 协议约高 56%，且该能力目前仅 MySQL 5.7 内核支持。如果你的业务全是跨分片事务，分布式反而可能比单机更慢，这是选型时最容易忽略的反直觉点。
三、三种建表方案：分片表、广播表、单表别搞混
TDSQL 不是"把所有表都切了"，而是让你对每张表单独指定切分策略。三种方案的差异如下：
| 建表类型 | 数据分布 | 适用场景 | 使用注意 | |----------|----------|----------|----------| | 分片表（Sharded） | 按 shardkey 水平切到各分片 | 超过 2000 万行 / 50 GB 的大表 | 必须带 shardkey 才能路由到单分片 | | 广播表（Broadcast） | 每个分片保存全量副本 | 配置表、字典表、需频繁 JOIN 的小表 | 每分片一份，写放大 × 分片数，不宜过大 | | 单表（Single） | 不切分，整表落一个分片 | 数据量小的表，完全兼容 MySQL | 与分片表 JOIN 时可能跨节点拉数据 |
官方的经验值写得很直白：单分片建议至少存 5000 万行再考虑切，切得太碎反而让跨分片 JOIN 变多。而"广播表"存在的唯一理由就是把 JOIN 收敛到单节点——当两张表有 shardkey 等值条件时，TDSQL 会依据分片一致性原则把相关数据自动落到同一物理节点，此时 JOIN 等价于单机 JOIN，性能最好；一旦跨物理节点，代理需要先拉取并缓存远端数据，性能迅速劣化。
还有一个实用细节：单表是对 MySQL 完全兼容的。如果你的业务里有一批小表，最省事的做法就是把它们全部建成单表，只把真正的大表切成分片表，这样可以大幅降低改造成本。
四、实操第一步：在控制台创建 TDSQL 实例
官方"Creating Instance"文档的操作路径，浓缩成六个决策点：
4.1 计费模式
- 包年包月（Monthly subscription）：预付费，创建即扣费，单价低于按量，且购买时长越长越省。适合长期稳定业务。 - 按量计费（Pay-as-you-go）：后付费，按实际用量结算，用完可立即释放。适合流量波动大的业务。
注意按量计费的内存单价是三段阶梯价，用满越久单价越低：
| 使用时长 | 适用档位 | |----------|----------| | 0 < 时长 ≤ 96 小时 | 第一档（最贵） | | 96 < 时长 ≤ 360 小时 | 第二档 | | 时长 > 360 小时 | 第三档（最便宜） |
所以"临时跑个长压测"的成本曲线是前陡后缓的，短时任务别按小时单价线性外推。
4.2 必选参数清单
| 参数 | 建议值 | 说明 | |------|--------|------| | 地域 Region | 与 CVM 同地域 | 不同地域内网不通，购买后不可修改 | | 网络 VPC | 与 CVM 同 VPC | 否则只能走公网，延迟与流量成本都上升 | | 主可用区 / 备可用区 | 选不同 AZ | 主备跨 AZ，抵御单机房故障 | | 内核版本 | MySQL 5.7 | 5.6 内核不支持分布式事务（XA），需要 2PC 必须选 5.7 | | 字符集 | UTF8MB4 | 支持 UTF8 / LATIN1 / GBK / UTF8MB4 / GB18030 | | 表名大小写 | 按业务规范，一旦初始化不可改 | lower_case_table_names 只能在初始化时设定 | | 强同步 | 强同步（可降级）或异步 | 强同步保证主从一致性，异步性能更好 | | 安全组 | 只放行 CVM 内网段 | 数据库不应暴露公网 |
4.3 分片规格与数量
官方推荐的三档起步配置（可直接照抄）：
| 业务阶段 | 建议配置 | |----------|----------| | 功能测试、无性能要求 | 2 个分片，每分片 2 GB 内存 + 25 GB 磁盘 | | 业务初期、数据量小但增长快 | 2 个分片，每分片 16 GB 内存 + 200 GB 磁盘 | | 稳定发展期、已明确分片逻辑 | 4 个分片，每分片规格 = 当前峰值 × 增长率 ÷ 4 |
节点规格（High IO 型）从 1 核 2 GB 一直到 32 核 128 GB 共八档：1C2G、2C4G、4C8G、6C16G、8C32G、16C64G、24C96G、32C128G。
付款后回到实例列表，状态变为 Running 即可使用。
五、实操第二步：连接实例与建库建表
实例创建完成后，在控制台"实例详情"页可以拿到内网/外网接入地址，这个地址指向的就是 TProxy。连接方式与普通 MySQL 完全一致：
`bash
// 从同 VPC 的 CVM 上连接（推荐：内网低延迟且流量免费）
mysql -h 10.0.x.x -P 3306 -u tdsql_user -p
// 需要从公网连接时，先在控制台把外网地址打开，并务必收紧安全组
mysql -h 43.xxx.xxx.xxx -P 3306 -u tdsql_user -p
`
建库与普通 MySQL 一样：
`sql
CREATE DATABASE shop DEFAULT CHARACTER SET utf8mb4;
USE shop;
`
重点在建表。以下三种写法分别对应上一节的三种表类型：
`sql
-- 分片表：按 user_id 切分，必须显式指定 shardkey
CREATE TABLE orders (
order_id BIGINT NOT NULL,
user_id BIGINT NOT NULL,
amount DECIMAL(12,2),
created_at DATETIME,
PRIMARY KEY (order_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
shardkey=user_id;
-- 广播表：每个分片保存全量，适合配置/字典表 CREATE TABLE dict_region ( region_id INT PRIMARY KEY, region_name VARCHAR(64) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 broadcast;
-- 单表：不切分，整表落在某个分片，完全兼容 MySQL 语法
CREATE TABLE sys_notice (
id INT PRIMARY KEY AUTO_INCREMENT,
content VARCHAR(255)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
single;
`
建完表不要急着灌数据。先在控制台上看一眼分片分布，确认数据确实被打散了，而不是全压在一个分片上——这是分片键选错时最早能暴露问题的信号。
六、读写分离：三种方案，选一种就够
TDSQL 默认支持读写分离，主从架构下每个从库都可设为只读，读请求由 TProxy 自动分配到负载较低的从库。官方提供了三种落地方式：
| 方案 | 做法 | 适用场景 |
|------|------|----------|
| 只读账号 | 创建一个只读权限的账号，读请求走它 | 改造最小，推荐首选 |
| SQL 注释 /slave/ | 在语句前加注释强制走从库 | 单条 SQL 级别的精细控制 |
| 只读实例 | 单独购买"容灾只读实例" | 需要独立容灾备份、读流量很大的场景 |
实践建议：先用只读账号把 80% 的报表/列表查询分流出去，剩下那 20% 有强一致要求的（下单后立即查订单状态）继续走主库。切忌为了"读写分离"而把所有读都打到从库——主从复制有延迟，用户刚下单就查不到会变成客诉。
七、分片键（shardkey）怎么选：全篇最重要的一节
分片键一旦选定，在线修改的代价极高，所以购买实例之前就要想清楚。四条判断标准：
1. 高频查询条件里必须带它。分片表只有带上 shardkey 才能路由到单一分片；不带 shardkey 的查询会被广播到所有分片，性能随分片数线性劣化。
2. 离散度要高。优先选用户 ID、订单 ID 这类基数大的字段；选"状态""地区"这种低基数字段，会立刻出现数据倾斜（某个分片特别大）。
3. 尽量与事务边界一致。同一个事务里操作的行最好落在同一分片，这样才能避免跨节点 2PC 的 70% 性能折损。比如订单与订单明细都用 user_id 做 shardkey，同一用户的订单和明细就天然同分片。
4. 不选会变化的字段。分片键本身若被更新，意味着数据要跨分片搬迁，代价极大。
一句话口诀：用在 WHERE 里最多、基数最大、且事务内不跨的那一列。
八、规格怎么估：拿官方 sysbench 数据反推
官方公开了一组基准测试数据（改造自 sysbench 0.5 的 oltp 脚本，读写比 4:1，单客户端并发 128），这组数字比任何"经验值"都可靠，因为它是单分片、单节点的真实吞吐：
| 内存 | 存储容量 | 数据集 | 客户端数 | 并发 | QPS | TPS | |------|----------|--------|----------|------|-----|-----| | 2 GB | 100 GB | 46 GB | 1 | 128 | 1,880 | 351 | | 4 GB | 200 GB | 76 GB | 1 | 128 | 3,983 | 797 | | 8 GB | 200 GB | 142 GB | 1 | 128 | 6,151 | 1,210 | | 16 GB | 400 GB | 238 GB | 1 | 128 | 10,098 | 2,119 | | 32 GB | 700 GB | 238 GB | 2 | 128 | 20,125 | 3,549 | | 64 GB | 1 TB | 378 GB | 2 | 128 | 37,956 | 7,002 | | 96 GB | 1.5 TB | 378 GB | 3 | 128 | 51,026 | 10,591 | | 120 GB | 2 TB | 378 GB | 3 | 128 | 81,050 | 15,013 | | 240 GB | 3 TB | 567 GB | 4 | 128 | 96,891 | 17,698 | | 480 GB | 6 TB | 567 GB | 6 | 128 | 140,256 | 26,599 |
读这张表有三个要点：
- 数据集大小比内存大时，性能增长会明显放缓（2 GB 内存跑 46 GB 数据集只有 1,880 QPS）。所以内存配置的第一约束不是"并发"，而是"热点数据集能不能装进内存"。 - QPS 随内存增长不是线性的，但接近线性（4 GB→8 GB 约 1.5 倍，8 GB→16 GB 约 1.6 倍）。这说明纵向升配的性价比在中段最好。 - 官方特别提示：TDSQL 采取了空闲资源超用策略，监控面板上 CPU 利用率可能超过 100%，这是正常现象，不要误判为故障。
换算方式：总吞吐 ≈ 单分片 QPS × 分片数。理论上 4 个 16 GB 分片约等于 4 × 10,098 ≈ 40,000 QPS。
九、价格：包年包月 vs 按量计费的真实单价
TDSQL 的计费口径官方写得非常清楚，计费公式如下：
`text
实例费用 = 节点单价 × 节点数 × 分片数
= (节点内存GB × 内存单价 + 节点磁盘GB × 磁盘单价) × 节点数 × 分片数
`
其中"节点数"是下单规格里主库和从库之和（一主一从 = 2 节点）。套餐外还包含：备份空间（赠送等量实例容量，超出部分计费）、公网流量（当前免费）、数据库审计（当前公测免费）。
9.1 包年包月单价（单节点，USD）
| 地域 | 内存单价（USD/GB/月） | 磁盘单价（USD/GB/月） | |------|----------------------|----------------------| | 广州 / 北京 / 上海 / 深圳 / 南京 | 9.43 | 0.06 | | 成都 / 重庆 | 9.43 | 0.06 | | 香港（中国） | 12.39 | 0.085 | | 弗吉尼亚 / 法兰克福 / 硅谷 | 8.00 | 0.07 | | 新加坡 | 12.68 | 0.085 | | 首尔 / 东京 | 10.00 | 0.11 | | 雅加达 | 12.68 | 0.085 |
9.2 按量计费单价（单节点，USD/GB/小时）
| 地域 | 第一档 | 第二档 | 第三档 | 磁盘单价 | |------|--------|--------|--------|----------| | 广州 / 北京 / 上海 / 深圳 / 南京 | 0.02619 | 0.01965 | 0.01310 | 0.00025 | | 香港（中国） | 0.03442 | 0.02582 | 0.01721 | 0.00012 | | 弗吉尼亚 / 法兰克福 / 硅谷 | 0.02222 | 0.01667 | 0.01111 | 0.00010 | | 首尔 / 东京 | 0.02778 | 0.02083 | 0.01389 | 0.00015 | | 新加坡 / 雅加达 | 0.03523 | 0.02642 | 0.01761 | 0.00012 |
9.3 官方算例：同一台实例，两种计费差多少
包年包月算例：广州地域，2 个分片，每分片 2 节点（一主一从），每节点 2 GB 内存 + 500 GB 磁盘，购买 1 个月。
`text
实例费用 = (2 GB × 9.43 + 500 GB × 0.06) × 2 节点 × 2 分片 × 1 月
= (18.86 + 30.00) × 4
= 195.44 USD
`
按量计费算例：北京地域，同样的 2 分片 × 2 节点 × (2 GB + 500 GB)，合计使用 400 小时。内存单价按使用时长分三段：
`text
第一档（前 96 小时） = (2 × 0.02619 + 500 × 0.00025) × 4 × 96 = 68.11 USD
第二档（96–360 小时） = (2 × 0.01965 + 500 × 0.00025) × 4 × 264 = 173.50 USD
第三档（360 小时以后）= (2 × 0.01310 + 500 × 0.00025) × 4 × 40 = 24.19 USD
合计 = 68.11 + 173.50 + 24.19 = 265.80 USD
`
结论：同样配置跑满一个月（约 720 小时），按量计费要 265.80 USD，包年包月只要 195.44 USD，包年包月便宜约 26%，且购买时长越长折扣越大。所以"业务已经确定长期跑"的实例没有任何理由开按量计费。
还有两个容易被忽略的成本项：
- 磁盘单价差异极大：内存单价各地域相差约 1.6 倍（8.00 → 12.68），但磁盘单价相差可达 2.5 倍（0.06 → 0.11）。如果你的业务是"小内存 + 大磁盘"型（比如冷数据归档库），地域选择对账单的影响会比想象中更大。 - 公网流量当前免费，但不要把这句话当成架构建议——生产环境数据库应当始终走内网，公网地址只用于临时运维。
十、容灾：跨 AZ 与容灾只读实例
TDSQL 的容灾能力分三层，按预算从低到高：
1. 分片内主从 + 跨 AZ 部署：主备放在同城不同可用区，通过内网实时复制。本地节点故障时，TProxy 自动切换，VIP 保持不变，应用层几乎无感（前提是业务有重连机制）。 2. 跨可用区容灾：主从部署在同城不同 AZ，本地为主、远端为备，访问时优先本地，不可达时切远端。 3. 金融级容灾：支持"两地三中心"或"同城两中心"部署架构，故障后可在数分钟内恢复。
此外还可以单独购买容灾只读实例，它既分担读流量、又充当独立的数据副本。值得注意的自动化能力是：当承载分片的物理节点故障时，调度系统会自动重试恢复；若原节点无法恢复，会在 30 分钟内自动申请新资源、从备份重建节点并自动加入集群，以保证分片主从切换能力长期有效。
十一、五条成本优化建议
1. 先做减量，再做分布式。把历史数据归档到 COS、把日志表拆出去，往往比直接买 TDSQL 便宜一个数量级。分布式是最后手段，不是第一选择。 2. 别把分片数开太多。官方明确建议"单分片高规格、分片总数少"，因为分片数直接乘以账单，而跨分片查询的代价也随分片数上升。 3. 长期业务一律转包年包月。上面的算例已经证明同配置差价 26%，且时长越长越省。 4. 开发测试环境用小规格 + 用完即弃。功能测试用 2 分片 × 2 GB 内存即可，测试完直接释放，不要留在账上。 5. 磁盘按一年增长预估、内存按六个月峰值预估。这是官方给出的两个不同时间窗，很多人会统一按"当前用量"下单，结果半年后又要升配。
十二、常见问题 FAQ
Q1：TDSQL 和自己在 CVM 上搭 MySQL 分库分表中间件（如 ShardingSphere）比，怎么选？
自建中间件的优势是完全可控、无产品锁定；代价是你要自己扛代理层的高可用、扩容时的数据迁移、主从切换的一致性问题。TDSQL 把这三件事做成了控制台里的按钮，代价是分片键设计等规则受产品约束（比如在线改分片键很困难）。团队里没有专职 DBA 时，托管方案的综合成本通常更低。
Q2：我的业务有大量跨分片事务，还适合用 TDSQL 吗？
要慎重。官方数据是跨节点事务性能约为单节点的 70%，也就是说跨分片事务越密集，分布式的收益越被抵消。正确的做法是重新设计 shardkey 让事务落在单分片内（例如订单与明细同用 user_id 分片）；如果业务模型天然无法做到，单机高配 MySQL 可能才是更优解。
Q3：分片键选错了可以改吗？
生产环境基本等于"改不了"。分片键决定了每一行数据的物理归属，换键意味着全量数据跨分片搬迁。所以务必在购买前用第 7 节的四条标准验证，最稳妥的是先在测试实例上灌入接近生产规模的数据跑一轮。
Q4：为什么监控面板上 CPU 利用率会超过 100%？
这是官方已知并说明的行为：TDSQL 对空闲资源采取超用策略，因此 CPU 利用率超过 100% 属于正常现象，不代表实例异常。判断实例健康应看 QPS/TPS、慢查询、主从延迟等指标。
Q5：备份要不要额外花钱？
赠送与实例容量等量的备份空间，超出部分才按量计费。备份空间主要存放 binlog、错误日志、慢日志和备份文件。日常备份按"日增量 × 保留天数"估算容量，超出赠送额度就该考虑缩短保留期或转存到 COS。
Q6：按量计费真的比包年包月划算吗？
只有在"短期、可随时释放"的场景才划算。从本文算例看，跑满一个月按量比包年包月贵约 26%；但如果你只是做三天迁移验证，按量计费可以避免包月的最低消费。阶梯价的意义正在于此——用得越久单价越低，但仍然追不上包年包月。
十三、总结与推荐方案
给三类读者直接给结论：
- 单表 5000 万行以内、预算有限：用 TencentDB for MySQL，不要碰 TDSQL。相关选型与连接实操可参考 腾讯云国际版TencentDB数据库实战：MySQL/Redis选型、创建连接与高可用迁移完整教程。 - 单表破亿或写入 QPS 单机顶不住：上 TDSQL for MySQL，内核选 5.7（要分布式事务），先按"2 分片 × 16 GB × 200 GB"起步，shardkey 用 user_id 这类高基数、事务内不跨字段。 - 要跨地域容灾：在跨 AZ 主从之外，再评估容灾只读实例与 COS 跨区域复制组合，架构思路可参考 腾讯云国际版COS跨区域复制与容灾实战。
一句话记住全篇：TDSQL 的收益来自"分片数 × 单分片规格"，风险来自"分片键选错"和"跨分片事务"，成本则必须在买之前用计费公式算一遍——而不是买完之后看账单。
> 🚀 需要海外云服务器搭建数据库或业务系统？通过 4.chengzicloud.cloud 访问首页，获取国际版选购与部署的完整方案。
> 本文由 4.chengzicloud.cloud 提供，点击访问首页了解更多