1. 评估背景与测试环境准备先说清楚我这次为什么要做TDSQL的评估。我们手上有一套跑了快五年的MySQL在线业务系统用户量涨上来之后单库单表的写入压力已经明显顶不住了。主从复制延迟在高峰期经常飙到十几秒半夜跑批任务的时候甚至会出现锁等待堆积。换硬件、分库分表中间件都聊过但团队最终把目光落到了分布式数据库上TDSQL就是重点考察对象之一。TDSQL是腾讯推出的分布式数据库产品底层依然是MySQL生态对外兼容MySQL协议。这个定位对我们这种存量MySQL业务来说非常关键——意味着应用层改造成本能压到最低DBA的运维习惯也能大部分沿用。但“兼容”这件事不能光看官方文档怎么吹必须自己动手测。所以这轮评估我没有只看宣传材料而是专门搭了一套独立的测试环境从兼容性、运维能力、性能表现三个维度做了完整的实测。1.1 为什么分布式数据库是刚需而不是可选在聊TDSQL的具体表现之前得先把“为什么需要分布式数据库”这个问题说透。单机MySQL的瓶颈其实就三个存储容量、计算能力、连接数。容量不够可以堆磁盘但单库的写入瓶颈卡在磁盘IO和binlog串行写入上计算能力不够可以加CPU但一条慢SQL扫全表的时候再多的核也帮不上忙连接数更不用说应用一扩容连接池一开几千个连接直接能把数据库打挂。分库分表中间件比如ShardingSphere、MyCAT这种能解决一部分问题但引入了新的复杂度中间件本身的高可用、全局ID生成、分布式事务、跨节点join限制、数据迁移工具链……每一个都是坑。TDSQL这类原生分布式数据库的思路是把分片、路由、分布式事务、弹性扩缩容这些能力内置到数据库内核里对应用暴露的还是“一个数据库”的逻辑形态。这个思路对业务团队来说是最友好的——你不需要自己维护中间件也不需要改一大堆SQL只需要在建表的时候指定分表键剩下的交给数据库。1.2 测试环境怎么搭配置怎么选这次评估我用了三套环境做对比一套是原生的单机MySQL 5.7作为基线一套是TDSQL单分片1个分片、1主2从还有一套是TDSQL三分片3个分片、每分片1主1从。这样既能测出TDSQL相对于单机MySQL的损耗也能看出分片扩展带来的线性度提升。硬件配置上所有节点统一用16核32GB的云主机数据盘用SSD网络走内网VPC避免公网延迟干扰测试结果。操作系统是CentOS 7.9MySQL版本5.7TDSQL版本用的是当时最新的公开版本。这里有个经验评估分布式数据库的时候一定要保证每个分片的硬件规格和单机基线一致否则测出来的性能差异无法归因——到底是分布式架构的损耗还是硬件规格不同导致的根本说不清楚。另外测试数据要尽量贴近真实业务。我直接导了一份线上业务的脱敏数据包含用户表、订单表、商品表、流水表总共大概10张核心表数据量在200GB左右。表结构里既有纯int主键的也有varchar业务主键的还有需要分表的超大流水表。这样测出来的兼容性和性能结果比用sysbench灌出来的假数据有说服力得多。2. 兼容性实测从MySQL迁移到TDSQL到底改多少代码兼容性是这次评估我最关心的维度因为直接决定了迁移成本。TDSQL对外宣称兼容MySQL协议但“协议兼容”和“语法全面兼容”是两码事。我的实测方法很简单把线上库的表结构、存储过程、常用SQL全部导出来在TDSQL上跑一遍看报多少错然后把应用层的Mapper XML和ORM生成的SQL全部抓出来逐个执行对比结果。2.1 SQL语法与数据库对象的兼容情况先说结论常规的DML、DDL语句基本无障碍。SELECT、INSERT、UPDATE、DELETE、JOIN、子查询、GROUP BY、ORDER BY、UNION这些核心语法TDSQL都能直接跑结果与MySQL一致。实际迁移中我们500多条Mapper SQL里只有不到10条需要微调这个比例比我预想的要低很多。但有几个点必须注意属于典型的“文档里写了但没人会认真看”的坑第一自增列不能当全局主键用。在单机MySQL里auto_increment配主键是常规操作。但在分布式架构下自增列只能在每个分片内保证唯一跨分片会重复。TDSQL虽然提供了全局自增的能力通过自增序列实现但性能上有限制而且在分布式事务里会有额外开销。我的建议是凡是需要全局唯一的业务主键都改成应用层生成的分布式ID雪花算法或号段模式或者用UUID。自增列保留用于排序、分页这种非主键场景倒问题不大。第二分表键shardkey必须提前设计好。这是TDSQL和单机MySQL最大的使用差异。建表时必须指定一个shardkey后续所有查询如果带上shardkey条件就能直接路由到对应分片执行如果不带就会变成全分片扫描性能天差地别。比如订单表我用order_id做shardkey按订单号查询是毫秒级但如果是按user_id查某个用户的所有订单就必须全表扫描。这个限制不是TDSQL独有的所有分布式数据库都这样关键是要在表结构设计阶段就把业务查询模式想清楚。第三跨分片JOIN、子查询和事务有性能红线。语法上支持但执行效率可能让你怀疑人生。比如A表和B表分片键不同两个表做JOIN的时候数据要拉到一个节点上再做关联。数据量小时还凑合数据量一旦上去这个操作的代价就是灾难级的。我的经验是优先把经常一起查询的表设计成相同的shardkey让关联发生在同一个分片内TDSQL称之为“亲和性表”或者干脆在应用层做数据组装。2.2 事务与隔离级别分布式事务没你想的那么可怕TDSQL支持分布式事务默认隔离级别是读已提交RC这点和MySQL默认一致对大部分业务来说无感。我专门测了跨分片事务的一致性启动一个事务分别往两个分片上的表插入数据手动kill掉其中一个分片节点再提交事务。结果是另一个分片的写入也回滚了没有出现“一半提交一半没提交”的脏数据。这个表现说明分布式事务的原子性是靠谱的底层用的是两阶段提交2PC 全局时间戳的方案。但要注意性能。跨分片事务的提交延迟比单分片事务高实测数据大概是单分片事务的1.5到2倍。如果业务里有大量跨分片事务一定要评估清楚对整体QPS的影响或者尽量从业务设计上避免——比如把需要强一致的写操作都收敛到同一个分片内。隔离级别方面TDSQL不支持可重复读RR只支持读已提交RC。对于从MySQL默认RR迁过来的业务这个问题不大因为现在主流互联网业务基本都是RC。但如果有依赖RR场景的报表类查询比如事务内多次读取要求结果一致就要注意改造否则可能出现结果漂移。2.3 索引、字符集与存储过程容易被忽略的细节索引方面TDSQL支持普通索引、唯一索引、联合索引和MySQL基本一致。但有个坑唯一索引必须包含shardkey。原因很好理解——如果唯一索引不包含分片键数据库就没办法在写入时快速定位到唯一性校验的目标分片只能全分片检查性能开销极大而且在高并发下会出现并发冲突。这个限制在建表时就要遵守不然后面改起来很痛苦。字符集方面TDSQL支持utf8、utf8mb4线上utf8mb4的表直接迁移没问题。排序规则collation也基本兼容但不同版本之间默认值有差异迁移后最好检查一遍建表语句里的collation是否和原库一致避免出现排序结果不一致的问题。存储过程和触发器TDSQL支持创建和调用但有一些限制——比如不允许跨分片访问、不允许在存储过程中动态拼接表名实际我这轮测试里把线上100多个存储过程全部导入有4个因为跨分片访问报了错需要改写。我的建议是能不用存储过程的尽量不用这个玩意儿在分布式数据库里维护成本高而且一旦涉及数据迁移和分片调整排查问题非常痛苦。3. 运维能力评估集群运营过程中的真实体验数据库选型不能只看性能和兼容性运维能力直接决定了产品上线后DBA团队累不累、事故概率高不高。这一趴我重点测了监控告警、备份恢复、扩缩容三个运维核心场景。3.1 监控告警体系能一眼看到集群健康状态吗TDSQL自带的赤兔管理平台相当于整个集群的运维驾驶舱。先说优点集群拓扑一目了然分片状态、主从关系、延迟情况、存储水位全部可视化展示这点比纯手工运维MySQL强太多。我实际用下来的核心监控指标包括监控项查看位置告警阈值建议CPU使用率节点监控大于80%持续10分钟QPS/TPS集群监控按业务峰值留30%余量慢查询数慢日志分析单节点大于100条/5分钟主从复制延迟分片监控大于5秒持续1分钟磁盘使用率节点监控大于70%提前扩容连接数节点监控大于80%上限需要批评的是赤兔平台默认的告警模板偏保守很多指标默认不开启告警。我遇到过磁盘使用率到了85%都不告警的情况后来发现是没配置。所以上线前一定要逐项核对告警规则别依赖默认配置。这个经验适用于所有云数据库产品不是TDSQL特有的问题。另外TDSQL的慢查询日志是独立收集的可以在平台里直接按分片查看比单机MySQL的slow log好用。利用这个功能我在压测阶段定位了好几条隐藏的跨分片扫描SQL都是在开发环境跑得快、生产环境数据量大之后才暴露的问题。3.2 备份恢复实战关键时候别掉链子备份恢复是我每次选型必测的项目因为平时用不到出了事故才见真章。TDSQL支持物理备份和逻辑备份可以在平台上一键发起。我实际测了两个场景场景一误删数据恢复。模拟了一张业务表被delete误删通过备份集恢复到指定时间点。整个过程大概40分钟200GB数据量恢复出来的数据稽核无缺失。有一个操作细节值得分享TDSQL的备份文件是保存在腾讯云COS上的恢复时需要指定COS路径恢复之前务必确认COS的读写权限和网络连通性否则会恢复失败。场景二全集群容灾演练。我把整个集群的数据节点全部停机然后从备份集重建了一个全新的集群。这个操作不是TDSQL自动完成的需要手动创建新集群、导入配置、恢复数据、重新挂载proxy节点耗时大概3小时。整体流程可操作但对DBA的要求比较高需要熟悉整个架构。我的建议是每个季度至少做一次完整的恢复演练而且要换人做——因为只有不同的人都按文档能恢复成功才算真的靠谱。3.3 扩容缩容分布式数据库的核心价值所在扩容能力是分布式数据库相较于单机MySQL的核心优势我必须实测。测试场景集群从3个分片扩展到6个分片观察数据迁移过程对业务的影响。实际操作下来TDSQL的扩容流程是在管理平台上发起扩容 → 自动创建新的分片节点 → 数据自动重新均衡分布。整个扩容过程中业务读写不受影响只有部分数据在迁移时会略有延迟上升。我记录了数据500GB数据从3分片扩展到6分片耗时约2小时。扩容期间业务读写QPS稳定P99延迟从12ms上升到30ms左右扩容结束后恢复到10ms。有一个细节要注意扩容期间不要执行大事务和批量DDL否则会和数据迁移竞争资源可能拖慢扩容进度甚至报错。缩容也一样支持但操作的频率远低于扩容我只做了功能验证没有实际业务缩容。从运维角度看这个弹性扩缩容能力确实比自建MySQL中间件的方案省心太多至少不用自己写迁移脚本、不用停机窗口、不用手工校验数据一致性。4. 性能压测benchmark数据与调优方向性能是大家最关心的维度也是测试耗时最长的一部分。我用了两种方式一种是用标准工具sysbench做可控基准测试另一种是用真实业务SQL做混合场景测试两者结合才敢下结论。4.1 压测方案设计与参数选择sysbench压测我跑了四类经典场景只读、只写、读写混合、复杂查询含join和group by。每个场景跑30分钟预热5分钟收集中间10分钟的稳定数据。并发数从50逐渐加到200、500。测试命令大概长这样# 准备数据16个表每表100万行 sysbench /usr/share/sysbench/oltp_common.lua \ --mysql-hostx.x.x.x --mysql-port15001 \ --mysql-usertest --mysql-passwordxxx \ --mysql-dbtestdb \ --tables16 --table_size1000000 \ --threads50 --time1800 --report-interval10 \ prepare # 跑只读场景 sysbench /usr/share/sysbench/oltp_read_only.lua \ --mysql-hostx.x.x.x --mysql-port15001 \ --mysql-usertest --mysql-passwordxxx \ --mysql-dbtestdb \ --tables16 --table_size1000000 \ --threads200 --time1800 --report-interval10 \ run真实业务SQL测试的方式是把线上应用的SQL日志抓下来按实际调用比例重放直接用JMeter压测网关接口让请求穿透到数据库层。这样得到的数据比sysbench更接近真实表现但缺点是很难隔离数据库本身的瓶颈——如果应用层或网络有问题数据库测出来的数据就不准。所以两种方式要配合使用互相验证。4.2 实测数据解读分片扩展到底给你带来了什么先看sysbench的结果。以读写混合场景、200并发为例环境QPSTPSP99延迟(ms)单机MySQL 5.718500120028TDSQL 单分片17000110030TDSQL 三分片46000290019这组数据有几个非常值得注意的点第一TDSQL单分片的性能相比单机MySQL有微弱损耗。QPS大概下降了8%这个损耗主要来自代理层的转发开销和分布式事务的时间戳获取。完全可以接受毕竟多了一层分布式调度能力。第二三分片带来的扩展比在2.7倍左右不是完美的3倍线性扩展。原因有两个一是部分聚合查询和跨分片操作在分片变多之后反而需要更多的协调开销二是测试模型不是完全分布均匀的热点数据集中在某些分片上。这个结果在分布式数据库里属于正常水平但也说明一个真相——三节点就能到完美线性扩展属于理想情况真实业务大多在2倍到2.5倍之间浮动。第三分片变多之后P99延迟反而下降了。这个观察很有意思。原因是并发请求被分散到更多分片上单个分片的负载降低队列排队时间减少。所以分布式数据库的价值不仅是提升吞吐上限还能在大并发下保持更稳定的延迟。4.3 性能瓶颈定位与几个有效的调优动作压测过程中遇到的第一个瓶颈是连接数。TDSQL默认的最大连接数设置得比较保守应用侧连接池一开大直接触达连接数上限新的连接请求被拒绝。处理方式是调大max_connections同时把proxy层的连接空闲超时时间调短及时回收无效连接。第二个瓶颈是单分片的热点问题。有张订单表按order_id做shardkey但某几个头部商家的订单量特别大导致特定分片的写入压力远高于其他分片。这种场景下单纯加节点解决不了问题因为热点数据始终落在同一个分片上。我的方案是把订单表改成按user_idorder_id的组合键做shardkey让同一个用户的订单尽量分散到不同分片缓解热点。第三个值得说的优化是批量写入。如果业务需要批量插入数据尽量用一条INSERT语句插入多行而不是循环执行单行INSERT。TDSQL对多行批量插入有专门优化性能差距可以达到5倍以上。这个经验在压测阶段帮了大忙因为我们灌数据的时候一开始是逐行insert速度极慢改成批量insert之后灌数据的效率直接起飞。性能调优表基于实测调优项操作效果连接数限制调大max_connections调短proxy空闲超时避免连接拒绝热点数据调整shardkey字段组合分散热点分片压力批量写入改用多行INSERT写入性能提升5倍以上慢SQL定位跨分片扫描改写SQL带shardkey关键查询耗时降低90%参数调优调大innodb_buffer_pool_size到物理内存70%读写整体提升约20%5. 常见问题与避坑实录这一节把我这轮评估里实际踩过的坑、以及同行业务迁移TDSQL时普遍遇到的问题做个整理都是花时间换来的经验。5.1 高频问题排查速查表问题现象可能原因排查思路解决方法查询特别慢但单分片数据量不大SQL没带shardkey查看慢日志是否全分片扫描改写SQL强制带shardkey条件应用报“分布式事务冲突”多个跨分片事务并发操作同一批数据查看事务阻塞监控业务侧加分布式锁减少冲突扩容后部分查询结果不一致数据还在迁移中查看数据均衡状态等迁移完成后再做数据一致性校验备份恢复失败COS路径权限配置错误查看恢复任务的错误日志检查COS访问权限和网络连通性连接数告警频繁proxy连接泄漏查看应用连接池配置调小连接池闲置超时及时回收建表报错“shardkey类型不支持”用了float/double做分片键查看错误信息换bigint或varchar类型主从延迟持续放大大事务或批量DDL查看分片主从延迟监控拆分批处理避免事务过大5.2 迁移过程中容易忽略的三个风险风险一字段类型隐式转换导致路由失效。如果分片键字段是varchar类型但应用传入的参数是intMySQL在比较时会把varchar转成int导致路由计算结果不一致请求被发错分片。这个问题在单机MySQL里顶多是性能略降放到分布式数据库里就是全分片扫描的灾难。迁移后一定要检查应用传参类型和表字段类型是否严格一致。风险二全局唯一性依赖数据库自增序列。有个业务表原本用自增ID当业务主键迁移之后发现多个分片写入了重复ID。前面提过TDSQL的全局自增需要通过特定方式实现如果你没配置正确自增列只在分片内唯一。这个问题最容易在迁移初期被发现但也最容易在迁移设计阶段被忽略。我强烈建议所有上TDSQL的表业务主键全部改成应用层生成的分布式ID不要依赖数据库自增。风险三容量规划未考虑分片间不均衡。很多团队做容量规划时是“总数据量除以分片数”然后按平均值配磁盘。真实业务里数据分布不可能完全均衡热点表、大字段表、归档数据都可能导致某些分片提前打满。规划时建议按“最大分片不超过均值1.5倍”来做容量冗余宁可多买一点空间也不要上线几个月后就要扩容。5.3 TDSQL与自建MySQL选型建议最后聊聊选型判断。如果你们的业务只是单库数据量不大、QPS平稳、没有快速增长的迹象那完全没必要上分布式数据库单机MySQL加读写分离就够了这是最省成本的方案。但如果你符合下面任何一个条件就值得认真考虑TDSQL这类产品单表数据量超过5000万行DDL和执行性能都开始恶化。写入QPS持续超过单库上限并且未来3年还有增长预期。团队已经明确要上微服务拆分数据库需要按业务维度水平扩展。不想自己维护分库分表中间件和自研数据迁移工具链。TDSQL不是万能的它也有自己的限制跨分片事务性能、数据类型限制、运维复杂度和成本。但作为从MySQL生态平滑演进到分布式架构的路径它在兼容性和运维体验上的完成度确实比自建方案或者纯中间件方案高不少。选数据库没有绝对的最好只有是否匹配你的业务阶段和团队能力。对于大多数MySQL存量业务来说TDSQL给出的是一条务实、平滑的升级路径。 TDSQL分布式数据库深度评测：从MySQL迁移到分片架构的实战体验
1. 评估背景与测试环境准备先说清楚我这次为什么要做TDSQL的评估。我们手上有一套跑了快五年的MySQL在线业务系统用户量涨上来之后单库单表的写入压力已经明显顶不住了。主从复制延迟在高峰期经常飙到十几秒半夜跑批任务的时候甚至会出现锁等待堆积。换硬件、分库分表中间件都聊过但团队最终把目光落到了分布式数据库上TDSQL就是重点考察对象之一。TDSQL是腾讯推出的分布式数据库产品底层依然是MySQL生态对外兼容MySQL协议。这个定位对我们这种存量MySQL业务来说非常关键——意味着应用层改造成本能压到最低DBA的运维习惯也能大部分沿用。但“兼容”这件事不能光看官方文档怎么吹必须自己动手测。所以这轮评估我没有只看宣传材料而是专门搭了一套独立的测试环境从兼容性、运维能力、性能表现三个维度做了完整的实测。1.1 为什么分布式数据库是刚需而不是可选在聊TDSQL的具体表现之前得先把“为什么需要分布式数据库”这个问题说透。单机MySQL的瓶颈其实就三个存储容量、计算能力、连接数。容量不够可以堆磁盘但单库的写入瓶颈卡在磁盘IO和binlog串行写入上计算能力不够可以加CPU但一条慢SQL扫全表的时候再多的核也帮不上忙连接数更不用说应用一扩容连接池一开几千个连接直接能把数据库打挂。分库分表中间件比如ShardingSphere、MyCAT这种能解决一部分问题但引入了新的复杂度中间件本身的高可用、全局ID生成、分布式事务、跨节点join限制、数据迁移工具链……每一个都是坑。TDSQL这类原生分布式数据库的思路是把分片、路由、分布式事务、弹性扩缩容这些能力内置到数据库内核里对应用暴露的还是“一个数据库”的逻辑形态。这个思路对业务团队来说是最友好的——你不需要自己维护中间件也不需要改一大堆SQL只需要在建表的时候指定分表键剩下的交给数据库。1.2 测试环境怎么搭配置怎么选这次评估我用了三套环境做对比一套是原生的单机MySQL 5.7作为基线一套是TDSQL单分片1个分片、1主2从还有一套是TDSQL三分片3个分片、每分片1主1从。这样既能测出TDSQL相对于单机MySQL的损耗也能看出分片扩展带来的线性度提升。硬件配置上所有节点统一用16核32GB的云主机数据盘用SSD网络走内网VPC避免公网延迟干扰测试结果。操作系统是CentOS 7.9MySQL版本5.7TDSQL版本用的是当时最新的公开版本。这里有个经验评估分布式数据库的时候一定要保证每个分片的硬件规格和单机基线一致否则测出来的性能差异无法归因——到底是分布式架构的损耗还是硬件规格不同导致的根本说不清楚。另外测试数据要尽量贴近真实业务。我直接导了一份线上业务的脱敏数据包含用户表、订单表、商品表、流水表总共大概10张核心表数据量在200GB左右。表结构里既有纯int主键的也有varchar业务主键的还有需要分表的超大流水表。这样测出来的兼容性和性能结果比用sysbench灌出来的假数据有说服力得多。2. 兼容性实测从MySQL迁移到TDSQL到底改多少代码兼容性是这次评估我最关心的维度因为直接决定了迁移成本。TDSQL对外宣称兼容MySQL协议但“协议兼容”和“语法全面兼容”是两码事。我的实测方法很简单把线上库的表结构、存储过程、常用SQL全部导出来在TDSQL上跑一遍看报多少错然后把应用层的Mapper XML和ORM生成的SQL全部抓出来逐个执行对比结果。2.1 SQL语法与数据库对象的兼容情况先说结论常规的DML、DDL语句基本无障碍。SELECT、INSERT、UPDATE、DELETE、JOIN、子查询、GROUP BY、ORDER BY、UNION这些核心语法TDSQL都能直接跑结果与MySQL一致。实际迁移中我们500多条Mapper SQL里只有不到10条需要微调这个比例比我预想的要低很多。但有几个点必须注意属于典型的“文档里写了但没人会认真看”的坑第一自增列不能当全局主键用。在单机MySQL里auto_increment配主键是常规操作。但在分布式架构下自增列只能在每个分片内保证唯一跨分片会重复。TDSQL虽然提供了全局自增的能力通过自增序列实现但性能上有限制而且在分布式事务里会有额外开销。我的建议是凡是需要全局唯一的业务主键都改成应用层生成的分布式ID雪花算法或号段模式或者用UUID。自增列保留用于排序、分页这种非主键场景倒问题不大。第二分表键shardkey必须提前设计好。这是TDSQL和单机MySQL最大的使用差异。建表时必须指定一个shardkey后续所有查询如果带上shardkey条件就能直接路由到对应分片执行如果不带就会变成全分片扫描性能天差地别。比如订单表我用order_id做shardkey按订单号查询是毫秒级但如果是按user_id查某个用户的所有订单就必须全表扫描。这个限制不是TDSQL独有的所有分布式数据库都这样关键是要在表结构设计阶段就把业务查询模式想清楚。第三跨分片JOIN、子查询和事务有性能红线。语法上支持但执行效率可能让你怀疑人生。比如A表和B表分片键不同两个表做JOIN的时候数据要拉到一个节点上再做关联。数据量小时还凑合数据量一旦上去这个操作的代价就是灾难级的。我的经验是优先把经常一起查询的表设计成相同的shardkey让关联发生在同一个分片内TDSQL称之为“亲和性表”或者干脆在应用层做数据组装。2.2 事务与隔离级别分布式事务没你想的那么可怕TDSQL支持分布式事务默认隔离级别是读已提交RC这点和MySQL默认一致对大部分业务来说无感。我专门测了跨分片事务的一致性启动一个事务分别往两个分片上的表插入数据手动kill掉其中一个分片节点再提交事务。结果是另一个分片的写入也回滚了没有出现“一半提交一半没提交”的脏数据。这个表现说明分布式事务的原子性是靠谱的底层用的是两阶段提交2PC 全局时间戳的方案。但要注意性能。跨分片事务的提交延迟比单分片事务高实测数据大概是单分片事务的1.5到2倍。如果业务里有大量跨分片事务一定要评估清楚对整体QPS的影响或者尽量从业务设计上避免——比如把需要强一致的写操作都收敛到同一个分片内。隔离级别方面TDSQL不支持可重复读RR只支持读已提交RC。对于从MySQL默认RR迁过来的业务这个问题不大因为现在主流互联网业务基本都是RC。但如果有依赖RR场景的报表类查询比如事务内多次读取要求结果一致就要注意改造否则可能出现结果漂移。2.3 索引、字符集与存储过程容易被忽略的细节索引方面TDSQL支持普通索引、唯一索引、联合索引和MySQL基本一致。但有个坑唯一索引必须包含shardkey。原因很好理解——如果唯一索引不包含分片键数据库就没办法在写入时快速定位到唯一性校验的目标分片只能全分片检查性能开销极大而且在高并发下会出现并发冲突。这个限制在建表时就要遵守不然后面改起来很痛苦。字符集方面TDSQL支持utf8、utf8mb4线上utf8mb4的表直接迁移没问题。排序规则collation也基本兼容但不同版本之间默认值有差异迁移后最好检查一遍建表语句里的collation是否和原库一致避免出现排序结果不一致的问题。存储过程和触发器TDSQL支持创建和调用但有一些限制——比如不允许跨分片访问、不允许在存储过程中动态拼接表名实际我这轮测试里把线上100多个存储过程全部导入有4个因为跨分片访问报了错需要改写。我的建议是能不用存储过程的尽量不用这个玩意儿在分布式数据库里维护成本高而且一旦涉及数据迁移和分片调整排查问题非常痛苦。3. 运维能力评估集群运营过程中的真实体验数据库选型不能只看性能和兼容性运维能力直接决定了产品上线后DBA团队累不累、事故概率高不高。这一趴我重点测了监控告警、备份恢复、扩缩容三个运维核心场景。3.1 监控告警体系能一眼看到集群健康状态吗TDSQL自带的赤兔管理平台相当于整个集群的运维驾驶舱。先说优点集群拓扑一目了然分片状态、主从关系、延迟情况、存储水位全部可视化展示这点比纯手工运维MySQL强太多。我实际用下来的核心监控指标包括监控项查看位置告警阈值建议CPU使用率节点监控大于80%持续10分钟QPS/TPS集群监控按业务峰值留30%余量慢查询数慢日志分析单节点大于100条/5分钟主从复制延迟分片监控大于5秒持续1分钟磁盘使用率节点监控大于70%提前扩容连接数节点监控大于80%上限需要批评的是赤兔平台默认的告警模板偏保守很多指标默认不开启告警。我遇到过磁盘使用率到了85%都不告警的情况后来发现是没配置。所以上线前一定要逐项核对告警规则别依赖默认配置。这个经验适用于所有云数据库产品不是TDSQL特有的问题。另外TDSQL的慢查询日志是独立收集的可以在平台里直接按分片查看比单机MySQL的slow log好用。利用这个功能我在压测阶段定位了好几条隐藏的跨分片扫描SQL都是在开发环境跑得快、生产环境数据量大之后才暴露的问题。3.2 备份恢复实战关键时候别掉链子备份恢复是我每次选型必测的项目因为平时用不到出了事故才见真章。TDSQL支持物理备份和逻辑备份可以在平台上一键发起。我实际测了两个场景场景一误删数据恢复。模拟了一张业务表被delete误删通过备份集恢复到指定时间点。整个过程大概40分钟200GB数据量恢复出来的数据稽核无缺失。有一个操作细节值得分享TDSQL的备份文件是保存在腾讯云COS上的恢复时需要指定COS路径恢复之前务必确认COS的读写权限和网络连通性否则会恢复失败。场景二全集群容灾演练。我把整个集群的数据节点全部停机然后从备份集重建了一个全新的集群。这个操作不是TDSQL自动完成的需要手动创建新集群、导入配置、恢复数据、重新挂载proxy节点耗时大概3小时。整体流程可操作但对DBA的要求比较高需要熟悉整个架构。我的建议是每个季度至少做一次完整的恢复演练而且要换人做——因为只有不同的人都按文档能恢复成功才算真的靠谱。3.3 扩容缩容分布式数据库的核心价值所在扩容能力是分布式数据库相较于单机MySQL的核心优势我必须实测。测试场景集群从3个分片扩展到6个分片观察数据迁移过程对业务的影响。实际操作下来TDSQL的扩容流程是在管理平台上发起扩容 → 自动创建新的分片节点 → 数据自动重新均衡分布。整个扩容过程中业务读写不受影响只有部分数据在迁移时会略有延迟上升。我记录了数据500GB数据从3分片扩展到6分片耗时约2小时。扩容期间业务读写QPS稳定P99延迟从12ms上升到30ms左右扩容结束后恢复到10ms。有一个细节要注意扩容期间不要执行大事务和批量DDL否则会和数据迁移竞争资源可能拖慢扩容进度甚至报错。缩容也一样支持但操作的频率远低于扩容我只做了功能验证没有实际业务缩容。从运维角度看这个弹性扩缩容能力确实比自建MySQL中间件的方案省心太多至少不用自己写迁移脚本、不用停机窗口、不用手工校验数据一致性。4. 性能压测benchmark数据与调优方向性能是大家最关心的维度也是测试耗时最长的一部分。我用了两种方式一种是用标准工具sysbench做可控基准测试另一种是用真实业务SQL做混合场景测试两者结合才敢下结论。4.1 压测方案设计与参数选择sysbench压测我跑了四类经典场景只读、只写、读写混合、复杂查询含join和group by。每个场景跑30分钟预热5分钟收集中间10分钟的稳定数据。并发数从50逐渐加到200、500。测试命令大概长这样# 准备数据16个表每表100万行 sysbench /usr/share/sysbench/oltp_common.lua \ --mysql-hostx.x.x.x --mysql-port15001 \ --mysql-usertest --mysql-passwordxxx \ --mysql-dbtestdb \ --tables16 --table_size1000000 \ --threads50 --time1800 --report-interval10 \ prepare # 跑只读场景 sysbench /usr/share/sysbench/oltp_read_only.lua \ --mysql-hostx.x.x.x --mysql-port15001 \ --mysql-usertest --mysql-passwordxxx \ --mysql-dbtestdb \ --tables16 --table_size1000000 \ --threads200 --time1800 --report-interval10 \ run真实业务SQL测试的方式是把线上应用的SQL日志抓下来按实际调用比例重放直接用JMeter压测网关接口让请求穿透到数据库层。这样得到的数据比sysbench更接近真实表现但缺点是很难隔离数据库本身的瓶颈——如果应用层或网络有问题数据库测出来的数据就不准。所以两种方式要配合使用互相验证。4.2 实测数据解读分片扩展到底给你带来了什么先看sysbench的结果。以读写混合场景、200并发为例环境QPSTPSP99延迟(ms)单机MySQL 5.718500120028TDSQL 单分片17000110030TDSQL 三分片46000290019这组数据有几个非常值得注意的点第一TDSQL单分片的性能相比单机MySQL有微弱损耗。QPS大概下降了8%这个损耗主要来自代理层的转发开销和分布式事务的时间戳获取。完全可以接受毕竟多了一层分布式调度能力。第二三分片带来的扩展比在2.7倍左右不是完美的3倍线性扩展。原因有两个一是部分聚合查询和跨分片操作在分片变多之后反而需要更多的协调开销二是测试模型不是完全分布均匀的热点数据集中在某些分片上。这个结果在分布式数据库里属于正常水平但也说明一个真相——三节点就能到完美线性扩展属于理想情况真实业务大多在2倍到2.5倍之间浮动。第三分片变多之后P99延迟反而下降了。这个观察很有意思。原因是并发请求被分散到更多分片上单个分片的负载降低队列排队时间减少。所以分布式数据库的价值不仅是提升吞吐上限还能在大并发下保持更稳定的延迟。4.3 性能瓶颈定位与几个有效的调优动作压测过程中遇到的第一个瓶颈是连接数。TDSQL默认的最大连接数设置得比较保守应用侧连接池一开大直接触达连接数上限新的连接请求被拒绝。处理方式是调大max_connections同时把proxy层的连接空闲超时时间调短及时回收无效连接。第二个瓶颈是单分片的热点问题。有张订单表按order_id做shardkey但某几个头部商家的订单量特别大导致特定分片的写入压力远高于其他分片。这种场景下单纯加节点解决不了问题因为热点数据始终落在同一个分片上。我的方案是把订单表改成按user_idorder_id的组合键做shardkey让同一个用户的订单尽量分散到不同分片缓解热点。第三个值得说的优化是批量写入。如果业务需要批量插入数据尽量用一条INSERT语句插入多行而不是循环执行单行INSERT。TDSQL对多行批量插入有专门优化性能差距可以达到5倍以上。这个经验在压测阶段帮了大忙因为我们灌数据的时候一开始是逐行insert速度极慢改成批量insert之后灌数据的效率直接起飞。性能调优表基于实测调优项操作效果连接数限制调大max_connections调短proxy空闲超时避免连接拒绝热点数据调整shardkey字段组合分散热点分片压力批量写入改用多行INSERT写入性能提升5倍以上慢SQL定位跨分片扫描改写SQL带shardkey关键查询耗时降低90%参数调优调大innodb_buffer_pool_size到物理内存70%读写整体提升约20%5. 常见问题与避坑实录这一节把我这轮评估里实际踩过的坑、以及同行业务迁移TDSQL时普遍遇到的问题做个整理都是花时间换来的经验。5.1 高频问题排查速查表问题现象可能原因排查思路解决方法查询特别慢但单分片数据量不大SQL没带shardkey查看慢日志是否全分片扫描改写SQL强制带shardkey条件应用报“分布式事务冲突”多个跨分片事务并发操作同一批数据查看事务阻塞监控业务侧加分布式锁减少冲突扩容后部分查询结果不一致数据还在迁移中查看数据均衡状态等迁移完成后再做数据一致性校验备份恢复失败COS路径权限配置错误查看恢复任务的错误日志检查COS访问权限和网络连通性连接数告警频繁proxy连接泄漏查看应用连接池配置调小连接池闲置超时及时回收建表报错“shardkey类型不支持”用了float/double做分片键查看错误信息换bigint或varchar类型主从延迟持续放大大事务或批量DDL查看分片主从延迟监控拆分批处理避免事务过大5.2 迁移过程中容易忽略的三个风险风险一字段类型隐式转换导致路由失效。如果分片键字段是varchar类型但应用传入的参数是intMySQL在比较时会把varchar转成int导致路由计算结果不一致请求被发错分片。这个问题在单机MySQL里顶多是性能略降放到分布式数据库里就是全分片扫描的灾难。迁移后一定要检查应用传参类型和表字段类型是否严格一致。风险二全局唯一性依赖数据库自增序列。有个业务表原本用自增ID当业务主键迁移之后发现多个分片写入了重复ID。前面提过TDSQL的全局自增需要通过特定方式实现如果你没配置正确自增列只在分片内唯一。这个问题最容易在迁移初期被发现但也最容易在迁移设计阶段被忽略。我强烈建议所有上TDSQL的表业务主键全部改成应用层生成的分布式ID不要依赖数据库自增。风险三容量规划未考虑分片间不均衡。很多团队做容量规划时是“总数据量除以分片数”然后按平均值配磁盘。真实业务里数据分布不可能完全均衡热点表、大字段表、归档数据都可能导致某些分片提前打满。规划时建议按“最大分片不超过均值1.5倍”来做容量冗余宁可多买一点空间也不要上线几个月后就要扩容。5.3 TDSQL与自建MySQL选型建议最后聊聊选型判断。如果你们的业务只是单库数据量不大、QPS平稳、没有快速增长的迹象那完全没必要上分布式数据库单机MySQL加读写分离就够了这是最省成本的方案。但如果你符合下面任何一个条件就值得认真考虑TDSQL这类产品单表数据量超过5000万行DDL和执行性能都开始恶化。写入QPS持续超过单库上限并且未来3年还有增长预期。团队已经明确要上微服务拆分数据库需要按业务维度水平扩展。不想自己维护分库分表中间件和自研数据迁移工具链。TDSQL不是万能的它也有自己的限制跨分片事务性能、数据类型限制、运维复杂度和成本。但作为从MySQL生态平滑演进到分布式架构的路径它在兼容性和运维体验上的完成度确实比自建方案或者纯中间件方案高不少。选数据库没有绝对的最好只有是否匹配你的业务阶段和团队能力。对于大多数MySQL存量业务来说TDSQL给出的是一条务实、平滑的升级路径。