协议兼容的边界：能连不等于能信

MySQL协议兼容在TeleDB这里指的是客户端握手、认证、报文格式、基础SQL语法、系统库视图按MySQL形态暴露，主流连接器可以不改连接串直连。这一层兼容解决了应用起得来的问题。

但协议兼容不覆盖三层东西。其一，所有MySQL私有语法扩展不一定全有，比如某些存储过程语法、特定版本的函数行为、某些插件级的特性。其二，优化器决策不同——同一条SQL在MySQL里走索引A，在TeleDB里可能走索引B，结果一样但耗时不同。其三，分布式场景下的全局约束，比如跨分片外键、跨节点触发器、自增主键全局唯一但非连续，这些在单机MySQL里不是问题，在分布式兼容库里需要显式设计。

迁移前最该做的一件事，是把协议兼容在内部文档里改写成具体清单：哪些语法我们用了、TeleDB支不支持、不支持的怎么改。凭官网写兼容四个字就开迁，等于闭眼过马路。这个清单应该包含当前业务用到的所有SQL语法、存储过程、触发器、自定义函数、字符集设置，逐条在TeleDB上验证，不能通过的列入改造计划。

还有一个容易被忽略的边界：MySQL生态工具链的兼容性。比如备份恢复工具、数据同步工具、监控采集工具，它们也走MySQL协议，但可能依赖某些私有命令或系统表。迁移前要把这些工具的兼容性一并验证，否则切流后发现监控采集不到数据，运维盲区会让人很被动。

连接入口与驱动选择

TeleDB暴露MySQL协议端口，应用通过普通MySQL驱动连接，连接串里主机端口指向TeleDB协调节点。协调节点在这里扮演和MySQL Server等价的接入角色，把SQL收上来做解析路由。

驱动层面建议沿用原MySQL驱动版本，不要顺手升级大版本——驱动大版本可能改默认行为，引入额外变量。连接池配置里，最大连接数、空闲回收时间、探活语句都按TeleDB协调节点角色调整：协调节点挂掉会触发重连，连接池要有节点列表或DNS轮询兜底，别把连接串写死单个节点IP，否则协调节点主备切换时连接池会集体断。

一个细节：MySQL客户端握手时会发一些会话变量初始化语句，TeleDB若不完全认这些变量，可能在连接建立阶段报无关错误。迁移测试里要把应用启动时的初始化SQL逐条过一遍，不认识的要么去掉要么在TeleDB侧确认等价替代。常见的初始化语句包括设置字符集、设置时区、设置SQL模式、设置事务隔离级别，每一项都需要确认。

连接池的健康检查也很重要。MySQL常用的探活语句是简单的SELECT语句，TeleDB如果对这个语句的处理方式和MySQL有细微差别，可能导致连接池误判连接状态。建议在迁移测试阶段专门验证探活语句的行为，避免上线后连接池频繁重建连接。

Schema与数据类型差异

库表结构迁移通常用控制台或生态工具做结构同步，但结构能过不等于语义一致。几类高频差异需要重点关注。

自增主键在单机MySQL里是连续递增的，TeleDB分布式下自增主键全局唯一但可能跳跃，依赖主键连续等于插入顺序的业务逻辑会错。如果业务代码里有根据主键差值推算插入间隔的逻辑，或者前端展示依赖主键顺序，迁移后会出现不符合预期的表现。

某些时间类型、JSON类型、空间类型的内部表示和函数支持度可能有细微差别，比如对时区会话变量的处理、对JSON路径函数的支持范围。迁移前用脚本扫一遍表结构，把非常规类型列出来人工核对。时间类型尤其要小心，因为不同数据库对时区的默认处理方式不同，可能导致同一时间戳在不同时区下显示不同。

字符集与排序规则要显式对齐。MySQL库常用utf8mb4加特定排序规则，TeleDB建库时若默认排序规则不同，字符串比较、分组聚合、去重都可能出微妙差异，尤其是涉及表情符或生僻字时。这种差异在测试阶段不容易被发现，往往要等到线上出现数据展示异常才暴露。

外键和触发器在分布式场景是灰色地带。TeleDB若不支持跨分片外键，原库里靠外键保证的父子表一致性要改成应用层保证或去掉外键。这一步不是兼容问题，是架构决策，必须在迁移设计阶段定，不能等测试期报错再补。触发器同理，如果原库大量使用触发器做数据审计或衍生字段更新，迁移时需要找到替代方案。

SQL语义对齐：同结果不同路径

即使DDL和驱动都通了，DML和查询才是最容易藏雷的地方。

隐式类型转换是高频踩坑点。MySQL里字符串和数字的混合运算有特定的隐式转换规则，某些兼容库严格按SQL标准走会报错或转成字符串拼接，行为分歧在WHERE条件里尤其危险——原库能命中索引的隐式转换，新库可能全扫。排查方法是检查所有WHERE条件里的字段类型是否与比较值类型一致，不一致的显式转换。

GROUP BY非聚合列是另一个常见差异。MySQL旧版本允许SELECT里带非聚合列不写进GROUP BY，TeleDB按标准SQL可能拒绝，迁移时要把这类SQL改写。这种SQL在MySQL里能跑是因为它默认取了分组中的任意一行，而TeleDB要求明确指定聚合函数或把列加入GROUP BY，语义更严格。

分页与ORDER BY在分布式环境下表现不同。LIMIT偏移大时，MySQL和TeleDB的执行计划差异会被放大，尤其跨分片查询需要全局排序时，深分页性能可能断崖式下降。原库跑得动的分页SQL，新库要重新评估，必要时改用游标分页或键集分页替代传统OFFSET分页。

函数行为也需要逐项验证。日期函数、字符串函数、窗口函数，同名函数在不同实现里边界处理可能不同。比如日期加减遇到月末最后一天的行为、字符串截取遇到空值的处理、窗口函数排序并列时的排名规则，这些边界情况在常规测试中容易被遗漏，但线上数据千奇百怪，迟早会遇到。

建议做一轮SQL抽取回放：从原MySQL慢查询日志或业务埋点里抽高频SQL，在TeleDB上重放，比对返回行数、关键字段值、耗时。这一轮能暴露九成语义雷。回放时要注意覆盖各种数据分布情况，不能只测少量数据，因为数据量不同时优化器的选择可能不同。

事务与隔离级别

MySQL默认可重复读，TeleDB作为分布式库，全局事务管理器发时间戳做快照隔离，和MySQL可重复读体验接近但不完全等同。开发工程师要确认的几件事需要仔细梳理。

应用里有没有依赖读已提交和可重复读的细微差别做业务逻辑，比如先读后写判断库存。分布式快照下，长事务会拖慢快照水位，原库里跑几分钟的事务在新库可能让分析侧或MVCC版本链变重。如果应用中有长时间运行的报表查询或数据导出任务，需要考虑它们在TeleDB下的表现是否会变差。

XA或跨库事务如果原系统用了，要确认TeleDB的等价机制，不能假设驱动层自动平移。分布式事务在两套系统中的实现方式可能不同，迁移前需要充分测试。

自增主键回滚后不复用这个MySQL经典行为，在分布式下未必成立，依赖插入失败回滚后主键不空洞的假设会破。如果业务逻辑里有根据主键最大值判断数据量的操作，迁移后会发现主键增长比预期快。

连接级变量如自动提交、SQL模式要在连接初始化里显式设，别依赖服务端默认值，默认值在两种库可能不同。这个差异在迁移测试中很容易被发现，但也容易被忽略——因为应用在MySQL上跑了好多年，没人记得当初设了什么默认值。

迁移切流与回滚

迁移不是某天半夜停写、导数据、起新库一次性动作，而是双写、灰度、切流、观察、回滚预案五段式。

双写阶段：应用同时写原MySQL和TeleDB，读流量先走原库，验证TeleDB写入链路不丢不错。双写要解决主键冲突和定时对账。主键冲突可以用统一发号器解决，对账需要定时比行数、比关键字段哈希。对账的频率和精度要根据业务容忍度来定，金融类业务可能需要逐行比对，日志类业务可以接受抽样。

灰度切读：把只读接口按百分比切到TeleDB，观察慢查询曲线和错误率。写仍双写，保证随时可回退读流量。灰度切读时要关注TeleDB的响应时间分布，特别是尾部延迟是否比MySQL差。如果尾部延迟偏高，需要排查是数据分布问题还是优化器选择问题。

全量切写：读全部走TeleDB、写只写TeleDB，原MySQL保留只读副本一段时间做兜底。这一刻之前必须确认双写期间数据一致，否则切写后原库落后部分会丢。全量切写最好安排在业务低峰期，并且预留充足的观察窗口。

回滚预案不是文档里的如有问题切回，而是具体动作：读流量切回原库的连接池开关、写流量从双写变单写的配置项、数据反向同步的工具是否备好。没有反向同步能力的迁移，回滚等于丢切写后的增量。反向同步的延迟和吞吐也需要在迁移前验证，确保回滚时能在业务可接受的时间内完成。

切流期间监控重点看：TeleDB节点SQL耗时分位数、主备日志差异、缓存命中率、连接数水位、原MySQL侧是否还有残留连接。任何一项异动先降流再查，别硬扛。监控指标的阈值要比日常运维更敏感，因为切流期间任何异常都可能被放大。

结语

天翼云实时数据库TeleDB的MySQL协议兼容迁移，真正的工程量不在连上，而在连上之后每一句SQL还认不认、每一个事务还稳不稳、每一条数据还对不对。协议兼容把驱动层和握手成本抹掉了，但语义层、优化器层、分布式约束层的不一致会浮上来。开发工程师做这类迁移，最稳的姿势是把兼容拆成四张清单——语法兼容清单、驱动行为清单、SQL语义比对清单、事务边界清单——逐条过完再动切流。官网那句MySQL协议兼容是入口，不是终点；迁移项目的交付物应该是业务无感切换这个结果，而不是能连上这个开始。迁移完成后也不要急着销毁原库，保留一段时间作为最后的保险，等新库跑过完整的业务周期后再做清理。