如果你最近在评估分布式数据库大概率绕不开 TDSQL。我去年深度参与了一个从 MySQL 单机迁移到 TDSQL 的项目团队纠结的核心问题就三个兼容性到底能做到什么程度、运维体系能不能接得住、性能会不会因为分布式而大打折扣。这篇文章把这些维度的评估过程、压测数据、踩坑细节完整记录下来希望对正在做数据库选型和迁移的 DBA、运维工程师、架构师有实际帮助而不是让你再去翻一遍官方文档。TDSQL 作为金融级分布式数据库设计目标里兼容、运维、性能三者是互相牵制的。很多人以为分布式数据库只要数据能存进去、SQL 能查出来就够真正跑起来才发现问题往往出在那些平时根本不在意的细节上。所以我把文章重点放在“实际评估中会碰到的关键点”而不是罗列产品特性。1. 分布式数据库选型为什么兼容性是绕不开的第一关1.1 从 MySQL 迁移到 TDSQL你要面对的不只是语法差异先说结论兼容性评估做得越早后面踩的坑越少。我们在项目初期做过一次线上 SQL 采集把业务库的所有 SQL 日志捞出来在 TDSQL 测试环境里回放了一遍。回放结果让我很意外真正的问题不是高深的分布式特性而是一堆“以前在单机 MySQL 里根本不会报错”的写法。比如自增列。单机 MySQL 里用 AUTO_INCREMENT 是很自然的事情但是到分布式环境自增列如果还是按单节点连续生成就会成为写入瓶颈。TDSQL 支持全局自增但自增值的语义变了它保证全局唯一不一定保证严格连续递增。业务代码如果依赖“插入后 id 必须连续”或者“用 id 大小判断先后顺序”迁移后会出逻辑问题。再比如 SQL_MODE。TDSQL 对 MySQL 的严格模式、非严格模式处理并不完全一致。单机 MySQL 里很多线上库用的是宽松模式插入非法日期时 MySQL 会告警而不是报错数据照样写进去。TDSQL 的默认校验会更严格这直接导致迁移测试时出现大量插入失败。这类问题不是“语法不兼容”而是“行为不兼容”不实际跑数据根本发现不了。还有存储过程、触发器、事件调度器。如果业务里大量使用存储过程迁移前一定要逐个审核。TDSQL 对存储过程的兼容情况整体不错但涉及游标、动态 SQL、嵌套事务、异常处理的细节和 MySQL 版本不同会有差异。我的建议是不要相信“系统提示兼容就一定能跑”做一个语法审核脚本把存储过程里的关键字、系统函数、系统表查一遍比人工肉眼看好得多。1.2 TDSQL 到底兼容了什么协议层、语法层、生态层兼容性可以拆成三个层面看网络协议、SQL 语法、周边生态。网络协议层面TDSQL 支持 MySQL 协议这意味着常见驱动、连接池、ORM 框架基本上都能接入。Java 里的 JDBC、Python 里的 PyMySQL、Go 的 go-sql-driver这些都可以直接连。项目里我们用 HikariCP 连接池、MyBatis-Plus基本没遇到连接层的兼容问题。所以协议层相对省心但要注意连接方式TDSQL 通常会有接入网关或者说 proxy 组件应用连接的是 proxy 地址而不是某个分片地址。这个架构差异一开始容易被忽略导致连接数管理、超时设置和单机 MySQL 不一样。SQL 语法层面TDSQL 做了大量 MySQL 兼容工作包括常用 DDL、DML、查询语法、内置函数、事务隔离级别。但兼容不等于一模一样。比如跨分片 JOINTDSQL 能执行但代价可能高再比如某些 INSERT ON DUPLICATE KEY UPDATE 语法在分片表上的语义跟单机不同。数据库没有办法替你判断一条 SQL 的业务意图所以兼容性的真实水平要建一张“SQL 兼容矩阵”测试常用语句、语句执行的正确性、执行计划是否走分布式节点下推、返回结果是否和 MySQL 一致。周边生态层面TDSQL 兼容 MySQL 的 binlog 格式这个对实时数仓同步、缓存同步、Canal 订阅这类场景特别关键。我们的业务里用到了 Canal 从 MySQL 同步数据到 Kafka切换到 TDSQL 后需要验证 TDSQL 输出的 binlog 是否包含足够完整的数据变更信息、位点是否连续、切换期间会不会丢数据。这里要特别小心TDSQL 的 binlog 格式和原生 MySQL 在一些取值细节上可能有差异比如表名大小写、库名限定、DDL 事件的表述Canal 版本太老可能会解析失败。建议先升级到较新的 Canal 版本再在测试环境完整跑一遍大事务、批量 DML、DDL 变更确认同步链路稳定后再切生产。1.3 迁移前怎么快速判断兼容风险我个人的迁移前检查套路可以分成四步。第一步是对象检查导出一份全量 schema包括表结构、索引、约束、自增列、字符集、排序规则对比 TDSQL 的支持范围。第二步是 SQL 行为采集把线上慢日志、审计日志、全量 SQL 抓出来按 SQL 类型归类、去重、统计频率然后在 TDSQL 测试实例上回放特别关注高频 SQL 的执行计划和返回结果。第三步是数据抽样校验选几张有代表性的业务表按不同数据量、不同分片键分布做全量数据比对和业务查询结果比对。第四步是应用联调让开发团队直接用 TDSQL 连接测试环境跑一轮核心业务流程别只做数据校验因为很多时候应用日志里已经报了 SQL 错误但数据库层面看着没事。这一步最忌讳的是“只看错误日志”。很多兼容性问题不是报错而是“能跑但结果不对”。比如一些字符串比较、大小写排序、时区处理、浮点精度看起来没报错但是数值有微小偏差。所以结果校验必须做而且要用同一份输入在 MySQL 和 TDSQL 上各跑一遍做 diff。我们在项目里发现过几个类似问题最后基本靠数据 diff 才翻出来。2. 运维视角TDSQL 的分片架构让运维习惯发生了哪些变化2.1 扩容、缩容、DDL 变更DBA 最需要重新适应的事升级到分布式数据库之后DBA 最明显的感觉是以前一台机器上的事情现在变成了一堆分片上的事情。有一个核心概念必须建立起来——分片键shard key。TDSQL 数据分布在多个分片上路由规则由分片键决定。运维层面看分片键选得好不好不仅影响性能还影响后续扩容的数据搬迁量。扩容操作在单机 MySQL 时代基本不需要考虑但在 TDSQL 里扩容通常意味着数据要从旧分片搬迁到新分片。TDSQL 提供在线扩容能力理论上业务无感知但实际扩容过程中会有数据搬迁带来的额外负载对磁盘 IO、网络带宽、CPU 都有冲击。我建议在业务低峰期做扩容而且扩容前要做一次全量巡检确认各分片的数据分布是否均匀。如果分布不均匀扩容后可能仍然存在热点。这里可以类比搬家你只是多租了一间房但之前东西全堆在客厅不重新整理新房间还是空着问题没解决。DDL 变更也要重新适应。单机 MySQL 即使有锁表问题至少范围可控分布式数据库的 DDL 会下推到所有分片执行耗时更长且更依赖在线 DDL 特性。TDSQL 支持在线 DDL但并不是所有操作都完全在线。比如大表加字段、加索引虽然能在线执行但还是建议先在一张小表上验证一次确认耗时和锁行为再上生产。如果建了索引但业务没走到反而白白增加存储和写入开销。运维上还要注意分片间数据分布是否均匀。常见问题是取模算法下业务没有真正分散导致某个分片数据量远超其他分片。巡查看什么核心指标是各分片的数据量、活跃连接数、QPS 分布、磁盘占用。我习惯写一个巡检脚本定时拉取所有分片的监控指标计算出最大值和最小值的比值。如果某些分片数据量差异超过 1.5 倍就要考虑分片键选择是否合理或者是否需要做数据重分布。2.2 高可用与容灾强同步复制不是开了就完事TDSQL 主打高可用底层通过一致性协议或强同步复制来保证主备数据一致。这个机制和 MySQL 传统异步复制有很大区别。传统 MySQL 主从切换丢数据是常态业务能接受秒级延迟、分钟级恢复TDSQL 这类金融级数据库更强调 RPO 趋近于零也就是说主库故障时不丢数据。但是强同步是有代价的。每次事务提交都要等备机确认落盘这会让单次事务的响应时间增加。如果主备部署在跨机房、跨地域的网络环境下网络延迟会直接加到事务路径里。很多人压测后发现 TDSQL 性能比单机 MySQL 低第一反应是数据库不行但如果没有检查强同步部署拓扑那可能冤枉了数据库。同机房内强同步的额外开销其实可控但跨地域部署一定要做好网络延迟评估。高可用切换还有几个关键运维动作定期做切换演练。这个太重要了。不要以为 TDSQL 控制台显示“主备状态正常”就万事大吉。我们做过一次故障切换演练模拟主节点宕机结果发现监控告警的 IP 还是旧的主节点地址业务连接池没有及时重连切换花了比预期更长的时间。所以每次切换演练后要检查应用连接到的节点地址是否更新、监控告警是否指向新主节点、临时本地账本有没有丢失。最好形成一份切换后检查清单逐项勾选。容灾方面TDSQL 支持一主多备、跨可用区部署。具体怎么部署取决于业务 RPO/RTO 目标。如果要求故障时数据零丢失那就得保证强同步如果业务可以接受少量丢数据异步备库的容灾能力也够用。关键是把“强同步”“异步备”和业务容忍度匹配起来。不要所有实例都强制同步那是对性能的无谓消耗。2.3 日常巡检盯哪些指标、用什么工具快速定位分布式数据库的巡检维度比单机多但底层逻辑不复杂分布式系统如果每个节点都健康整体大概率健康如果某个节点负载异常高整体就会波动。日常巡检我主要看四类指标。第一类是集群节点状态主备关系、节点在线状态、分片状态是否正常。如果出现分片只读、节点重建、同步中断要立刻处理。第二类是性能指标包括各分片的 CPU、内存、磁盘 IO、QPS、连接数、慢查询数量、主备延迟。第三类是存储容量特别是各个分片的数据增长趋势磁盘使用率超过 70% 就要准备扩容量了别等 90% 才着急。第四类是异常事件比如大事务、长事务、死锁、锁等待、DDL 卡顿这些在日志里通常有记录。运维人员如果习惯用 Linux 命令行排查问题这套思路在 TDSQL 运维里依然有效。比如遇到“IO 性能明显下降了”第一步先在数据库节点上用 top、iostat、iotop、sar 这些 Linux 常用命令确认瓶颈在磁盘还是网络而不是直接进控制台看图表。如果 iostat 显示 util 接近 100%说明磁盘真的忙如果显示 waittime 高但不忙可能就是 IO 队列配置问题或者文件系统问题。再配合数据库内部的慢日志和等待事件基本能定位到具体节点。这里想提一个运维工具化思路。我在做巡检时不会天天打开控制台而是把所有监控 API 和数据采集能力串成一个自动化巡检脚本每天定时跑一遍把异常指标推到告警群。热词里提到“运维工具箱”其实就是这个逻辑把重复琐碎的操作脚本化、参数化减少人工判断出错的可能。TDSQL 的管控平台已经提供了不少能力但跨系统整合还是要自己动手。3. 性能评估基准测试数据背后的真实含义3.1 分布式数据库性能瓶颈模型先于压测建立谈性能之前先建立分布式数据库的瓶颈模型。理解了这个模型就不会被压测数据牵着鼻子走。单机 MySQL 的性能瓶颈主要在 CPU、内存、磁盘 IO优化思路比较直接。分布式数据库多了一层网络和协调开销一条 SQL 到达 proxy 之后需要路由到对应分片多个分片参与时还需要合并结果、处理分布式事务。因此 TDSQL 性能评估至少要考虑四个环节应用到接入层proxy的延迟、proxy 路由开销、分片节点自身处理能力、跨分片协调开销。这个模型解释了为什么同样的硬件TDSQL 跑单分片表可能接近 MySQL但跨分片 JOIN 或者分布式事务会明显变慢。所以表面上看“性能下降”追根溯源其实是访问模式变了。评估 TDSQL 性能时不能只测一个 Total QPS要拆成不同场景分别测纯单分片点查、单分片范围查、跨分片聚合、跨分片 JOIN、写入、事务。另外要提“大量使用算子对硬件性能的挑战”。分布式数据库执行一条复杂 SQL 时可能涉及排序、哈希、分组、连接等算子这些算子需要在内存里完成中间计算。如果数据量很大内存不够就会落到磁盘性能断崖式下降。因此在压测复杂查询时要同时观察内存和临时文件不只是看执行时间。这条经验对 TDSQL 同样适用。3.2 sysbench/TPCC 压测从脚本、参数到结果解读压测工具选择上我自己常用 sysbench 和 TPCC 两类。sysbench 适合做基础性能摸底验证单分片点查、写入、聚合、并发能力TPCC 这类业务模型测试适合评估接近真实交易场景的表现。热词里有“benchmark 测试 c 性能”虽然原意不同但数据库压测同样要重视测试代码本身的性能开销。如果压测工具成了瓶颈测出来的结果就完全不可信。压测前我会先做一轮“不连数据库只跑框架”的空跑测试确认工具本身能打到目标并发。sysbench 压测的一个基础参数模板--oltp-point-selects决定点查比例--oltp-dist-type决定只读/混合--threads决定并发数--tables和--table-size决定数据量。数据量要设计好单机压测可能几千万行就够分布式压测至少要保证每个分片都有足够数据并且分布均匀。TDSQL 表有分片键sysbench 建表时如果不指定分片键默认可能全部路由到一个分片压测结果就变成“单分片性能”不能代表集群能力。压测策略建议先测小并发低负载比如 8、16、32 连接观察延迟再陡增并发到 64、128、256看吞吐量是否线性增长、延迟是否爆炸。如果并发从 32 加到 64QPS 翻倍但 P99 延迟高了很多那说明系统进入瓶颈区。TDSQL 压测后要重点看三组数据整体 QPS、整体 TPS、P95/P99 延迟。只报平均延迟没有参考意义因为分布式系统里长尾请求最容易影响用户体验。TPCC 压测更贴近核心交易系统它模拟订单、库存、支付、物流等场景事务模型复杂包含大量跨表操作。结果解读时最重要的不是最终 tpmC 数字而是这个数字是在什么硬件、什么副本策略、什么并发下跑出来的。同样硬件条件下单副本和强同步多副本的 tpmC 可能差 30% 以上。如果拿官方压测数据和自己的测试环境比较一定要把硬件、副本、分片数对齐。3.3 压测后的性能边界读扩展、写扩展与事务开销从压测结果看 TDSQL 的扩展能力我总结了三个规律。第一读扩展通常比写扩展更容易实现。分布式数据库可以把查询分散到多个分片并行执行理论上分片越多读性能越高。但“读扩展”不等于“所有查询都能线性扩展”点查只要路由正确确实接近线性但全表扫描、大范围查询、跨分片聚合是所有分片都要参与计算性能受限于最慢的那个分片。第二写扩展受制于分片键设计。如果分片键选得好写入可以均匀分散到各分片扩展性接近线性如果分片键选得差所有写入都集中到同一个分片集群扩展半天也只是多了一堆空闲节点。所以压测写入前一定要检查数据分布。我常用一个脚本统计插入后的数据量分布如果某个分片数据量远高于其他分片就说明分片键没有把数据打散。第三分布式事务有明显开销。压测中把事务从单分片事务改成跨分片事务TPS 可能会下降一半甚至更多。这不是缺陷而是分布式一致性的固有代价。业务设计如果能把大部分事务控制在单分片内TDSQL 的瓶颈就和单机差不了太多反之如果业务大量依赖跨分片事务分布式数据库的优势会被抵消。这也告诉我们TDSQL 性能调优不完全是数据库的事应用侧的表结构设计和事务拆解同样关键。4. TDSQL 性能调优的关键动作从数据建模到 SQL 改写4.1 分布式键怎么选直接决定性能上限这部分是实战中最有价值的部分。分片键也叫分布式键shard key它的选择直接影响数据分布、事务路由和查询效率。分片键选择的第一原则是“高基数且均匀”。比如订单系统的分片键选 device_id 可能不好因为某些设备 ID 的量级不均匀选 user_id 通常更合理因为用户分布相对均匀。不要选性别、状态码这种只有几个取值的字段否则数据会集中在很少的几个分片上。第二原则是“高频访问字段优先”。如果业务里最常按用户查询订单那 user_id 就是很好的分片键查询请求可以直接路由到对应分片不做广播。第三原则是“尽量把高频事务控制在单分片内”。比如订单和订单明细表都用 user_id 作为分片键那么同一个用户下的订单和订单明细就会落在同一个分片上订单主表和明细表之间的 JOIN 就可以在单分片内完成避免跨分片 JOIN。这一点在建模时就要想好等上线后再改分片键成本很高。业务里经常出现“按主键查询”和“按用户查询”两个需求同时存在的场景。如果主键选了全局唯一 ID而用户 ID 可能是分片键那么按主键查询时数据库需要先路由到正确分片吗这取决于 TDSQL 是否支持全局二级索引。如果不支持一次主键查询可能变成广播查询扫描所有分片性能下降。所以设计表结构时除了分片键还要考虑二级索引的全局支持情况。TDSQL 对全局索引的支持需要单独评估不要想当然。4.2 执行计划、索引设计与 SQL 改写思路性能调优逃不开执行计划。TDSQL 的 explain 能看到分布式执行计划和 MySQL 的 explain 不太一样。它会明确标出哪些操作下推到存储节点执行哪些操作要在 proxy 层做汇总或关联。判断一条 SQL 写得好不好最关键的是看有没有出现“全分片扫描”或者“proxy 层大规模数据合并”。举个例子订单表按 user_id 分片业务要查某个用户最近的订单SQL 如果写成WHERE user_id 123 ORDER BY order_time DESC LIMIT 10数据库能直接路由到该用户所在分片走二级索引或者分片内排序很快。但如果业务需求是“查最近所有订单”没有 user_id 条件那这条 SQL 就要在所有分片上都执行再把结果汇总排序数据量和耗时都会明显增加。这时就要评估业务场景能不能接受不能接受就要换一种设计比如增加一个按时间聚合的汇总表。索引设计和单机 MySQL 类似但多了分片键的概念。每个分片内部索引照样要建但要注意避免创建与分片键方向不一致的大范围索引。比如分片键是 user_id如果业务里大量查询是“按商品查订单”那最好考虑用商品维度建一个全局索引表或者做一张宽表冗余数据而不是指望在分片表上加一个普通索引就能解决问题。SQL 改写方面我见过最常见的问题有两个一个是SELECT *然后只取一两列造成无谓的网络传输另一个是关联查询子查询嵌套太深分布式执行计划直接劣化。好一点的写法是尽量把过滤条件下推到子查询里减少中间结果集。Join 的时候尽量让小表做驱动表。还有就是要避免在分片键上做运算比如WHERE user_id 1 100这种写法会破坏路由导致查询变成广播应改为WHERE user_id 99。4.3 硬件与部署层面的调优手段从 Linux 到数据库参数性能调优不只有 SQL 层面硬件和部署也会直接决定上限。TDSQL 集群通常部署在物理机或虚机上网络、磁盘、CPU 的配置不能太差。我们压测时发现当并发上去之后瓶颈经常不在数据库进程本身而在网络软中断、磁盘队列、虚拟化层的 CPU steal 上。如果使用的是云主机可以先用top检查%steal如果这个值长期超过 5%说明宿主机的 CPU 争抢严重再调数据库参数也没用还不如换规格。磁盘 IO 方面强烈建议使用 SSD/NVMe。TDSQL 的强同步对磁盘写入延迟敏感机械盘很难撑住高并发事务。另外文件系统挂载参数、IO 调度器、内存大页等系统级配置也会影响稳定性。这部分可以借助 Linux 常用命令排查比如dmesg看有没有磁盘错误vmstat看内存交换mpstat -P ALL看 CPU 是否均衡pidstat看数据库进程的资源占用。数据库参数层面TDSQL 很多参数保持了 MySQL 习惯比如innodb_buffer_pool_size、max_connections、binlog_format、sync_binlog。调优原则是不要一次性改一堆参数每次只改一个压测前后对比并记录。理论上调优前要有基线否则改完不知道是哪个参数起了作用。还要注意参数在 proxy 层和存储层可能分别生效有些参数在控制台改了但没 apply也会导致压测结果不对。关于算子对硬件挑战我再说一点。复杂 SQL 涉及大量排序、分组、JOIN 算子通常可以在分片内并行执行。但是合并结果时如果有大量数据在 proxy 层进行GROUP BY或者ORDER BYproxy 的内存消耗会非常大。压测时如果发现 P99 延迟突然增长要去看 proxy 的 GC 情况、内存使用、临时落盘情况。如果临时文件增长明显说明算子内存不够要么优化 SQL 减少返回行数要么调大 proxy 内存上限要么给集群扩容。硬件和 SQL 一起调才能发挥出 TDSQL 的真实性能。5. 兼容性避坑实录从测试环境到生产迁移的完整复盘5.1 最容易踩的坑自增列、隐式转换、事务隔离级别先说自增列。TDSQL 支持全局自增但我在测试环境里发现过“自增列不是严格递增”的现象。原因很简单分布式环境下的自增 ID 生成器为了保证高并发会采用分段或批量生成模式。为了让同一分片内数据不冲突ID 段可能跳跃。业务如果依赖严格顺序比如用 ID 作为排序依据那结果就可能和预想不一样。我建议业务侧不要依赖 ID 的大小排序如果需要排序用业务时间字段。如果非要连续 ID需要单独设计一套发号器而不是指望数据库自增。再说隐式转换。MySQL 里有很多隐式类型转换的 SQL 写法比如把字符串列和数字比较或者把 varchar 字段和 int 类型参数拼接。在单机 MySQL 里可能能跑但在 TDSQL 里隐式转换经常导致索引失效、路由失效。我们踩过的一个真实案例订单表分片键是 user_id但是业务在 SQL 里传入了userId字符串虽然参数值是 123类型是 varchar和表里的 bigint 列比较时数据库可能无法正确提取分片路由信息导致广播查询。解决办法是应用层强类型化所有分片键值都用数字类型传入SQL 里不要做无谓的转换。事务隔离级别也值得注意。MySQL 默认隔离级别是 REPEATABLE READTDSQL 支持的隔离级别和默认值可能跟业务预期不一致。项目初期我们没改隔离级别结果一个报表统计场景出现数据可重复读和预期不一致的问题。排查后才发现默认隔离级别差异。迁移后要检查每一类业务的隔离级别需要并在连接参数或者事务里显式指定不要依赖默认值。5.2 跨分片事务和 SQL 限制亲测后才会懂TDSQL 对跨分片事务是支持的但性能有退化。我们在压测中发现一个包含 3 个分片参与的事务TPS 比单分片事务低了大约 40% 到 50%延迟也明显上升。这并不是说不能用而是要在模型设计时尽量避免。比如一个购买流程涉及用户表、订单表、账户表如果三张表都用 user_id 作为分片键那么同一个用户的操作基本都在一个分片内完成不需要跨分片事务。如果把订单表分片键设为 order_id账户表分片键设为 user_id那一次购买操作就必须跨分片事务开销一下就上来了。另一个限制是跨分片查询。TDSQL 支持跨分片 JOIN、子查询、分布式聚合但这些操作通常会把结果汇总到 proxy 层再处理。如果表数据量很大结果集也大查询会非常慢。我们在测试环境跑过一个多表 JOIN 加 GROUP BY结果 2000 万行数据查询花了十几秒后来把 JOIN 改成两张冗余表的单表查询耗时降到 300 毫秒。这就是典型的“不是数据库不行而是你用分布式的思路去硬套单机的 SQL”。跨分片 DML 也有不少限制。比如 UPDATE 语句里如果修改了分片键值TDSQL 可能不允许因为分片键一变数据就要重新搬位置这相当危险。DELETE 时如果没带分片键条件会广播到所有分片执行低并发时没问题高并发下会拖垮集群。所以上线前要形成一个 checklist所有涉及分布式表的 SQL要么带上分片键条件要么明确评估过广播查询的代价。5.3 数据迁移与校验的实施流程数据迁移这块我们是先用 DTS 工具做全量迁移再跑增量同步最后做校验。全量迁移相对平稳但要注意大数据量时源库磁盘 IO 和网络带宽占用。建议全量迁移放在业务低峰期而且提前估算时间。数据量 100GB 和 1TB 的迁移时间差很远要预留足够的时间窗口。增量同步阶段最重要的就是追平位点。DTS 会提供一个延迟指标切换前必须等到延迟为 0 或者非常小。如果业务每小时都有大量写入增量同步延迟可能一直降不下来。这时候要检查迁移账号的权限、目标实例规格、网络带宽必要时暂停部分非核心批量任务给增量同步让路。校验环节不能省。我们用过行数比对和抽样校验后来发现还是不够因为行数一致不代表数据内容一致。最终使用了带哈希的校验方式对每条记录计算 checksum和源库比对。这里推荐用 pt-table-checksum 类似的工具思路但要注意网络和性能开销。TDSQL 分片表校验时要按分片键分批跑避免全部数据拉出来比对那样太慢。5.4 割接后的回滚策略与观察期割接前一定要准备回滚方案。我的做法是保留源 MySQL 实例至少两周期间不回收资源。割接后观察应用日志、慢查询、错误率尤其是连接池是否稳定、事务是否频繁回滚、所有定时任务是否都正常。同步链路不要急着断保留反向同步或者至少保留源端数据只读方便快速回滚。回滚不是简单把数据库切回去就行增量数据也要考虑。如果 TDSQL 上运行了一天产生了大量新数据回滚到 MySQL 之后怎么把这一天的新数据补偿回去需要提前想清楚。最稳妥的办法是部署一套反向同步工具把 TDSQL 的增量变化持续同步回 MySQL直到确认 TDSQL 稳定运行再停掉反向链路。不然割接后发现一个严重问题想回滚又丢失新数据会很被动。观察期内建议做几件事第一对比压测基线和实际业务的性能数据看有没有到达预期第二持续监控慢查询和错误日志把新出现的慢查询全部拉出来优化第三和开发团队确认线上功能没有遗漏特别是那些低频使用的管理后台、报表、导出功能平时不跑迁移后很容易被忽略。项目上线后前两周是问题高发期一定要有专人盯告警。回到我最早说的那个项目我们最终顺利上了生产但整个过程比预期多花了近两周时间就是因为兼容性问题在测试阶段没有完全暴露。事后复盘发现如果能更早做 SQL 回放和数据 diff很多问题可以在正式割接前解决。数据库选型评估没有捷径兼容、运维、性能这三件事每一项都得用最笨的方法去验证。希望这篇文章能让你在评估 TDSQL 的时候少走几步弯路尤其是那些只有实际踩过才会注意到的细节。