作为一个在数据库领域摸爬滚打过几年的开发者每次听到“上云”或者“平滑迁移”这几个字心里多少都会打鼓。最近我们团队刚好把一个核心的交易类系统从自建的MySQL经过几轮评估后迁到了腾讯云TDSQL MySQL版整个过程中最让我揪心、也最值得写点东西记录的就是兼容性。不是官方文档那种“99%兼容”的宏观结论而是开发者在写SQL、配连接、建表、上线时实实在在会撞上的细节。如果你也在评估TDSQL MySQL版或者正准备把自己的业务从MySQL迁过去这篇内容可以帮你少走不少弯路。先说结论TDSQL MySQL版对于绝大部分常规MySQL用法是透明的我们的应用连接串改个地址就能跑起来但一些分布式特性下的开发习惯必须按它的规则重新来。这篇文章我会从架构认知、SQL兼容细节、实际迁移适配流程到我们踩过的坑和排查思路一条线讲清楚。1. 先把TDSQL MySQL版的兼容性是什么说清楚1.1 它到底是个什么形态TDSQL是腾讯自研的一款金融级分布式数据库产品MySQL版自然就是兼容MySQL协议和语法的那个分支。它在物理上大概率不是一台实例而是一组组件的协作前面有接入网关Proxy有一组存储节点也叫SET还有负责调度和数据一致性的管理节点。但对开发者来说看到的就是一个MySQL协议的服务地址IP、端口、账号、库、表。这一点非常重要因为它意味着你的连接方式、驱动、ORM框架基本不用动。我们当时用的还是老一套Java技术栈MyBatis-Plus Druid连接池把JDBC URL里的地址换掉应用就起来了。客户端工具用Navicat、DataGrip连它体验也跟连MySQL一模一样。但是你这个“MySQL服务”底层可能已经变成了多个分片。每个分片在物理上又是一套独立的MySQL存储。你的表如果建成了分布式表数据会被按照分片键打散到不同的分片里。于是很多MySQL里“看起来没问题”的SQL在这里可能会执行得很慢甚至直接报错。这个形态决定了兼容性的第一个维度协议和基础语法兼容到不到位第二个维度分布式约束下你的SQL能不能写出高性能版本。1.2 兼容性为什么是迁移的第一道门槛我见过不少项目一开始觉得“反正兼容MySQL迁过去就行了”结果上线没几天就出幺蛾子某个报表SQL把整个代理节点内存吃满、某个更新语句因为没带分片键导致全表广播扫描、存储过程里一个跨分片的游标行为变得诡异。这些不是TDSQL不行而是很多开发者把“兼容”理解成了“完全一样”。对从自建MySQL迁过来的人“兼容”至少要分成三层看协议兼容MySQL客户端、JDBC/PyMySQL等驱动能不能正常连账号权限模型是否一致。语法兼容建表语句、CRUD、事务、存储过程、函数、排序、聚合这些能不能直接执行。语义兼容同样的SQL执行结果和性能是否大致符合预期特别是涉及跨分片、分布式事务、全局唯一性时。前两层如果做得不好连启动都过不去第三层如果没提前摸清业务流量一上来就现形。我建议所有准备迁移的团队把这三层都当成“待验证项”不要默认它就是好的。1.3 三种典型接入方式先搞清楚你的业务属于哪种TDSQL MySQL版并不是一上来就必须建分布式表。实际使用中我把它分成几种用法集中式场景表不设分片键相当于一个增强版的MySQL实例。适合数据量不大、并发可以接受、也没有水平扩展需求的小系统。分布式表场景关键业务表设置分片键数据自动打散支撑海量数据和高并发。适合交易、订单、用户类系统。混合场景热表用分布式表字典表、配置表用广播表或单表整体兼顾性能和灵活性。我们项目最终选的是第三种。分布式表承载订单和流水广播表承载地区、渠道、商品字典单表放系统配置。这个组合下来绝大多数日常SQL都命中单分片性能和兼容性问题被大幅缩小。所以第一步不是纠结SQL怎么写而是先把你的数据模型规划清楚。2. 开发侧最关心SQL和存储对象到底兼容到什么程度2.1 常规SQL语法日常单表操作的兼容体验先说大家最常用的部分。普通单表的SELECT、INSERT、UPDATE、DELETE只要你的查询条件里能带得上分片键也就是路由到单个分片那TDSQL MySQL版的表现基本就是一套高性能MySQL。我们当时把几万行代码里的常用SQL过了一遍这类语句几乎没有任何改动。单表不带分片键的查询也能执行但Proxy会把请求广播到所有分片然后做结果合并。数据量小的时候没感觉数据量大而且频繁执行消耗会成倍增加。所以官方文档里会反复提醒能带分片键就尽量带分片键。这个不是一句空话而是我们后续所有SQLReview的第一条军规。连表查询方面单分片内JOIN没问题跨分片JOIN能跑但是有限制。两个分布式表如果分片键相同TDSQL可以做到分片内先JOIN再汇总性能尚可如果分片键不同Proxy要把数据拉到中间层做关联数据量一大就危险。我们当时的做法是高频的跨主体查询全部改成应用侧拆两次查询或者干脆做成宽表后来上线跑得很稳。子查询和聚合函数上MySQL常见的COUNT、SUM、AVG、GROUP BY、ORDER BY都没问题Proxy会自动帮我们做分布式合并和再排序。但某些带LIMIT的复杂子查询分布式下可能会因为数据分散在各分片而出现结果不稳定的情况这类语句我们统一在开发规范里禁掉了改成分步查询。2.2 分布式带来的限制边界这是全文最关键的一节。TDSQL MySQL版对分布式表的SQL有一套明确的限制规则开发时必须清楚。第一类是更新删除必须谨慎处理分片键。对于分布式表UPDATE或DELETE如果能明确命中分片键条件执行效率最高如果不带分片键TDSQL会广播到所有分片执行。订单表删除一条数据如果你只按订单号删而分片键偏偏是用户ID那这条语句就会广播到全部分片扫描。小表无所谓大表多次执行就会拖垮整体性能。第二类是跨分片的唯一性约束做不到像单机那样简单。比如你想在用户表中对手机号建唯一索引而分片键是用户ID那么手机号字段就无法做全局唯一约束——因为不同分片不知道彼此的数据。TDSQL提供了全局二级索引能力能部分解决这类问题但我建议设计期就评估好能用分片键覆盖的业务唯一性就不要依赖全局索引。第三类是分布式事务不是免费午餐。TDSQL支持分布式事务底层有两阶段提交的机制保障跨分片一致性。但跨分片事务比单分片事务开销高而且对长事务更敏感。我们定的开发规范是事务尽量短单事务内尽量少跨分片核心大事务必须做幂等设计。毕竟任何分布式数据库都怕长事务TDSQL也不例外。第四类是自增主键的全局形态。如果你用AUTO_INCREMENT在TDSQL里它会被改造成全局唯一自增但自增值只在插入的时候保证唯一不保证按物理顺序连续递增。如果业务代码里依赖“自增ID连续”做逻辑一定会有坑。我们统一改成分布式ID生成器主键改成雪花ID或者雪花ID变种。2.3 存储过程、触发器、视图、外键这些“高级对象”MySQL里用得多的存储过程、函数、触发器、视图、事件在TDSQL MySQL版里兼容程度不完全一样我把我们实际的验证结果整理一下视图兼容性不错单分片路由的视图基本没问题。但视图如果跨分片关联性能要靠实际压测说话。存储过程和函数基础的创建、入参出参、游标、循环、异常处理我们迁移过来的过程大部分能跑。但存储过程里如果出现跨分片的大结果集操作可能会因为Proxy层的资源限制出现异常。建议存储过程里只做单分片内的小逻辑重量级计算放到应用层去做。触发器官方支持力度相对谨慎。我们当时有一个订单表需要写变更日志的触发器迁移后发现高并发下触发器逻辑容易干扰主流程后来改成了应用层显式写入日志表。外键单分片内约束支持还算可用但跨分片外键是不支持的。金融核心系统本来也不建议用外键做业务完整性改成应用层校验更适合分布式架构。事件调度器Event我们没用它做主流程只在一个配置表上做了定时清理迁移后功能正常。一句话总结这些都是MySQL的附加能力但分布式场景下它们的容错性、性能、行为确定性都不如应用层代码。能用代码解决的不要指望数据库。2.4 事务、隔离级别和全局唯一性事务隔离级别方面TDSQL MySQL版支持MySQL常见的READ COMMITTED和REPEATABLE READ。我们业务用的是READ COMMITTED配合行锁和MVCC普通并发场景的表现基本可以无缝替换。不过有一点要提醒分布式事务开启时锁的粒度和等待时间可能比单机MySQL要敏感。我们有个结算批处理任务曾经出现过跨分片死锁排查下来细节不复杂就是两个分片上的锁获取顺序不一致但这类问题在分布式环境更难事前发现只能靠监控死锁日志并及时调整事务内SQL顺序。全局唯一性上的选择常用的有几种UUID串、雪花算法、Redis发号器。TDSQL MySQL版还支持自带的全局自增序列但如果你对ID有“时间递增、业务可读、趋势递增”这类要求优先还是用应用层分布式ID。3. 实操从MySQL迁到TDSQL的开发适配全流程3.1 迁移前先做一次“兼容性体检”不要上来就导出导入先把你的存量SQL和表结构做一次体检。第一步收集SQL。如果用的是开源中间件慢查询日志、审计日志里全是宝贝如果有独立监控平台把一段时间内的TOP SQL、全量SQL都导出来。我们当时导出了近两周的十几万条SQL去重归类。第二步人工分类核查。手工打开分类后的SQL脚本重点标记三类语句跨表JOIN、带子查询的复杂语句、存储过程/触发器等对象定义。不用一条条精读但需要按常见限制清单去对。我整理了一个简易的核查清单可以参考分布式表的所有UPDATE/DELETEWHERE里是否含分片键SELECT的WHERE里是否常带分片键如果不带频率高不高是否存在跨分片JOINJOIN字段和分片键的关系是什么是否有深分页offset很大是否有大鱼union后再排序建表里是否有AUTO_INCREMENT做主键是否有跨分片唯一索引存储过程内是否有跨分片大查询触发器是否依赖物化或临时表字符集是否各库统一排序规则是否一致第三步用EXPLAIN干跑一遍关键SQL。TDSQL MySQL版支持EXPLAIN能看出SQL的命中分片情况虽然不能完全等价于内部的分布式执行计划但至少能帮你发现“这条语句是不是全分片广播”。这步实测很有用我们有一批统计SQL就是在这里发现需要改写的。3.2 连接配置和参数调整这一步最容易被忽略连接串的调整是第一个可见的改动点。我们用的Java应用改完后长这样jdbc:mysql://tdsql-proxy.example.com:3306/shopping?useUnicodetruecharacterEncodingutf8mb4useSSLfalseserverTimezoneAsia/ShanghairewriteBatchedStatementstrue几个关键点用域名连接别用IP直连。TDSQL控制台上给的是代理接入地址域名方式应对后端节点变更更稳。连接池不要开太大。Druid或HikariCP配置里initialSize和maxActive别按原来单机MySQL的习惯拍脑袋。因为Proxy层要hold住所有分片的连接连接池过大容易把Proxy连接数打满。我们调整为maxActive50就足够支撑原有峰值。开启批量写参数。rewriteBatchedStatementstrue对我们批量插入性能提升很明显从MySQL迁过来后这个参数建议直接加上。字符集统一utf8mb4。建库建表时通过参数模板统一指定避免迁移后因为乱码问题来回折腾。参数模板方面TDSQL控制台支持配置参数。我们最关注几个sql_mode、max_allowed_packet、lower_case_table_names、time_zone。建议建实例时把sql_mode对齐源库否则某些写法在严格模式下会直接报错。还有max_allowed_packet原来入库的大报文或大SQL如果超过了默认值迁移后第一条大SQL就会失败我们就被这个坑过一次。3.3 分片键选型分布式表的“命根子”分片键怎么选直接决定了你未来所有SQL的写法必须在建表前定下来。网上很多文章会告诉你选“业务最常用的条件”这个没错但还太抽象。我的实际建议是选高基数、分布均匀的字段。用户ID、订单ID、店铺ID这类天然均匀的字段是首选。千万不要用状态、类型、月份这种低基数字段做分片键会产生严重的数据倾斜一个分片热到爆、其他分片闲着。选等值查询最频繁的字段。分片键的目的就是路由使用越频繁的等值条件就能让越多SQL命中单分片。比如电商订单表用户端查询永远带用户ID后台查询可能带商家ID这时候到底按哪个分片要看哪个场景是常态流量。不要选会频繁更新的字段。分片键变更意味着数据要跨分片搬迁代价很大几乎等于重新设计表。业务上要有兜底方案。非分片键查询要提前想好方案比如建全局二级索引、设计冗余表、或者走搜索引擎。不要等业务方来问“我按手机号查用户怎么办”的时候再临时抱佛脚。我们当时把订单表分片键定为用户ID商家后台查询订单的场景全部改成先查“用户ID与商家ID关系表”再做二次查询。这个模式牺牲了一次查询的RT但换来的是所有核心链路都稳定落在单分片权衡下来非常值。3.4 用DTS做迁移以及迁移后的验证迁移工具我们用的腾讯云DTS。整体流程不复杂先在源库开好数据同步账号然后在DTS控制台创建迁移任务选“结构迁移全量迁移增量迁移”填上源和目标实例信息最后启动任务。增量迁移那一步很重要它可以做到业务切换前数据实时同步。我们当时的切流窗口选在凌晨流程是这样的DTS全量迁移完成进入增量同步状态应用侧停写等增量延迟追到0在目标库做一次总数核对切换应用的JDBC地址到TDSQL打开流量观察监控指标。验证不只是看行数。我们写了一个专门的验证脚本跑三类东西一是关键表COUNT(*)对比源库和目标库二是抽样查询几条关键业务记录比对关键字段三是把核心链路的SQL清单拿出来在目标库依次EXPLAIN和执行确认执行计划和结果集是否一致。比较让我意外的是大部分SQL验证一次就过了但有几条涉及子查询和跨分片排序的语句虽然结果一样EXPLAIN里显示的扫描分片明显偏多。这类SQL我们后来都做了应用层改写没有让它们带着隐患留在生产环境。4. 常见兼容性问题与排查速查4.1 高频报错和排查方向我把这几个月碰到的问题、排查方向整理成了一张速查表适合贴在自己团队的wiki里现象或报错关键字可能原因排查与处理思路SQL报错近似“statement cannot route to a single shard”SQL无法路由到单个分片或跨分片能力不支持检查WHERE是否带分片键检查是否跨分片JOIN/子查询深分页时Proxy节点CPU/内存飙高大offset的LIMIT触发全分片排序合并改用基于上一页最后ID的游标分页更新库存类语句并发冲突变高跨分片分布式事务锁等待检查事务内SQL顺序尽量把热点行集中到一个分片批量INSERT极慢连接串缺少批量参数或单条执行开启rewriteBatchedStatements评估分片数是否过大自增主键出现“跳跃”全局自增序列机制导致业务不要依赖ID连续递增数据库变慢、并发连接被打满Proxy连接数被应用连接池耗尽缩小连接池检查是否有连接泄漏表结构变更DDL执行意外报错分布式表DDL限制确认是否涉及分片键修改普通DDL通过控制台或标准语法执行存储过程执行异常或结果不一致跨分片逻辑在Proxy层受限拆到应用层处理或改为只操作单分片内数据这张表背后最核心的排查方法其实是先把SQL能不能路由到单分片判断清楚。拿到一条慢SQL第一步不是看索引而是看它是不是全分片广播。把这个问题解决了很多“性能问题”直接就消失。4.2 三个典型的真实案例复盘案例一不带分片键的UPDATE引发的蝴蝶效应。我们上线第一天运营后台有个按“订单时间”批量修改订单备注的功能。订单表分片键是用户ID这条UPDATE的WHERE条件只有create_time没有用户ID结果Proxy把这条语句广播给了所有分片。当时数据量还不算大只把几个分片CPU打高了几分钟。我们改了SQL先查一次能够定位到用户ID再按用户ID去更新问题就再没出现过。这个案例的教训批量更新前一定问自己一句WHERE里到底有没有分片键。案例二深分页把Proxy内存吃满了。分页查询支持“最后一页”是刚需但MySQL习惯的LIMIT 100000, 20在TDSQL分布式表下面临的是所有分片先把10万条数据翻出来再统一排序剪裁。我们的一个后台列表页就这么把Proxy节点的内存打到告警。后来改成按排序字段和上一页最后一条记录定位也就是游标分页Proxy只需要下推一个范围条件效果立竿见影。这条经验适用于所有分布式数据库。案例三存储过程里跨分片游标行为异常。一个老报表模块存储过程里定义了一个游标遍历某张日志表做累计计算。原来单机MySQL没问题上了TDSQL后因为日志表是分布式表游标遍历过程中分片之间没有全局排序保证某些结果偶发不一致。后来我们把这个报表改成两步先用一条聚合SQL把结果算出来再在应用层做二次加工。存储过程拆掉后报表结果保持一致。4.3 给开发者的避坑清单写到最后我把团队沉淀的SQL开发规范精简了一下没有特别高深的内容全是“老老实实避坑”的招式对分布式表SELECT/UPDATE/DELETE都必须评估是否命中分片键核心链路强制命中。统计类、报表类查询不要直接怼到在线库能用汇总表/宽表就先归并。禁止深分页后台列表一律游标分页。跨分片JOIN能拆就拆不能拆就建立反范式冗余字段。字符串字段统一utf8mb4排序规则统一避免大小写和字符集引发的关联异常。事务里别混业务操作短事务、少跨分片、幂等重试。自增主键只用于无业务含义的代理键不参与业务逻辑。上线前对核心SQL做一次“分片命中率”审查通过EXPLAIN确认执行计划。多环境准备一个和线上规模接近的分布式测试环境只在小库上验证是远远不够的。我在实际项目中最大的体会是TDSQL MySQL版并不可怕它保留了MySQL的开发体验又给了你分布式的扩展能力但代价是你得接受分布式环境下的纪律。把分片键、路由、广播、跨分片事务这几个概念刻进团队每个开发者的脑子里迁移过程就会顺利很多。如果你们也正在做类似的评估我建议先拿一两个核心业务表做小范围压测尤其是把“不带分片键查询”“跨分片事务”“深分页”这几个最容易踩坑的场景单独压一轮。提前暴露问题好过上线之后再手忙脚乱。