企业官网建设流程全解析

这个3月，数据库圈子在湖南有一场挺值得跑一趟的聚会。3月14日，TiDB社区把线下Meetup办到了长沙，主题很直接——数据库的国产化升级。报名链接在群里一转，我身边做架构、做运维、做数据平台的朋友就开始呼朋引伴了，零售、医疗、金融、交通、智能制造，五个行业放在一起，几乎覆盖了国内存量数据库改造最典型的那几类场景。TiDB作为分布式NewSQL数据库，这两年在这类升级项目里出镜率很高，兼容MySQL协议、支持水平弹性扩展、具备HTAP混合负载能力，很多团队把它当作从传统集中式架构迈向分布式架构的过渡选择。

这篇内容我不打算复读会议议程，那没意思。我更想把这几年实际参与过的数据库国产化替换、存量迁移、上线护航项目里的经验和踩过的坑摊开来讲，再聊聊TiDB这类数据库到底适合什么场景、迁移时哪些问题提前知道能省掉你两礼拜的加班，以及3月14号这场活动上，你更值得去听什么、问什么。无论你是正在做选型调研的架构师，还是马上要扛迁移项目的DBA，又或是刚接触分布式数据库的开发同学，这篇都能给你一份能直接抄作业的参考思路。

1. 国产化升级绕不开的架构选择题：为什么大家都在谈TiDB

1.1 升级的本质不是换数据库，而是重构数据架构

很多团队对“国产化升级”的第一反应是“把Oracle换成某国产库”，这个认知其实很危险。我见过不止一个项目，老板拍板要国产化，底下人把表结构导过去、存储过程改一改、连接串换一换，结果上线一个月，业务高峰期CPU直接打满，原本在Oracle上靠分区和并行还能撑住的报表SQL，在新库上跑得像蜗牛。问题出在哪？出在大家把“升级”理解成了“平移”。

数据库替换的本质，是数据架构的重构。原来集中式数据库承担了太多职责：OLTP、OLAP、批处理、消息中间件的数据落地，全塞在一个库里。业务量小的时候没问题，等数据量上了亿级、并发上了千级，集中式架构的瓶颈就藏不住了。你换一个新的集中式库，只是把瓶颈从一个盒子搬到另一个盒子。真正要解决的是扩展性问题——存储能不能横向加机器、计算能不能弹性伸缩、读写能不能分离、历史数据和热数据能不能分层。

所以这几年TiDB这类分布式数据库会频繁出现在国产化升级的讨论里，原因不在“国产”这个词，而在它的架构逻辑原本就是为了解决集中式库的扩展性天花板。它不是让你把旧库“平移”过来，而是逼着你把数据模型、访问模式、容量规划重新想一遍。这个过程确实疼，但疼完了，架构是健康的。

1.2 TiDB存的不是“另一个MySQL”，而是“能长大的MySQL”

TiDB的架构，很多文章写过，我再简要说一下，因为不理解架构就没法理解后面所有的选型和踩坑。TiDB整体分成三层：最上层的TiDB Server负责SQL解析和计算，它是无状态的，可以随便加节点；中间是PD，负责集群的元数据管理和调度，相当于整个集群的大脑；最底层是TiKV，负责数据存储，数据按Region切分成一个个小片，默认每个Region大概96MB，分散存储在不同节点上。

这套架构带来的直接好处是：扩容是真正意义上的水平扩展。业务量涨了，加几台TiKV节点，数据会自动rebalance过去，不需要你手工拆库拆表。Region的自动分裂和调度意味着热点数据可以分散到多个节点上，某一张表的写入压力特别大时，不会像单机MySQL那样成为全局瓶颈。

还有个很实用的能力是HTAP。你不需要再单独搭一套数仓做分析，同一份数据可以同时走行存（TiKV）和列存（TiFlash），TP和AP负载互相隔离。我在一个零售项目里就是这么干的——交易数据实时写入TiKV，报表查询走TiFlash，原来的ETL链路省掉了一整段，报表延迟从T+1变成了分钟级。

对从MySQL迁过来的团队，TiDB还有一个隐性优势：它懂MySQL的协议。你原来用MySQL的SDK、ORM、连接池，基本不用改，开发同学的SQL习惯也大体保留。也就是说，团队的学习成本主要体现在分布式思维上，而不是重新学一门数据库语言。这一点在实际项目中太重要了，直接决定了迁移项目的排期是三个月还是一年。

1.3 兼容MySQL生态，迁移成本才能被真正打下来

我接触过不少准备国产化替换的团队，大家第一关心的问题其实是“应用代码要改多少”。TiDB的聪明之处就是它没有另起炉灶，而是深度兼容MySQL 5.7和8.0的常用语法和协议。你原来用MyBatis、GORM、SQLAlchemy这些框架写的DAO层，换一个数据库驱动，大部分情况可以原样跑。

但这不意味着100%零改动。我后面会专门说兼容性体检的问题，这里先给个大致预期：常见的CRUD、JOIN、子查询、事务操作，基本没有问题；但有一些边缘特性是需要注意的，比如某些存储过程语法、触发器、外键约束，TiDB的支持策略和MySQL并不完全一样（TiDB对存储过程有支持但限制不少，外键在较新版本虽然支持了但在分布式环境下需要谨慎使用）。存储过程在TiDB里能用，但官方一直不推荐把复杂业务逻辑压在数据库里，更建议上移到应用层。触发器官方直接不支持，历史遗留的触发器逻辑必须在迁移前改写成应用层代码。

我在制定迁移方案时，会先让团队做一次SQL兼容性扫描，把存量SQL全部捞出来，跑一遍静态检查，把涉及不兼容特性的SQL单独列出来排期改造。这一步看着琐碎，却是整个迁移项目里风险最高的环节——SQL改造漏了一个，上线后就是线上事故。TiDB生态里有一些辅助工具能做这个检查，不过最靠谱的还是拿全量SQL日志在测试环境真跑一遍。

2. 五大行业的改造场景拆解：从订单洪峰到产线数据

2.1 零售：先解决峰值扩展，再谈精细化运营

零售行业的数据库压力，特点非常鲜明：流量是脉冲式的。大促、秒杀、直播带货，峰值流量可能是平日的几十倍。过去用单机MySQL，每逢大促就得提前扩容、改架构、加缓存、限流，凌晨压测，运维同事那几天基本不用睡觉。

TiDB在零售场景的核心价值就是弹性。你不需要提前几个月准备容量，业务高峰来临时临时加节点也能撑住。我参与过的一个连锁零售项目，原来的架构是MySQL主从，订单表过亿之后，查询和写入都明显变慢，团队不得不上ShardingSphere做分片，但分片键选得不好，很多查询要跨片聚合，反而更慢。后来他们考虑引入TiDB，看中的就是自动分片的能力——底层数据自动按Region拆分并分布到多个节点，上层应用完全无感知，不需要手工设计分片键，也不用改SQL。

零售行业另一个被忽略的需求是数据链路整合。门店、线上商城、会员系统、供应链系统，各自有各自的库，报表要汇总到总部，经常是“晚上定时跑批，跑完天亮了”。TiDB的HTAP能力在这种场景很讨巧，我帮他们做了这么一件事：把各系统的业务表通过数据同步组件实时汇总到TiDB，TiFlash列存负责分析查询，日报变成了小时级甚至实时。零售数据分析的诉求其实就是快、准、全，TiDB这套方案相当于把交易库和分析库合成了一件事，运维负担少了一半。

2.2 医疗：多院区、高可用、好监管，稳定压倒一切

医疗行业的数据库升级，优先级排序跟互联网完全不一样：稳定 > 合规 > 性能 > 成本。别看有些医院的信息化系统还是老旧的SQL Server或Oracle，真要去动它，要考虑的东西非常多：HIS（医院信息系统）、LIS（检验系统）、PACS（影像系统）、EMR（电子病历），一个都不能宕机。而且现在大型三甲医院普遍是多院区模式，各分院之间数据要共享、要互通，传统的“一个院区一个库”根本没法做统一的患者主索引和病历视图。

TiDB在多院区整合场景的表现，我有一次在交流会上听一个医疗信息科的主任讲过。他们的做法是各院区本地保留一套TiDB集群，通过同步组件把关键数据汇聚到总院的数据中心。这样既保证了各院区本地业务的低延迟，又能在总院形成全量数据视图。患者档案、就诊记录、检验报告这些数据，不再散落在各个系统里，跨院区的调阅延迟从分钟级降到了秒级。

高可用方面，TiDB的Raft协议和多数派机制保证了数据强一致。节点宕机、磁盘故障，只要集群里超过半数的副本还活着，数据就不会丢，服务基本不中断。这一点对医疗场景太关键了——半夜急诊、手术期间系统是不能停的。我见过不少医院做容灾演练，切给TiDB之后，主备切换时间从传统的分钟级缩到了几十秒级，甚至能做到对业务无感。加上数据实时同步到异地容灾集群，等保和监管审计的要求也更容易满足。

2.3 金融：强一致、多活容灾，分布式事务是地基

金融行业做数据库国产化升级是走得最早的，也是最谨慎的。银行、保险、证券的核心系统，对数据一致性的要求是铁律，一分钱都不能差。TCC、SAGA、本地消息表，这些分布式事务方案在传统集中式数据库里都不需要操心，因为单库天然支持ACID。一旦拆成多个库或者换成分布式数据库，分布式事务就成了必须跨过去的坎。

TiDB的分布式事务基于Percolator模型，支持跨节点、跨Region的ACID事务。在TiDB里，事务可以涉及多个Region，通过两阶段提交保证原子性，而且对应用层透明——你写代码还是像写单机MySQL一样，不用改造成TCC或者SAGA。这一点对金融业务来说，是减负不是加负。我接触过的某个支付类项目，原来被分库分表折磨得够呛，跨库事务用分布式事务框架硬扛，性能损失很大，引入TiDB后事务逻辑回归了本地事务的写法，代码量和故障率都明显下降。

多活容灾方面，TiDB的原生设计支持同城多中心、两地三中心部署。数据副本跨机房放置，任何一个机房整体故障，流量可以秒级切到其他机房，RPO趋近于零，RTO控制在分钟级以内。金融行业对容灾的要求是“不能只看数据备份，还要看业务连续”，TiDB的这个能力正好对上。说白了，对金融来说，技术架构的国产化升级是底线工程，不能花里胡哨，就看稳不稳、敢不敢复制。

2.4 交通：车联网与票务的混合负载

交通行业的数据场景，可能很多人不太了解，它其实是典型的“高并发写入+时空分析+实时统计”混合负载。车联网平台，每辆车每秒会上报GPS坐标、车速、油耗、电池状态，一台车一天产生几万条数据，一个城市的车队规模动辄几十万辆，一天就是上亿条写入；轨道交通的票务系统，早晚高峰的刷闸并发非常高，但票务数据又需要做清分结算等复杂统计。

我之前参与过一个公交集团的数据平台项目，原来用的是Oracle，车载终端上报的数据让Oracle的入库压力非常大，归档表和操作表的切换也经常出问题。改造时他们考虑TiDB，最核心的原因就是写入扩展性。几十个车队的终端同时上报，单点压力分摊到集群里，入库延迟稳定在毫秒级。数据不再需要定期归档——TiDB的数据量大了可以加节点，旧的冷数据也可以通过设置分区或使用TiKV的自动压缩机制来管理。

交通数据还有一个特点是空间属性强，“查一辆车在过去一段时间的历史轨迹”“统计某个区域当前的在线车辆数”，这类查询如果走传统数据库的SQL，写起来麻烦、跑起来更慢。配了TiFlash之后，这类分析查询直接走列存，全城车辆实时位置汇总跑到秒级。票务系统的清分结算原来是一个晚上跑批的活儿，现在可以做到准实时，财务那边给个时间窗口就能出报表。交通数据这种“既要又要还要”的场景，单靠一个OLTP库或一个数仓都别扭，TiDB这种HTAP融合方案反而是最顺手的。

2.5 智能制造：产线实时数据与ERP/MES的打通

智能制造是这几年国产化升级里新增的热门场景。工厂里的设备、传感器、PLC（可编程逻辑控制器）每时每刻都在产生数据，MES系统要把这些数据接进来做生产监控，ERP系统要做工单和成本的核算，两个系统如果数据不打通，管理层看到的报表永远是滞后的。

TiDB在智能制造场景的数据架构里，一个典型位置是作为车间的“实时数据中枢”：产线设备数据通过边缘网关写入TiDB，MES和ERP的业务数据也汇集到同一套集群。因为TiDB兼容MySQL，设备端和业务端接入都很快；产线监控看板需要实时聚合，走TiFlash的列存查询，几十万设备的数据刷新到秒级；历史数据也不会像以前那样被定时清理，而是沉淀下来做产能分析和质量追溯。

有次我去一个做新能源电池的工厂交流，他们的痛点特别典型——原来MES用SQL Server，设备数据用时序数据库，两套体系互不相通，要做个良率分析得导来导去。他们当时的想法就是把设备和业务数据统一到一个平台，选型时重点考察的就是“能不能既扛住设备高频写入，又支持复杂业务查询”，TiDB的HTAP和MySQL兼容性刚好命中。做工业数据的人都有一个感受：工厂里的数据基础设施，不怕功能多，就怕不兼容、不通透。TiDB能把这些数据揉到一起，价值就出来了。

3. 迁移实操笔记：从存量库平滑切到TiDB的标准动作

3.1 迁移前的兼容性体检，决定后面是省心还是折腾

每次有人问我“TiDB迁移难不难”，我都会反问一句：“你的存量库健康吗？”如果原来的库上跑着一堆没人敢动的存储过程、改了又改的触发器、各种诡异的数据类型和字符集，那迁移一定不轻松。如果存量库本身SQL比较规矩，迁移就会顺利得多。所以第一步永远是体检，不是直接开导数据。

兼容性体检我会从四个维度做：SQL语法、数据类型、字符集排序规则、事务隔离级别。

SQL语法方面，可以用EXPLAIN或者TiDB的SQL诊断工具跑一遍存量SQL，也可以直接用pt-query-digest从慢查询日志里捞高频SQL，放到TiDB测试环境执行一遍，看有没有报错、执行计划是否合理。常见的不兼容点我刚才提过：触发器、外键（新版本支持但默认建议少用）、某些复杂的存储过程逻辑、Oracle风格的CONNECT BY层次查询（TiDB一般是建议改成递归CTE）、UPDATE ... JOIN的语法差异。最好在项目一开始就建一个“SQL改造清单”，每遇到一个不兼容的写法就登记一条，对应到具体改造人和排期。

数据类型方面，TiDB支持常用数值、字符串、时间类型、JSON类型，跟MySQL基本一致。Oracle迁移过来需要特别注意：VARCHAR2要改成VARCHAR，NUMBER要细化成具体的INT或DECIMAL，DATE类型在Oracle里带时分秒，TiDB的DATE不带，需要改成DATETIME。这些都是直接跑数据才会暴露的坑，建议写一个类型映射表，导数据前先过一遍。

字符集和排序规则，现在基本统一推荐utf8mb4和utf8mb4_general_ci（或者utf8mb4_0900_ai_ci），如果老库用的是latin1这种老编码，迁移之前就要想好数据清洗方案，别等导完了才发现乱码。事务隔离级别，TiDB默认是REPEATABLE_READ，和InnoDB的默认一致，但TiDB的快照隔离实现略有差异，如果应用里依赖SELECT ... FOR UPDATE的锁语义，需要做一轮并发场景的回放测试。

3.2 全量+增量+校验，用Data Migration做分钟级切换

体检完、改造完，终于到了真正干活的时候。存量迁移我推荐的工具是TiDB官方生态里的TiDB Data Migration（DM），它能处理全量数据导出、增量binlog同步、以及数据校验，是TiDB迁移项目的标准配套。

整个流程分三步：全量同步、增量追平、切换。

全量同步阶段，DM会把源库的数据完整导到TiDB。这一步最怕的就是大表超时和断点续传的问题。DM天然支持断点续传，中途网络抖动、导出任务挂了，恢复任务之后能从断点继续，不用重新来一遍。源库如果是Oracle，要注意Oracle侧是没法直接走binlog的，需要先用Ora2Pg或者其他工具做一次全量迁移，增量部分再想办法，这时候同步链路会复杂一些。如果源库是MySQL，DM就非常顺手。

增量追平阶段，DM会读取源库的binlog（或者Oracle的redo解析产物），把同步期间的增量变更持续应用到TiDB。这个阶段，你要做的是不断监控源库和目标库的同步延迟，等到两者的数据基本一致。延迟归零或接近零时，就进入切换窗口。切换时先把源库设置成只读，等最后一波增量追平，然后让应用连接切到TiDB。

整个切换动作，我习惯在凌晨低峰期做，提前列好checklist，一条一条确认：同步延迟是否归零、数据校验是否通过、连接串是否切换完毕、只读开关是否解除、业务探活是否正常、回滚开关是否备好。工具不会让过程变得戏剧化，但能把风险压到可控范围。

3.3 上线切换与回滚预案，慢工出细活

切换回滚这件事，我必须多说几句。很多人设计迁移方案时，把回滚当成“最后一步”，整个方案的核心都在“怎么切过去”，但对“怎么切回来”一笔带过。真实上线时，回滚预案比切换预案更重要，因为你永远不知道切过去之后会发生什么。我在项目里有一条铁律：回滚方案必须单独演练过，不能只是写在文档里。

TiDB迁移项目的回滚通常分两种：应用层回滚和全量数据回滚。应用层回滚最简单，就是保留源的数据库连接串，一旦TiDB侧出现严重问题，应用可以切回源库继续跑；这要求源库在切换之后不要立即变更数据（至少保留一个过渡期的回写窗口）。所以我会建议业务在切换后一周内保留源库，接受应用双写或者源库只读的代价——这个代价通常远小于数据回滚的代价。

数据层回滚比较麻烦，如果切换后业务跑了好几天，源库的存量数据已经过期，此时要回滚只能重新走一遍全量导出+增量的流程，业务中断时间是分钟级起步。所以现场的真实策略往往是：切换后发现问题，如果问题能在短时间内修复（比如某个SQL执行计划错乱、某个索引没建对），优先修复而不是回滚；只有核心数据不丢、但功能卡死无法修复时，才启动回滚。另外，建议切换前对TiDB侧做一次完整的快照备份（TiDB支持通过BR工具做备份），数据一致性校验也尽量自动化，不能靠人肉抽查。

成功的上线，不是“切过去那一刻有多顺利”，而是“切过去之后的七天都很安静”。慢工出细活，迁移项目尤其如此。

4. 高频故障与避坑经验速查

4.1 排查思路：先查链路，再查SQL，最后查硬件

跟TiDB打了几年交道，我总结出一个比较省力的排查顺序：链路 → SQL → 硬件。很多同学一遇到TiDB性能问题，第一反应就是看节点负载、看磁盘IO，这其实把顺序搞反了。TiDB最大的性能杀手永远在SQL层面和访问模式层面。

链路排查，先确认应用到TiDB的连接是走负载均衡还是直连，连接数有没有被打满。TiDB的连接数是按TiDB Server节点维度计算的，假如你有一堆应用连接池，总连接数很容易把单个TiDB Server打爆，这时候不是集群性能不够，而是连接分配出了问题。解决办法是调大连接池上限或增加TiDB Server节点。PD的调度异常也会造成类似症状——某个TiKV节点上的Region长期不均衡，热点集中在少数节点上。

SQL排查是最核心的。用TiDB Dashboard看慢查询、看执行计划、看锁等待。遇到慢SQL，第一步是看执行计划有没有选错索引，TiDB的优化器在复杂JOIN和子查询上的代价估算偶尔会跑偏，这时候不用急着改SQL，可以先试试SPLIT REGION或者调整优化器提示（比如USE_INDEX、HASH_JOIN）。如果连执行计划都对，再考虑数据分布问题，比如某张表的数据倾斜严重，根据少量热值的条件查询就会特别慢。

硬件排查放到最后。TiDB对磁盘的要求较高，TiKV使用RocksDB，对IOPS和延迟敏感，如果用的是机械盘或者性能不达标的云盘，写入延迟会明显偏高。但这个问题在选型阶段就该发现，上线后遇到的概率不大。真遇到节点故障，也就是看看TiKV的监控面板，确认Raft的leader是否已疏散、数据正在自动补副本，这个机制基本不需要人干预。

4.2 最容易被低估的七个坑

• 自增主键和热点写入。这是TiDB运维里最经典的问题。单表自增ID是全局递增的，插入时所有新数据都落在同一个Region上，写入热点就形成了。解决办法是用TiDB的AUTO_RANDOM特性替代自增主键，或者在业务里用类似Snowflake的方式生成随机分布的主键。很多从MySQL迁过来的团队第一个踩的坑就是这个。

• 大事务限制。TiDB的事务默认限制是单个事务的总大小不超过100MB（由txn-total-size-limit控制）。如果你批量更新几十万行数据，每个字段都很大，很容易撞上这个限制。日常大批量操作要分批，建议每批几千行。DELETE大范围数据时，尤其注意分批加LIMIT，而不是一条SQL全扫。

• 分区表的动态裁剪。TiDB从较新版本开始支持分区表的动态裁剪模式，如果没开，很多分区表的查询会把所有分区都扫一遍。检查tidb_partition_prune_mode，设为dynamic，再用EXPLAIN看执行计划的partition:all还是partition:p1。

• Online DDL的实际影响。TiDB的DDL不锁表，但也别高兴太早。超大表的索引创建还是会占用额外资源，影响在线写入性能。我一般在业务低峰期执行建索引操作，且优先使用tidb_ddl_enable_fast_reorg这类参数加速。

• Tiflash和列存的资源隔离。开了TiFlash不代表查询一定走列存。优化器会基于代价选择行存还是列存，如果你的分析查询没走TiFlash，检查表的TIFLASH REPLICA是否建好，以及相关的优化器开关是否打开。别把TiFlash当成自动加速器，它是需要设计的分层存储。

• 字符集和排序规则不匹配。迁移时如果源库和目标库排序规则不一致，联合查询能跑，但结果集顺序可能和你预期不一样，索引匹配也会出问题。所有库、表、字段统一utf8mb4，省掉后面一堆破事。

• 连接池配置和TiDB的不适配。TiDB对连接池的语义和MySQL略有差别，有些Java连接池（如Druid）里配置了Ping检测、PrepareThreshold等参数，可能出现频繁重连或者Prepare语句报错的情况。迁移后建议用真实业务跑一轮连接池稳定性测试。

这七个坑，每一个我都见过线上事故版本，也见过团队花了两周才定位出来。提前知道，能救你的上线。

5. 3月14日湘聚活动，值得听什么、问什么

5.1 现场信号：五大行业的真实案例比PPT更重要

说回3月14号这场TiDB社区长沙场。活动名叫“数智湖南，湘聚”，主题就是数据库国产化升级实践，聚焦零售、医疗、金融、交通、智能制造五个行业。数据库沙龙最有价值的从来不是概念，而是案例，尤其是和湖南省内产业特征相关的案例。

湖南的产业特点其实很鲜明：长沙的工程机械、轨道交通装备制造很强，三一重工、中联重科、中车株机这些企业都在做数字化的深度转型；零售方面有大量的连锁商超、本地生活平台；医疗资源在长沙也是区域级的中心。所以活动里一旦真的讲这几个行业的国产化升级案例，基本就是省内企业的一手经验，比你看十篇技术文档都更有参考价值。

到现场，我建议你重点听三样东西：一是迁移路径设计，他们从什么架构起步，经历了哪几个阶段，为什么在某一步选择了TiDB；二是踩坑复盘，讲者有没有披露自己在迁移中遇到的问题，这是判断分享含金量的关键；三是多行业同台时的横向比较，零售的弹性扩展和金融的强一致是两种取向，你能从中看到自己所在行业可能忽略的角度。

5.2 怎么提问，才能换回干货

很多人去技术活动，问的问题太泛。“TiDB适合我们吗？”“国产化升级要多久？”这种问题，讲者只能给你一个四平八稳的答案。真想挖干货，问题要具体，要带上你自己的业务上下文。

比如你可以这么问：“我们有张订单表3亿行，联合索引有五个字段，按现状在MySQL上写入延迟已经到百毫秒级，如果平移到TiDB，需要先做分表或者改主键吗？”这种问题带上了表规模、索引情况、现有延迟，懂行的人一听就知道你踩到了哪一步，给出的建议也会具体得多。

如果你是做金融的，就追问共识细节：“你们的跨机房容灾，RPO实测能做到多少？容灾切换演练过几次？切换时有没有遇到Region重新调度引发的延迟尖峰？”如果你是做制造的，就追问数据链路：“你们设备数据的接入频率是多少，有没有先做数据预处理，还是直接把原始点位写进TiDB？”现场提问的艺术就是“把公开经验变成你的专属咨询”，带着问题去，带着方案走，这一趟才不白跑。

我个人的习惯是，参加这类活动前先把自己项目的架构图画出来，标出目前最痛的三个点，到现场逐个去问，问不到就加微信继续聊。数据库选型和升级这事，最怕闭门造车，别人已经在生产环境趟平的路，你别再自己拿脚去踩一遍。

无论你最后选不选TiDB，国产化升级这条路的思路是一样的：先把存量摸清楚，再谈架构；先把风险点列出来，再谈排期；先准备回滚方案，再谈上线。希望3月14号湖南这场聚会能给你带来一些真实的参照，也祝正在做数据库改造的你，少加班、少踩坑、一次切成功。