◈ DB 选型参考
← 返回首页

腾讯云 TDSQL

关系型 OLTP #分布式 #云原生 #存算分离 #金融级高可用 #MySQL兼容 #PG兼容 #Oracle兼容 #HTAP #Serverless #国密 #信创 #腾讯云锁定

腾讯云的企业级数据库**产品家族**：以金融级分布式 OLTP 起家（TDSQL for MySQL），逐步长出云原生 Serverless（TDSQL-C）、PG/Oracle 双模兼容（TDSQL for PostgreSQL）、HTAP 与多模态新引擎（TDSQL Boundless）——"在腾讯云上用数据库"的完整答案，但每个答案都深度绑定腾讯云。

用 AI 深挖这款：
证据等级：官方文档 厂商口径 社区实测 社区共识 待验证

基本信息

项内容
厂商腾讯云（中国）
起源2007 年腾讯内部立项（支撑 QQ 计费、微信支付等业务），2012 年正式命名 TDSQL；2014 年微众银行核心系统首次商业化落地；2015 年在腾讯云正式商用；2020-12 原 DCDB / TBase / CynosDB 三大产品线统一品牌为 TDSQL 系列
许可证闭源商业（全家族）；例外：TDSQL for PostgreSQL 的社区发行版 OpenTenBase 已于 2023-12 捐赠给开放原子开源基金会
托管服务腾讯云公有云（全形态）；金融版支持私有化/专有云（TCE）部署
主类型关系型（分布式 OLTP / 云原生存算分离）
兼具类型HTAP（TDSQL-H、PG 版行列混存、Boundless）、多模态（Boundless 2026-03 起：结构化 + JSON + 全文检索 + 向量检索）

硬维度（47 项）

1 静态加密 / TDE 有

有官方文档。支持表空间透明加密与字段级加密；密钥默认对接腾讯云 KMS（密钥不落库），无 KMS 场景可用内置密钥环；支持国密 SM2/SM3/SM4（厂商口径：国密为增值组件，默认未配置）。版本限定：官方白皮书口径为"专有云及 MySQL 5.7 或更高版本内核"。

2 TLS / 传输加密 有

有官方文档。控制台支持 HTTPS；数据库连接支持 SSL 加密（默认 TLS 1.2 以上）；组件间内部通讯同样基于 SSL 加密。

3 审计 有

有官方文档。SQL 审计记录执行的 SQL（含来源 IP、用户、耗时、结果），需单独计费；另有数据脱敏（手机号/身份证/邮箱等字段规则）、SQL 防火墙（语法解析过滤非法 SQL，需配合 WAF 使用，暂未预存规则）；三层面审计体系：赤兔运维系统操作日志 / 数据库 SQL 审计 / 服务器铁将军审计。金融定制版审计日志默认存储 15 天，操作日志默认 60 天+归档 1 年。

4 认证与权限 有

有官方文档。数据库账号权限细到列级（19 种常见权限）；控制台账号管理不支持命令行 INSERT INTO mysql.user / GRANT 创建账号（出于安全考虑锁定）；管控侧支持三权分立（系统管理员/安全管理员/审计管理员）；平台侧通过 CAM（访问管理）+ 安全组 + VPC 做网络与身份隔离；账号防爆破、密码自动过期、错误密码锁定等策略。

5 备份恢复 有

有官方文档。TDSQL for MySQL 分布式版：物理备份（xtrabackup）+ binlog 增量，备库执行备份、主库压力小；默认备份保留 7 天，金融定制版最长可配 3650 天（需工单）。TDSQL-C：基于写时重定向（ROW）的秒级快照备份（元数据操作，与数据量几乎无关）+ 快照增量，支持控制台一键 PITR、库表级回档（原集群或新集群）、redo log 回档（关闭 binlog 可获厂商口径 30%+ 写性能提升）。

6 可观测性 有

有官方文档。DBbrain 智能管家（慢 SQL 根因分析、索引推荐、空间分析、实时活跃会话/TopSQL、异常诊断、参数优化），对 TDSQL MySQL 系全形态开箱即用；赤兔运维管理平台；扁鹊智能运维（厂商口径：200+ 指标毫秒级监控、AI 索引优化）。监控采样粒度：标准版默认 5 分钟/次，金融定制版 1 分钟/次。

7 连接模型 有，Proxy 网关 + 线程池

有，Proxy 网关 + 线程池（官方文档 + 社区实测）。分布式版应用经 VIP 连接无状态 Proxy 集群（SQL 解析/路由/读写分离/跨分片聚合），Proxy 按连接数横向加节点；内核有线程池与热点更新优化。注意：max_connections、innodb_buffer_pool_size 等核心参数受实例规格限定，极端调优诉求受云托管约束（可通过客户经理定制，社区共识）。

8 事务与隔离级别 有

有官方文档：继承引擎语义 + 分布式增强。单机语义继承 MySQL InnoDB（默认 REPEATABLE READ）。分布式版：经典 InnoDB 引擎走改造过的 XA 两阶段提交（厂商口径性能影响约 20%）；TDStore 引擎走协商式 2PC（协调者下沉）；全局一致性读通过 MC（轻量级 GTM）分配全局时间戳 GTS + 全局 MVCC 实现，对应用透明。

9 复制与一致性 有，架构核心

有，架构核心官方文档。TDSQL for MySQL：MAR 强同步协议（一主多备强同步，RPO=0）；TDStore：Multi-Raft（每分片三副本）；TDSQL-C：存储层块级三副本强一致，计算节点只写 redo log。故障切换：心跳超时 10s 判定故障 + 管理节点多数派决策 <1s + VIP 漂移，厂商口径 RTO<30s。

10 扩展方式 有

有官方文档：纵向 + 横向。纵向：全形态支持升降配，TDSQL-C 秒级（无需数据迁移）。横向：分布式版加 Set + 自动 rebalance（业务无感）；TDStore 加节点 + 自动调度（业务无需指定 shardkey）；TDSQL-C 存储自动扩展、加只读节点（最多 15 个）。扩容对业务的影响从"秒级断连"（集中式升配）到"平滑无感"（分布式加 Set）不等，见深水区。

11 兼容性 部分支持

部分支持官方文档：分形态，差异极大。TDSQL-C MySQL 版：100% 兼容 MySQL 5.7/8.0。TDSQL for MySQL 全系列（单机/集中式/分布式，含 TDStore 引擎）：不支持触发器、存储过程、游标、事件、自定义函数、外键、自建分区、全文索引、临时表、复合语句（BEGIN END/LOOP）等；另有一批 DDL/DML 小语法限制（不支持 CREATE TABLE ... SELECT、SELECT INTO OUTFILE、LOAD DATA、不带 WHERE 的 UPDATE/DELETE 等）。TDSQL for PostgreSQL：PG 模式完全兼容，Oracle 模式高度兼容（厂商口径 98%，含 PL/SQL、系统包、分区表等）。详见深水区三。

12 许可证与商业模式 有

有（官方口径）：闭源商业。公有云按量计费模型：TDSQL for MySQL 按"节点内存规格 × 分片数 + 存储 GB + 备份"计量；TDSQL-C 预置型按规格 + 存储 GB，Serverless 按 CCU-秒（1 CCU ≈ 1 vCPU + 2GB 内存）+ 存储 GB（一/二级分层），审计单独计费；金融版/私有化按 license/订阅。开源例外：OpenTenBase（PG 版社区发行版，开放原子基金会，2023-12 捐赠）。

13 中文资料丰富度 有

有社区共识：丰富。官方中文文档体系完整（产品文档 557/1003/1129/1376 系列 + 金融专区文档）；腾讯云开发者社区、官方技术博客（博客园/掘金/知乎/SegmentFault 官方账号）持续输出；第三方实践帖（CSDN/墨天轮/cndba）多。但内核机制文档的深度与体系化程度弱于 MySQL/PG 官方文档社区共识；Boundless 等新形态文档仍在完善中。

14 性能与延迟特征 有

有（金融级分布式；强一致优先）。

  • 分片/集群版水平扩展读写；强一致复制带来写延迟代价 官方文档。
  • 公开性能数据以厂商口径为主，第三方可复现实测少 待验证。
  • 金融场景优化：高并发短事务是强项，复杂分析靠列存/HTAP 引擎 厂商口径。

15 合规与认证 有

有（继承腾讯云合规体系；金融监管友好）。

  • 腾讯云：等保三级、可信云、ISO27001 等厂商口径厂商口径。
  • 信创名录/金融集采版本以腾讯云官方公告为准；服务大量金融机构，监管报备链条成熟 厂商口径。
  • 私有化部署项目的合规测评单独做 待验证。

16 成熟度与社区生态 有

有（2007 年腾讯内部诞生；金融场景久经考验）。

  • 2007 年为腾讯计费系统诞生，后开放；TDSQL-C（Serverless）是新一代 官方文档。
  • 金融/政企案例多，腾讯云持续投入 厂商口径。
  • 开源与社区声量弱于 OceanBase/TiDB，公开技术细节少 社区共识。

17 标杆用户 有

有（腾讯系（微信支付/王者荣耀））。

  • 微信支付、王者荣耀等腾讯核心业务厂商口径厂商口径。
  • 金融机构（银行/证券）案例多 厂商口径。
  • 春节红包等极端峰值场景验证 社区共识。

18 生态工具链 有

有（腾讯云 DTS/备份全托管）。

  • 迁移/同步：腾讯云 DTS 官方文档。
  • 备份：自动备份+PITR 官方文档。
  • 监控：云监控+DBbrain 诊断 官方文档。

19 云托管与 Serverless 有

有（本身就是云服务；TDSQL-C Serverless）。

  • TDSQL 本身就是腾讯云托管服务；TDSQL-C Serverless 按量 官方文档。
  • 私有化/专有云版本面向政企 官方文档。
  • 腾讯云绑定 社区共识。

20 数据接入与摄入 有

有（兼容 MySQL 工具链；DTS 迁移）。

  • LOAD DATA、mydumper 等 MySQL 工具可用 官方文档。
  • 腾讯云 DTS 做迁移与同步 官方文档。
  • 分片集群导入注意按 shard key 打散，避免热点 社区共识。

21 外部数据访问 部分支持

部分支持（MySQL 版无外部表；PG 版有 FDW）。

  • TDSQL-MySQL 无外部表语义 社区共识。
  • TDSQL-PG（基于 PG）可用 postgres_fdw 待验证。

22 CDC 与下游同步 有

有（binlog 兼容；DTS、Debezium/Canal）。

  • binlog 与 MySQL 兼容，可接 Canal/Debezium 官方文档。
  • DTS 持续同步是云上标准链路 官方文档。

23 TTL 与数据生命周期管理 部分支持

部分支持（同源分区过期；无原生行级 TTL）。

  • MySQL 版分区 + event，PG 版分区 + 定时任务 社区共识。
  • 无原生行级 TTL 社区共识。

24 在线 DDL 与 Schema 演进 部分支持

部分支持（分形态：TDSQL-C 同 MySQL 内核在线 DDL；分布式版官方未给 online 对照表；PG 版同 PG 原生）。

  • 只改定义：TDSQL-C 100% 兼容 MySQL 8.0，INSTANT 加列/删列/改 DEFAULT 行为同内核 官方文档；分布式版官方未给出各操作的 online 对照表（未找到证据）。
    • 重写但位置不变：TDSQL-C 同 InnoDB INPLACE 在线建索引；TB 级大表加索引仍是数小时量级（共享存储免了备库重做，主从延迟压力消失）社区共识；TDSQL-C 支持并行 DDL（内核 ≥3.1.16.004，低版本曾因故障隐患被官方禁用）官方文档；分布式版 DDL 下发全分片同步执行，大表 DDL 排低峰期 社区共识。
    • 搬数据：分布式版改分表键不支持——官方《使用限制》明文"不支持 ALTER 对分表键改名"（查证为无）官方文档；TDSQL-C 改主键/列类型同 MySQL 走 COPY 重建（按兼容性继承）官方文档。
    • 验证约束：分布式版不支持外键（查证为无，官方《使用限制》）官方文档；TDSQL-C 无 NOT VALID 两阶段（同 MySQL，查证为无）官方文档；PG 版同 PG 原生在线 DDL 官方文档。
    • 规模：第二、四类代价 O(n)：TDSQL-C 的 TB 级索引构建数小时（写不阻塞、备库不受拖累）；分布式版跨分片 DDL 代价随分片数放大 社区共识。
    • 语义：TDSQL-C DDL 语义同 MySQL（隐式提交、MDL）；分布式版 DDL 经 Proxy 下发各分片——"在线"指各分片在线执行，不是"无代价" 社区共识。

25 多租户与资源隔离 部分支持

部分支持（实例/分片级隔离为主）。

  • 租户隔离靠多实例/分片，细粒度资源组能力有限 社区共识。
  • 分布式版按分片打散天然有一定隔离 社区共识。

26 跨地域多活 有

有（多中心架构，跨区容灾/多活）。

  • 分布式版支持跨中心部署，强同步多活可配 官方文档。
  • 跨中心延迟要求高，选型看网络 社区共识。

27 高可用架构与 RTO/RPO 有

有（强同步多副本自动切换）。

  • 强同步复制多副本，主故障自动切换 官方文档。
  • RPO=0，RTO 秒级 官方文档。

28 行级安全与数据脱敏 未找到证据

未找到证据（未见原生RLS公开说明）。

  • 未找到 TDSQL 原生行级安全的公开官方文档 待验证
  • MySQL 协议兼容，权限模型沿用 GRANT；脱敏多靠应用层或腾讯云数据安全产品 待验证
  • 强合规场景选型前需向官方求证 RLS / 脱敏路线图 待验证

29 JSON 与半结构化能力 有

有（MySQL 版 JSON 继承）。

  • MySQL 版原生 JSON 类型与函数 官方文档。
  • 能力与上游 MySQL 对齐 社区共识。

30 全文检索能力 有

有（FULLTEXT 继承）。

  • MySQL 版 FULLTEXT 索引 官方文档。
  • 大规模检索同样建议外挂 ES 社区共识。

31 存储效率与压缩 有

有（列存引擎+压缩，细节披露有限）。

  • 支持列存引擎与数据压缩，面向 HTAP 负载优化存储。厂商口径
  • 具体压缩算法、压缩比等技术细节公开资料较少，以官方白皮书口径为主。待验证
  • 云上存储按量计费，压缩收益直接体现在账单而非用户可调参数。社区共识

32 开源协议与厂商锁定风险 有

有（腾讯云绑定；金融级特性云专属）。

  • TDSQL 为腾讯云托管分布式数据库，架构与运维深度绑定腾讯云，无法迁出。官方文档
  • 开源版本功能与云上企业版存在差距，强一致、多地多活等能力云专属。社区共识
  • 从 TDSQL 迁出需重写分片键设计与强一致依赖，成本高。社区共识

33 查询优化器与计划稳定性 有

有（MySQL 衍生+分布式优化器）。

  • 基于 MySQL 优化器扩展分布式计划 官方文档。
  • hint 兼容 MySQL 社区共识。

34 参数调优与自治能力 有

有（DBbrain 自动诊断：索引推荐+限流）。

  • 腾讯云 DBbrain 提供 SQL 诊断、索引推荐、自治限流 官方文档。
  • 参数组可调 官方文档。

35 静默数据损坏防护 有

有（继承 InnoDB 校验，云层多副本兜底）。

  • MySQL 版基于 InnoDB，继承页 checksum 与 doublewrite 防写撕裂。厂商口径
  • 腾讯云底层做多副本冗余与存储层校验，单副本损坏可自动修复。官方文档
  • 用户侧无独立的全库校验命令，损坏审计依赖云厂商。待验证

36 存储过程/触发器/过程语言 有

有（SP/触发器继承 MySQL）。

  • 存储过程、触发器、事件与 MySQL 一致 官方文档。
  • 去 O 改写成本与 MySQL 一致 社区共识。

37 约束与数据完整性 有

有（FK/CHECK 继承）。

  • 外键、CHECK 与 MySQL 一致 官方文档。
  • 分布式下外键使用注意 shard 键对齐 社区实测。

38 分析 SQL 完备性 有

有（窗口函数/CTE 完整继承）。

  • 8.0 窗口函数、CTE 官方文档。
  • 复杂分析非其主场景 社区共识。

39 被遗忘权与数据擦除 部分支持

部分支持（手动DELETE；binlog/备份残留）。

  • 删除靠标准 DML，无公开的原生擦除工作流 待验证
  • binlog、备份集、异地灾备实例构成残留面，与 MySQL 生态一致 社区共识

40 数据血缘与目录集成 部分支持

部分支持（WeData 数据地图集成）。

  • 通过 WeData 数据地图做血缘 官方文档。
  • 无原生列级血缘 社区共识。

41 存算分离 vs 存算一体 有

有（存算分离架构）。

  • 计算与存储分离设计 官方文档。

42 多模能力 部分支持

部分支持（随 MySQL：JSON+全文）。

  • JSON、全文索引随 MySQL 引擎 官方文档。
  • 无向量/图 社区共识。

43 FinOps 成本可观测性 有

有（腾讯云按实例规格计费，标签+预算告警）。

  • 按实例规格与存储按量/包年计费，支持费用标签做业务归因。官方文档
  • 费用中心支持预算设置与超支告警。官方文档

44 驱动与多语言生态 有

有（MySQL 协议兼容）。

  • MySQL 线协议兼容 官方文档。

45 物化视图 无

无（查证为无物化视图能力）。

  • 无物化视图（查证为无）官方文档。
  • 汇总表模拟 社区共识。

46 支持跨云 部分支持

部分支持（腾讯云为主；私有化可出云）。

  • 主力是腾讯云 官方文档。
  • 有私有化/本地部署版本，可出云但非多云原生 厂商口径。

47 热点数据更新能力 部分支持

部分支持（组锁机制 GA 可用性未证实，热点靠应用层打散）。

  • 默认语境为分布式 TDSQL for MySQL：存储层行锁（InnoDB/TXSQL 内核），后来者排队等待；死锁由内核检测并回滚一方，重试由应用负责；热点行在单分片内串行，热点键若集中落在同一分片，该分片主节点即成为单点 社区共识。
  • 内置缓解：腾讯在 TXSQL 内核研发"热点感知"锁管理机制，被 SIGMOD 2025 收录；系统动态识别被高频争抢的热点后，把冲突事务导入高效的"组锁模式"协作执行，大幅减少传统"锁-等待"开销；官方称极端热点场景最高 6.5–22 倍提升，微信支付日常交易性能提升 30%、大促热点 TPS 近 10 倍、延迟抖动降低 80% 厂商口径。
  • 边界：该机制的具体 GA 版本与参数开关未找到公开证据，现有材料多为论文与媒体报道的厂商口径，所用版本是否可用需向官方确认 待验证。
  • 衰减形态：组锁模式缓解的是锁管理开销，不改变单行串行的本质；分布式布局下热点键落在同一分片时，单分片主节点仍是瓶颈 社区共识。
  • 应用层模式与代价：计算节点历史上用哈希表预判更新数据分布来做限流与分发；社区通用模式为计数器分片、队列削峰、Redis 前置扣减后异步落库；代价是最终一致性窗口与对账复杂度 社区共识。

招牌能力

  1. MAR 强同步 + RPO=0 / RTO<30s 的金融级高可用 真本事：一主多备强同步复制（MAR 协议）是架构底色，不是可选项——主库崩溃不丢数据（RPO=0）；心跳 10s 判定故障、多数派 <1s 决策、VIP 漂移，切换总时长厂商口径 <30s；支持同城三中心、两地三中心、两地四中心。2014 年微众银行核心系统、2019 年张家港农商行（国内首个传统银行核心国产化）等 100+ 金融机构核心系统厂商口径是其口碑的实证基础。 边缘真相：强同步的税是写延迟——业内经验值 5–15% 写性能损耗（TDSQL 通过线程池调度优化压到接近 5%，社区共识）；RTO<30s 指的是"故障自动切主"，不是"从备份恢复"，TB 级从物理备份恢复仍是小时级；RTO 数字建立在"心跳超时 10s"这个判定窗口上，10s 内业务看到的是 hang 不是切换。
  2. MC + GTS 全局一致性读（轻量级 GTM） 真本事：分布式场景下跨分片查询可能读到"半提交"快照（分片 A 已提交、B 未提交）——这在金融账务不可接受。TDSQL 用 MC（轻量级全局事务管理器）分配全局时间戳 GTS，每个分片的本地事务 ID 映射到 GTS，查询携带 GTS 按时间戳过滤各分片镜像，要么读到事务前完整旧状态、要么读到事务后完整新状态。关键是对应用完全透明：应用照常发普通 SELECT，内部完成 GTS 分配 + 跨分片 MVCC 视图同步。与纯 GTM 方案比，MC 减少了 GTM 通信量、避免全局冲突检测。 边缘真相：见深水区二——"轻量级"不等于"去中心化"，MC 依然是 GTS 分配的逻辑中心点；跨分片写事务仍要走 2PC，一致性读解决的是"读"的问题，不解决"写"的性能税。
  3. TDSQL-C "日志即数据库"：计算节点只写 redo log 真本事：存算分离做到极致——计算节点（无状态 TXSQL）不写完整数据页，只把 redo log 写到共享分布式存储层，存储层自行回放生成数据页。直接收益：整体 IO 厂商口径减少 60%+、写性能厂商口径提升 90%+（相对自建 MySQL）；主从基于 redo 同步，延迟毫秒级；计算节点秒级故障切换、秒级升配；扩缩容不涉及数据迁移（存储是共享的）；备份是写时重定向快照，秒级完成、业务无感。这是 Aurora 式架构在腾讯云的实现，但内核是 TXSQL 而非开源分支。 边缘真相：见深水区四——"只写 redo"的代价是 PITR/回档走 redo log 而非 binlog，关 binlog 换性能的同时断掉整个 CDC 生态；存储单库可达 PB 级，但单写节点的计算规格仍是写吞吐天花板。
  4. TDSQL-C Serverless：无连接约 1 小时自动暂停，暂停时计算费为 0 真本事：0.25–64 CCU 自动伸缩（CPU 亚秒级扩容、内存约 8s 扩容/63s 缩容），无连接约 1 小时后自动暂停、再次连接秒级唤醒；暂停期间计算费为 0，只有存储继续计费。开发测试、SaaS 多租户、波峰波谷业务的"不用不花钱"名副其实——这是全家族里唯一真 Serverless 的形态。 边缘真相：见深水区四——"零费用"有三道关：启动后 10 分钟内无请求也不会降级（最小计费窗口）；暂停期间存储费照收（TB 级存储的"暂停"并不便宜）；每天第一波流量要吃秒级冷启动。对持续读写业务，Serverless 单价高于预置型，总成本反而可能更贵。
  5. PG 版"一套引擎、双模兼容" + 2025-05 一体化版本 真本事：TDSQL for PostgreSQL 在语法层、元数据层、视图层隔离 Oracle 与 PG 差异，底层复用统一执行引擎（事务管理、行列混合存储、MPP 分布式架构），同一集群可建 PG 模式或 Oracle 模式数据库；Oracle 模式兼容数据类型与运算符、分区表、系统内置包、系统视图、函数、存储过程、PL/SQL（厂商口径 98%）；V5.21 起支持行列混存（行存 OLTP + 列存 OLAP 同库），向量化执行引擎；社区发行版 OpenTenBase 已捐赠开放原子基金会，是家族里唯一的开源出口。2025-05 一体化版本更进一步：一次安装即可按需部署 MySQL / PostgreSQL 多种实例模式，统一管控（企业版集中式/分布式/标准版三档）。 边缘真相："98% 兼容"是厂商口径，剩下 2% 往往是核心系统最难迁的部分（PL/SQL 高级包、DBA 习惯的系统视图行为差异），必须逐项 POC；V2（2020 年前）已于 2023-12-30 停售、V5.06 将于 2025-12-30 停售，老版本用户面临迁移窗口（见深水区六）。

深水区

深水区一：shardkey 是终身契约——选定那天，未来十年的路就定死了

  • 机制：分布式版按 shardkey 做哈希分片。建表时可显式指定 shardkey；不指定时 TDSQL 会自动选一个，但该功能默认关闭（腾讯技术公开课 Q&A 口径：因为 TDSQL 不知道业务的访问模式，自动选的未必最合适）。官方《使用限制》明确：不支持 ALTER 对分表键改名；UPDATE 分区表/shardkey 直接报错（Proxy ERROR 682: can not update the shardkey）；分表 UPDATE 必须带 WHERE 条件，否则系统拒绝执行。
  • 推到边缘：shardkey 选错 = 三种死法齐发——① 热点倾斜：大商户/大客户的数据全挤在少数分片（微信支付的解法是"双 KEY 分布机制"，普通团队没有）；② 跨分片查询：WHERE 不带 shardkey 的 SELECT 触发全分片扫描 + Proxy 聚合，响应慢一个数量级；③ 想改？没有在线改 shardkey 的路，只能建新表 + DTS 全量/增量迁移，等于一次小型重构。更隐蔽的是建表约束：官方默认禁止创建无主键表（TCE 白皮书口径，保证写入符合预期），分表还要求主键/shardkey 规划前置——schema 设计从"上线后再说"变成"上线前必须想清楚"。
  • 选型含义：shardkey 规划是分布式版 POC 的第一优先级，拿业务 80% 高频查询反推；不愿做这道题的团队应该直接选 TDSQL-C（单库视角）或 TDStore 引擎版（业务无需指定 shardkey，自动调度）。
  • 来源：腾讯云《TDSQL MySQL 版使用限制》（2024-01-06）；腾讯技术公开课 Q&A（建表/shardkey/2PC 口径）；第三方实测文档（UPDATE shardkey 报错 682）。

深水区二：跨分片事务的 2PC 税，与 MC 这个"轻量级中心"

  • 机制：经典 InnoDB 引擎的跨分片事务走改造过的 MySQL XA 两阶段提交——腾讯公开课 Q&A 原话："跟开源差别比较大……性能影响不是特别大，基本上影响可能在 20% 左右"厂商口径。TDStore 引擎走协商式 2PC（协调者下沉到存储层）：PREPARE → COMMIT → CLEAR（异步）三轮 RPC。而跨分片一致性读依赖 MC（轻量级 GTM）分配全局时间戳 GTS。
  • 推到边缘：① 2PC 的税与事务跨越的分片数正相关，热点行上的跨片事务还会放大锁等待——"把分布式事务变回本地事务"的唯一办法是 schema 设计时就让关联数据同分片（shardkey 对齐），这和 MySQL 里随便跨表完全不同；② MC 是"轻量级"GTM，不是"去中心化"GTM——GTS 分配依然是逻辑上的中心点，官方材料未公开其高可用形态（多副本？故障时 GTS 停滞对跨分片读的影响？），列入待验证项；③ Proxy 默认强一致读，跨分片聚合查询在 Proxy 层做合并/排序/分页，Proxy 容量要按连接数和聚合复杂度配，否则无状态网关先成为瓶颈。
  • 选型含义：POC 必须用真实事务模型压测跨分片比例，不要只测单分片点查；MC 的单点风险是架构评审时值得追问厂商的一道题。
  • 来源：腾讯云技术公开课 Q&A（2PC 改造与 20% 口径）；SegmentFault《TDSQL 全局一致性读技术详解》（2024）；腾讯云《必修课！深度解析金融级分布式数据库一致性技术》（2025）；腾讯云《TDSQL Boundless 分布式事务与数据亲和性》。

深水区三：TDSQL for MySQL 的兼容性边界——官方《使用限制》的真实代价

  • 机制（官方《使用限制》2024-01-06 原文口径，优先级最高）：大特性限制——不支持自定义函数、事件、表空间；不支持视图、存储过程、触发器、游标；不支持外键、自建分区；不支持复合语句（BEGIN END、LOOP）；不支持主备同步相关 SQL。DDL 小语法——不支持 CREATE TABLE ... SELECT、CREATE TEMPORARY TABLE、CREATE/DROP/ALTER SERVER/LOGFILE GROUP；不支持 ALTER 对分表键改名。DML 小语法——不支持 SELECT INTO OUTFILE/DUMPFILE、不支持不带 WHERE 的 UPDATE/DELETE、不支持 LOAD DATA/XML、不支持 INSERT ... SELECT（1.14.4 之后版本支持）、不支持不带列名的 INSERT/REPLACE、不支持 index_hint、HANDLER/DO。管理 SQL——不支持 ANALYZE/CHECK/CHECKSUM/OPTIMIZE/REPAIR TABLE（需用透传语法）、不支持 FLUSH、KILL、RESET、SHUTDOWN、SHOW BINARY LOGS。
  • 推到边缘：① 这套约束是 TDSQL for MySQL 内核的共性，集中式版、单机版同样受限——"不要分库分表所以选集中式版"躲得过分片，躲不过兼容性损失；② 从 MySQL 迁过来，代码里但凡用了触发器/外键/全文索引/存储过程/临时表，就是重写，没有"兼容模式"可开；③ 运维习惯也要改：DBA 熟悉的 KILL、OPTIMIZE TABLE、SHOW BINARY LOGS 全部不可用，慢 SQL 排查要切到 DBbrain/赤兔体系。
  • 选型含义：迁移前用官方《兼容性》+《使用限制》两份文档做静态代码扫描，触发器/外键/全文索引三项是"一票否决项"——中任意一项重度依赖，直接选 TDSQL-C（100% 兼容 MySQL 5.7/8.0），不要赌分布式版。
  • 来源：腾讯云《TDSQL MySQL 版使用限制》（2024-01-06，最近更新）；腾讯云《TDSQL MySQL 版兼容性》；社区研究交叉验证（2026-05）。

深水区四：TDSQL-C Serverless 与存储层的真相——"暂停"不等于"不花钱"

  • 机制：Serverless 按 CCU-秒计费（1 CCU ≈ 1 vCPU + 2GB 内存），存储按 GB 分一/二级（高频/低频）计费。自动启停：无连接约 1 小时后自动暂停，再次连接秒级唤醒；弹性范围 0.25–64 CCU，CPU 亚秒级扩容、内存约 8s 扩容/63s 缩容。存储层是共享分布式三副本，计算节点只写 redo log。
  • 推到边缘：① "暂停时计算费为 0"有三道关：实例启动后 10 分钟内即使无请求也不会降级（最小计费窗口）；暂停期间存储费照收——TB 级数据的"暂停"每月仍有可观存储账单；唤醒是"秒级"不是"毫秒级"，每天第一波流量固定吃一次冷启动。② redo log 回档是把双刃剑：关闭 binlog 可获厂商口径 30%+ 写性能提升，但代价是 Canal / Maxwell / Debezium / Flink CDC 全部断流——PITR 改走 redo log 回放，下游数仓/搜索/缓存同步链路要重做。③ DDL 仍受 MySQL 内核限制：TDSQL-C 兼容的是"语法"，不是"物理代价"——TB 级大表加索引依然是 Online DDL 数小时量级，秒级的是加列（Instant DDL）等特定操作。
  • 选型含义：Serverless 适合波动/间歇负载；持续读写业务算总账可能贵过预置型（待验证：公开案例多为波动业务，持续重负载场景缺少参考）。决定关 binlog 之前，先盘点所有 binlog 下游。
  • 来源：腾讯云《TDSQL-C MySQL 版服务计费说明》《自动启停设置》（2025）；腾讯云《TDSQL-C MySQL 版备份与回档概述》；社区研究（2026-05）。

深水区五：TDSQL Boundless——新引擎的成熟度风险

  • 机制：Boundless 三大组件——SQLEngine（基于 MySQL 8.0，多主无状态，每节点可读写）、TDStore（LSM-Tree + Multi-Raft KV 引擎，数据按 Key 范围分布在 Region 上）、TDMC（Raft 一主两备集群，分配全局事务 ID、协调数据调度）；对等架构 HyperNode 把计算+存储+日志合并在单个节点内，本地访问优先、远端 RPC 补充；2026-03 发布多模态能力（结构化 + JSON + 全文检索 + 向量检索）。
  • 推到边缘：① TDStore 2022-08 才开始商业化，Boundless 多模态 2026-03 刚发布——正处活跃迭代期，协商式 2PC、自动分裂/合并/迁移等新机制的独立实测与生产故障案例还很少（社区共识：中等信心）；② 厂商论文（VLDB 2024《TDSQL: Tencent Distributed Database System》及相关 industry paper）描述的是设计目标与受控实验，不是生产故障率——选型时要区分"论文口径"与"独立实测"；③ 多模态"一引擎多模型"听着性感，但向量检索/全文检索的成熟度与专用引擎（ES/Milvus）不在一个量级，重度非结构化负载仍建议专用方案。
  • 选型含义：Boundless 适合愿意陪跑新架构、且有原厂深度支持的团队；求稳的金融核心建议用经典分布式 InnoDB 版（十年以上生产验证）。
  • 来源：腾讯云《TDSQL Boundless 产品架构》《存储引擎架构与数据模型》《分布式事务与数据亲和性》；VLDB 2024 论文；社区研究（2026-04/05）。

深水区六：大版本升级与版本分裂——私有化版和公有云不是同一个产品

  • 机制：① TDSQL-C MySQL 版暂不支持 5.7→8.0 这类大版本升级（官方 FAQ 原文，查证为无）：唯一路径是新建目标版本实例 + DTS 全量/增量迁移，等于一次小型迁移项目；内核小版本支持原地快速升级（redo log 存储，升级快，但连接可能秒级闪断）。② TDSQL for PostgreSQL 有明确生命周期：V2（2020 年前）2023-12-30 停售、V5.06（2021）2025-12-30 停售，新购只有 V5.21——老版本用户面临迁移窗口。③ 私有化/金融版 vs 公有云：标准版监控采样 5 分钟/次、金融定制版 1 分钟/次；备份保留标准版 7 天、金融定制版最长 3650 天（需工单）；操作日志 7 天 vs 60 天+归档 1 年；金融定制版支持一主一从/一主二从定制部署与监管配合——同一内核，两套运维与合规基线，且私有化版本迭代节奏通常慢于公有云社区共识。
  • 推到边缘：① 大版本升级没有"一键"，意味着 MySQL 8.0 的新特性（窗口函数、CTE、Hash Join）对 5.7 存量实例是"看得见够不着"，除非接受 DTS 迁移成本；② 版本分裂的长期代价：私有化金融版客户享受不到公有云的快速迭代，安全补丁与内核小版本要走专有云发布通道，升级窗口谈判成本高；③ 集中式→分布式同样没有在线升级，只能 DTS + shardkey 规划 + 停机/切流。
  • 选型含义：签约前把"未来 3 年的大版本升级路径"写进技术评审项；私有化选型要确认版本发布节奏与补丁 SLA，不要默认"和公有云一样新"。
  • 来源：腾讯云《TDSQL-C MySQL 版常见问题》（版本升级章节，2025-12-15 更新）；腾讯云《TDSQL PostgreSQL 版产品简介》（内核版本生命周期）；TCE 专有云 TDSQL 产品白皮书；社区研究（2026-05）。

客户经验

本区内容主要基于厂商口径与媒体转述，独立社区验证不足，引用时请打折。

生态 微众银行全国首个分布式银行核心 —— 金融级生产实证

一句话
微众银行基于 TDSQL 建成全国首个分布式银行核心系统（Openhive，同城多活）：单日峰值 14 亿笔交易、可用率 99.999%、单账户年 IT 成本降至 2 元。
窄场景
银行/金融核心系统去 IOE：要求同城多活、金融级可用性，且需要"国内已有银行跑在前面"的合规与审计说服力。
机制
TDSQL（腾讯分布式数据库，MySQL 协议兼容）支撑微众银行全行系统跑在分布式架构上：同城多活部署、分布式事务、自动容灾切换。"单账户年 IT 成本 2 元"是对比传统"小型机+Oracle+EMC"集中式架构的成本叙事——去 IOE 的经济账。
生产验证
新浪财经转述"子弹财经"报道的微众银行案例量化数字（https://finance.sina.cn/2025-12-14/detail-inhauqsz3153445.d.html）。诚实标注：独立媒体转述，非腾讯官方直发；数字未独立复现。反差本身也是信息：TDSQL 的用户是"签了合同的银行"，不是"写博客的工程师"——社区一线工程师的生产分享本次几乎找不到。
竞品差距
OceanBase——蚂蚁/网商银行的同类故事，两者是"国产分布式银行核心"叙事的双子星；传统 IOE——成本差出数量级，是 TDSQL/OceanBase 共同的立论基础。"银行核心敢用"这张信任状两家各持一张，选型看的是存量生态（腾讯系 vs 蚂蚁系）。
证据等级
具名生产（独立媒体转述）；数字未独立复现；社区一线分享缺席（已标注）
最后核验
2026-10-01

政策 "去 O"政策 + 金融合规 —— 政策红利型招牌

一句话
在"去 IOE"政策与金融信创合规语境下，TDSQL 是"国产分布式数据库"的合规选项之一——政策本身就是它的招牌。
窄场景
国企/金融/政务的信创选型：采购目录、合规审计、"自主可控"评分表是硬约束；技术优劣在合规门槛之后讨论。
机制
这不是内核能力，是制度能力：TDSQL 的国产身份、金融案例背书、腾讯的交付体系，让它能进信创采购清单。对这类客户，"能不能过审"优先于"性能高多少"。这是 31 款里少数"政策即招牌"的案例。
生产验证
"4000+ 客户、十大行七家用"——DoNews 转述腾讯官方口径，本次未留存可逐字引用的 URL（诚实标注）。厂商口径，未独立复现；独立验证缺失。
竞品差距
Oracle/MySQL——"去 O"政策下是被替代对象；Aurora/Spanner——外资云，在信创场景无资格。这张牌只在"中国金融/政务信创"窄场景生效，出海或纯互联网场景不成立——地域性招牌，必须标注适用边界。
证据等级
证据最弱——厂商口径转述（媒体）；独立验证缺失（已明确标注）
最后核验
2026-10-01

用户最买账的 5 点

  1. 金融级高可用口碑：RPO=0 / RTO<30s 是架构给的，不是配出来的
    • 为什么是真的：MAR 强同步是内核级能力——主库写必须同步到备库才返回，天然 RPO=0；心跳 10s 判定 + 多数派决策 + VIP 漂移的切换链路是产品化能力；100+ 金融机构核心系统、IDC 2024 中国金融行业分布式数据库 21.32% 份额（银行子市场 22.48% 第一）是第三方背书。
    • 边缘与限度：强同步税约 5–15% 写性能；RTO<30s 是切主不是恢复；大多数业务的真实需求是"别宕机"而不是"两地三中心"——为用不上的容灾等级付三倍机器钱是常见浪费。
    • 来源：腾讯云官方文档 + IDC《中国金融行业分布式事务型数据库市场份额，2024》；观察版本：TDSQL for MySQL 全形态（2026-05）。
  2. TDSQL-C "大存储单库 + 100% MySQL 兼容 + 运维省力"三合一
    • 为什么是真的：存算分离让单库到 PB 级无需分库分表；TXSQL 内核 100% 兼容 MySQL 5.7/8.0（触发器/外键/全文索引全保留）；秒级升配、ROW 秒级快照、一键 PITR、库表级回档都是开箱即用。这是"不想做分片设计、不想丢 MySQL 特性"的团队的最短路径。
    • 边缘与限度：换来的是深度腾讯云绑定（无他云、无自建）；部分核心参数受规格限定；单写节点规格仍是写吞吐天花板，PB 级存储 ≠ 无限写入。
    • 来源：腾讯云《TDSQL-C MySQL 版产品概述》《兼容与格式》；社区研究（2026-05）。
  3. 国密 / 等保 / 信创合规开箱即用
    • 为什么是真的：国密 SM2/SM3/SM4、三权分立、列级权限、SQL 审计、TDE 都是产品内置能力，不是外挂；等保三级是设计基线。政企、金融客户选型时"合规"是从 0 到 1 的门槛，TDSQL 直接给满。
    • 边缘与限度：国密是增值组件、默认未配置厂商口径；国密算法的性能开销官方未公开实测数据待验证；合规能力强 ≠ 业务性能强，两者要分开 POC。
    • 来源：TCE 专有云 TDSQL 产品白皮书（安全章节）；腾讯云安全白皮书；观察版本：金融版/专有云（2024-01 口径）。
  4. 迁移工具链：DBbridge + DTS 让"去 O / 去 MySQL 自建"有路可走
    • 为什么是真的：DBbridge 支持 Oracle/MySQL → TDSQL 的 DDL/DML 自动转换（厂商口径代码修改量压缩至 5% 以内）；DTS 支持全量 + 增量在线迁移；富融银行 10 个月完成核心系统替换、15 小时内完成数据迁移和系统升级是有公开报道的案例。
    • 边缘与限度："5% 以内"是厂商口径，真实比例取决于 Oracle 特性使用深度（PL/SQL 包、DB Job 越多，手工越多）；迁出比迁入难得多——快照备份是腾讯云专有格式，签约前就要评估迁出预案（定期逻辑备份到自有 COS）。
    • 来源：腾讯云开发者社区案例（2024）；社区研究（2026-05）。
  5. DBbrain / 扁鹊 / 赤兔：DBA 人力不够时的智能运维
    • 为什么是真的：DBbrain 开箱即用（无需部署 agent），慢 SQL 根因、索引推荐、空间分析、异常诊断都是 DBA 日常最高频的工作；与监控/告警/审计深度集成。MySQL 生态的开源工具链相对薄弱，DBbrain 的相对价值比在 PG 生态更高。
    • 边缘与限度：智能诊断给的是"建议"不是"免责"——根因模型基于腾讯云数据训练，对特殊业务负载的误诊要人工复核；与 DBbrain 深度耦合本身也是一种锁定（自建 Prometheus exporter 做关键指标双备是社区推荐做法）。
    • 来源：腾讯云官方文档；社区研究（2026-05）。

吐槽清单

分类吐槽影响版本状态
兼容坑TDSQL for MySQL 全系列（单机/集中式/分布式）不支持触发器、存储过程、游标、事件、自定义函数、外键、自建分区、全文索引、临时表、复合语句——是内核共性，不是分片导致，集中式版也躲不掉全版本open
兼容坑DDL/DML 小语法限制多：不支持 CREATE TABLE ... SELECT、SELECT INTO OUTFILE、LOAD DATA、不带 WHERE 的 UPDATE/DELETE、不带列名的 INSERT；管理 SQL 不支持 KILL、FLUSH、OPTIMIZE TABLE、SHOW BINARY LOGS，DBA 排查习惯要重建全版本open
运维坑shardkey 一旦选定不可改（ALTER 改名不支持、UPDATE shardkey 报错 682）；选错 = 数据倾斜 + 跨分片全扫描 + 只能建新表 DTS 重迁分布式版open（schema 设计时规避）
运维坑分布式 InnoDB 全分片同步 DDL，大表 DDL 必须排低峰期；集中式→分布式无在线升级，只能 DTS + shardkey 规划 + 停机/切流全版本open
运维坑TDSQL-C 5.7→8.0 无原地大版本升级路径，只能新建实例 + DTS 迁移；内核小版本升级连接可能秒级闪断TDSQL-C MySQL 版open
生态坑TDSQL-C 关 binlog 换厂商口径 30%+ 写性能提升，但 Canal/Maxwell/Debezium/Flink CDC 全部断流，下游数仓/搜索同步链路要重做TDSQL-C MySQL 版open（按需取舍）
成本坑Serverless 自动启停：启动后 10 分钟最小计费窗口、暂停期间存储费照收、每天第一波流量吃秒级冷启动；持续重负载下总成本可能高于预置型TDSQL-C Serverlessopen
授权坑深度绑定腾讯云：无他云、无自建形态；快照备份为腾讯云专有格式，迁出 = 逻辑迁移，TB 级耗时数小时到数天全版本open
运维坑max_connections、innodb_buffer_pool_size 等核心参数受规格限定，极端调优诉求要找客户经理定制全版本partially-fixed（可定制，未产品化）
版本坑PG 版 V2 已停售（2023-12-30）、V5.06 将于 2025-12-30 停售，老版本用户须规划向 V5.21 迁移TDSQL for PostgreSQL V2/V5.06fixed-in-v5.21（新购仅 V5.21）
运维坑产品线多、命名三层含义（家族/分布式版/泛指），选型与看文档时容易混淆；Boundless 等新形态文档仍在完善中全版本open
生态坑TDStore（2022-08 商业化）与 Boundless（2026-03 多模态）实战案例少于经典分布式版，新机制故障案例积累中TDStore / Boundlessopen
版本坑私有化/金融版版本迭代慢于公有云，安全补丁走专有云发布通道；非客户难获取软件包做 POC金融版open

判决

  • 一句话定位：在腾讯云生态内，它是"金融级分布式 OLTP + 云原生 Serverless + PG/Oracle 双模"的完整答案；出了腾讯云，它什么都不是——先确认你愿不愿意为这个绑定付费，再谈选哪个子产品。
  • 适合谁：① 银行/证券/保险核心交易系统（要 RPO=0、强一致、两地三中心）；② 单库 TB+、不愿做分库分表、要 100% MySQL 兼容的 OLTP（TDSQL-C 预置型）；③ 流量波峰波谷明显的互联网业务、SaaS 多租户、开发测试环境（TDSQL-C Serverless）；④ 去 Oracle 迁移（TDSQL for PostgreSQL Oracle 模式，须逐项 POC）；⑤ 政企信创/国密合规硬性要求的项目；⑥ 已深度使用腾讯云生态、接受厂商绑定的团队。
  • 不适合谁：① 有多云/跨云策略的团队（无他云形态，迁出=逻辑迁移）；② 重度依赖触发器/外键/全文索引/存储过程又想要分布式版的业务（兼容性损失要重写）；③ 数据长期 <100GB、QPS 低的小业务（分布式架构是杀鸡用牛刀，云上 RDS-MySQL 更划算）；④ 追求开源生态、想自己掌控内核的团队（闭源，OpenTenBase 只覆盖 PG 版）；⑤ 海外业务为主（海外节点与合规弱于 AWS/Azure）；⑥ 超复杂 OLAP/数仓（主业是 OLTP，分析走 TDSQL-A 或专用数仓）。
  • 迁移成本：
    • MySQL → TDSQL-C：低。100% 协议/语法兼容，DTS 全量+增量在线迁移；注意字符集（utf8mb4_general_ci vs utf8mb4_0900_ai_ci）与 sql_mode 两边对齐。
    • MySQL → TDSQL for MySQL（分布式/集中式）：中高。触发器/外键/全文索引/存储过程等要重写；shardkey 必须在建表前规划；建议先做静态代码扫描再定。
    • PostgreSQL → TDSQL for PostgreSQL：中低。PG 模式完全兼容；注意 V2/V5.06 生命周期，直接上 V5.21。
    • Oracle → TDSQL for PostgreSQL（Oracle 模式）：中。厂商口径 98% 语法兼容，但 PL/SQL 高级包、系统视图行为差异、DB Job 等要逐项 POC；DBbridge 可做 DDL/DML 自动转换打底。

来源与待验证清单

  • 版本信息来源：腾讯云《TDSQL PostgreSQL 版产品简介》（内核版本生命周期：V2 停售 2023-12-30、V5.06 停售 2025-12-30、V5.21 发布 2024-06-30）；腾讯云《TDSQL-C MySQL 版常见问题》（版本升级章节，2025-12-15 更新）；DoNews《腾讯云发布 TDSQL 一体化数据库》（2025-05-14）。
  • 架构口径来源：腾讯云官方文档产品 557（TDSQL MySQL 版：概述/实例架构/兼容性/使用限制 2024-01-06/安全白皮书）、1003（TDSQL-C MySQL 版：产品概述/架构/兼容与格式/备份与回档/计费说明/自动启停设置/常见问题）、1129（TDSQL PostgreSQL 版）、1376（TDSQL Boundless：产品架构/存储引擎/分布式事务/安全与合规）；TCE 专有云《分布式云数据库 TDSQL 产品白皮书》（安全与部署章节）；VLDB 2024 论文《TDSQL: Tencent Distributed Database System》；腾讯云开发者社区技术百科《HTAP 数据库 TDSQL-H》（2023-08-31）。
  • 深水区机制来源：腾讯云技术公开课 Q&A（SQL 引擎自研、shardkey 选择、XA 2PC 改造约 20% 影响——厂商口径）；SegmentFault《TDSQL 全局一致性读技术详解》（2024）；腾讯云开发者社区《必修课！深度解析金融级分布式数据库一致性技术》（2025）；第三方实测文档（UPDATE shardkey 报错 682、Proxy 错误码 658）。
  • 吐槽采集方向：腾讯云官方《使用限制》《常见问题》文档中的明确限制项；社区研究文档的落地踩坑清单（colask/vibe-coding tdsql-mysql-deep-dive，2026-05）；知乎/CSDN/墨天轮 DBA 实践帖、GitHub 相关讨论（待 LLM 流水线规模化验证）。
  • 待验证项：① MC（轻量级 GTM）的高可用形态与故障时行为（官方材料未公开）；② 国密 SM2/SM3/SM4 的实际性能开销；③ Serverless 在持续重负载下的总成本 vs 预置型（公开案例多为波动业务）；④ Boundless 协商式 2PC 与多模态能力的独立实测/生产故障案例；⑤ 私有化金融版相对公有云的版本滞后具体程度。
  • 下次评审建议：跟踪 ① TDSQL Boundless 多模态能力的生产案例与独立评测；② TDSQL-C 大版本升级路径是否有官方原地升级方案；③ TDSQL for PostgreSQL V5.06 停售（2025-12-30）后的迁移情况；④ 一体化版本（2025-05）的企业版集中式/分布式/标准版三档实际功能差异文档化情况。