数据库国产替代是这两年完全绕不开的话题。上半年我正好牵头把集团一套核心交易系统从 Oracle 迁移到了华为云 TaurusDB从立项评估、规格选型、数据迁移到应用侧改造、上线后的稳定性治理前后踩了不知道多少坑。很多朋友一听到“国产替代”就头疼总觉得是政策性任务、稳定性和性能一定打折。实际上做完这一轮我的感受是TaurusDB 这一档云原生数据库在能力上已经完全能接住传统商业数据库的盘子真正卡人的不是数据库本身而是团队有没有一套可落地的评估和迁移方法。这篇记录我就按自己的实操顺序来写不绕弯子凡是我觉得必须提前知道的事、必须提前准备的清单、以及容易翻车的细节都会尽量写明白。内容会有点长适合正在做数据库替换选型、准备迁移核心系统或者刚接手 TaurusDB 运维的朋友。1. 国产替代不只是换软件先想清楚这三件事1.1 为什么说“国产化”不等于“降级”很多人听到国产数据库第一反应是“老系统换新引擎性能和稳定性肯定要打折”。我自己在项目启动之前也有这种顾虑但实际跑完一轮才发现这种担心有一半来自惯性另一半来自对“国产数据库”这个概念的模糊认知。国产化替代的真正难点不在于数据库本身性能不够而在于它和旧生态之间存在大量隐性依赖。传统 Oracle 时代业务系统往往不只是“连一个数据库”那么简单。周边通常还挂着定时任务、数据仓库同步链路、报表系统、历史数据归档脚本、甚至某些同事手写的存储过程逻辑。这些都属于“隐性资产”它们不在代码仓库里却真实地运行在生产的每个深夜。替换数据库等于把这些隐性资产全部重新验证一遍任何一个环节漏掉上线当晚就会变成事故现场。幸运的是TaurusDB 是一个高度兼容 MySQL 8.0 生态的云原生数据库语法、驱动、工具链都沿用了 MySQL 的开源体系。这意味着大部分应用改造成本远低于 Oracle 到高斯或到达梦的迁移。但兼容不代表零改造尤其是从 Oracle 迁移过来时SQL 方言、事务特性、字符集行为都要逐个确认。项目组必须把这次替代当作一次系统重构来做而不是一次简单的数据搬迁。1.2 TaurusDB 在替代方案里的真实定位TaurusDB 最核心的特点是把计算和存储彻底拆开了。传统自建 MySQL 是本地盘或云硬盘存储计算节点挂了要等主备切换存储扩容也得停机或滚窗口。TaurusDB 的存储是分布式共享存储类似云厂商早期 Aurora 的思路一个主节点加多个只读节点共享同一份存储数据binlog 和 redo 的生成方式也和传统 MySQL 有很大区别。这种架构带来的直接好处有两点。第一只读节点的扩展非常快因为不需要像传统主从那样复制数据文件新节点挂上来直接从共享存储读数据即可。第二主备切换时因为存储层已经做到了多副本强一致数据丢失风险显著降低切换速度比传统主从快得多。对于企业核心系统来说这两点正是替代 Oracle 最需要的能力。和同属国产阵营的达梦、openGauss 相比TaurusDB 最大的优势在于 MySQL 生态兼容度。MySQL 和 Oracle 的差异化虽然存在但企业里大部分 Java 开发都有 MySQL 经验招聘和培养成本低。而且 Spring Boot、MyBatis、Druid 这些通用中间件天然适配 MySQL 协议接管应用侧几乎不需要改代码框架。我们最后选择 TaurusDB核心原因就是“团队学习成本最小、迁移路径最平滑”。1.3 动手之前把这份评估清单做完任何替代项目最忌讳的就是“边迁移边发现兼容性问题”。我们在正式迁移前花了整整两周做兼容性评估把所有应用涉及的表结构、视图、存储过程、定时任务、报表 SQL 全部拉出来过了一遍。这里有一份评估维度清单建议你直接照抄去用评估项检查内容重点关注表结构与数据类型字段类型映射、长度、默认值、自增列Oracle 的 NUMBER、DATE、CLOB 转换字符集与排序规则库表默认字符集、连接字符集、大小写敏感utf8mb4、utf8mb4_0900_ai_ci索引与约束主键、唯一键、外键、函数索引Oracle 位图索引不兼容需提前改造SQL 方言分页、字符串函数、日期函数、序列Oracle 的 ROWNUM、SYSDATE、DUAL存储过程与触发器语法差异、内置函数差异、游标行为Oracle PL/SQL 改为 MySQL 存储过程事务与隔离级别事务隔离级别、锁等待超时、大事务Oracle 默认读已提交MySQL 默认可重复读定时任务与外围脚本crontab、数据库 Job、同步链路旧 DBLINK 无直接替代需要中间层改造高可用与容灾切换时间、RPO/RTO 目标、跨可用区容灾对比原 Oracle RAC 的 SLA做完这份评估项目组基本就能估算出改造工作量。我们的结论是纯 SQL 层兼容问题占四成外围脚本与数据链路改造占四成剩余两成是团队熟悉度和运维体系重建。把工作量量化出来向管理层汇报时也有依据。2. 部署与规格规划先把地基打牢2.1 实例规格怎么选不要拍脑袋数据库实例规格选型是整个项目中我最想强调的一环。很多人喜欢按“以前 Oracle 多少核新库就买多少核”来直接对标这种做法在云原生架构下会失真。TaurusDB 的存储和计算分离意味着 CPU 内存规格只影响计算能力存储性能由分布式存储池决定两者不存在传统数据库那种“盘性能绑在计算节点上”的关系。我的建议是分三步走。第一步先看原库的峰值指标。可以从 Oracle 的 AWR 报告或云监控里拉出过去一个月的 CPU 使用率、内存占用、IOPS、活跃会话数。核心交易系统重点看活跃会话数和 IO 等待报表分析类系统重点看 CPU 和临时表空间。第二步按 TaurusDB 的规格档位做一个初步换算一般原 Oracle 峰值 CPU 不超过 16 核的业务选 8 核 32GB 或 16 核 64GB 起步就够了。第三步用真实业务流量做压测把最重要的三五个查询场景跑一遍观察资源水位和响应时间变化。以一个日订单量百万级的交易系统为例我们的实际配置是 16 核 64GB 主实例加 2 个只读节点。高峰期 CPU 稳定在 45% 左右IOPS 峰值不到 8000连接数峰值 1200 左右。这套规格在 TaurusDB 的定价体系下成本只有原来 Oracle 商业授权的零头。2.2 高可用架构与容灾设计数据库高可用不是“开了主备就万事大吉”需要从上到下串起来设计。TaurusDB 默认同可用区部署一主一备故障切换自动完成。但企业级核心系统我会建议再加一层跨可用区容灾把只读节点或灾备实例放到另一个可用区这样即使整个可用区出问题应用也能通过切换连接串继续对外服务。除了数据库本身的容灾应用侧连接配置同样重要。我的做法是在应用配置中心里单独维护数据库地址项日常指向内网读写分离地址容灾演练时统一切换到灾备实例地址。这里有个容易被忽略的点只读节点是共享存储的它们和主节点在同一份数据上连接负载均衡由 TaurusDB 的代理层自动完成应用不需要自己实现读写分离逻辑。对于 RPO 和 RTO 的设定我们最终定的是 RPO 接近 0、RTO 小于 5 分钟。这个目标在 TaurusDB 的存储多副本机制下是可以达到的前提是应用连接池的探活参数、超时参数必须配合调整否则数据库切换成功了应用侧连接池还是掐着旧连接不放故障恢复时间会被拉长。2.3 初始参数配置要点TaurusDB 控制台里有很多 MySQL 参数建完实例之后建议第一时间按业务情况调整不要全用默认值。我整理了几个最关键的max_connections默认值通常偏小核心系统建议设置到 2000 以上但要注意连接数上来后会占内存需要和实例规格匹配。wait_timeout/interactive_timeout默认 8 小时生产环境建议调到 300 秒左右减少无效连接占用。slow_query_log生产系统建议打开慢查询阈值long_query_time设成 1 秒方便后续性能分析。binlog_expire_logs_seconds如果要用增量同步或订阅下游建议保留 3 到 7 天的 binlog不要设置 0。character_set_server/collation_server无脑统一成utf8mb4和utf8mb4_0900_ai_ci避免后续建表时字符集混用。time_zone建议显式设置成08:00不要依赖默认系统时区否则 JDBC 连接时区不一致时间字段会出现 8 小时偏移。另外TaurusDB 是共享存储架构参数修改大部分可以在线生效但还是建议在业务低峰期操作并且改完参数后观察 15 分钟。一次不要同时改超过三四个参数否则出问题时很难定位是哪一项引起的。3. 数据迁移实操从 Oracle 到 TaurusDB 的平滑过渡3.1 迁移方案选型别迷信单一工具数据迁移是整个替代项目里风险最高的一环。我们的源库是 Oracle 19c数据量接近 3TB涉及 400 多张表其中还有 20 多张超过千万行的大表。迁移方案我们对比了两条路一是用华为云 DRS 数据复制服务做在线迁移二是自建脚本用 DataX 或 mysqldump 先导出再导入。DRS 的优势是能同时做全量加增量支持从 Oracle 到 MySQL 的格式转换表结构、索引、约束都能自动翻译。我们实际测下来Oracle 的 NUMBER、VARCHAR2、DATE、CLOB 这些主流类型转换准确率很高plsql 里的函数和存储过程不会翻译这部分需要人工改造。如果业务允许短暂停机完全可以用 DRS 先全量搬一遍再在割接窗口前追增量。自研脚本方案适合数据量不大、结构简单、DBA 团队对外围控制力强的场景。DataX 在异构数据库之间的字段映射灵活性高但增量同步这部分要自己实现成本不小。我们最终选择了 DRS 作为主力工具外围同步链路仍用 DataX 做备份方案。一句话总结能用成熟迁移工具就不要自己造轮子DBA 的时间应该花在验证数据一致性上而不是调脚本。3.2 全量加增量迁移的操作步骤这里把我们的迁移步骤完整列出来可以直接抄作业第一步源库只读性评估。确认哪些表可以接受短时间只读哪些业务表必须保持读写。第二步DRS 创建迁移任务填写源端 Oracle 连接和目标端 TaurusDB 连接执行预检查。预检查会校验账号权限、字符集、对象类型、主键等有报错先处理完再继续。第三步启动全量迁移。DRS 会自动完成表结构迁移和存量数据搬迁量级在 1TB 以下的库一般几个小时就能完。全量迁移完成后DRS 会自动进入增量同步阶段通过解析源库归档日志来同步增量数据。此时源库业务可以继续运行我们要做的是观察增量时延。当增量滞后时间持续低于 10 秒就可以准备割接了。割接窗口内先停应用确认源库无新事务等待 DRS 增量时延归零点“结束任务”然后把应用连接串切到 TaurusDB启动应用。这里有一个细节DRS 增量同步依赖 Oracle 的补充日志和归档日志迁移任务启动前要确保源库开了补充日志否则部分 update 操作可能无法准确解析。如果 DRS 任务报日志缺失比如归档空间被清理了那增量环节就得从头重来代价非常大。3.3 数据一致性校验不能只看行数割接前的数据校验是决定能否顺利切换的关键。只统计“表数量对不上”和“行数一致”远远不够因为字段值内容、顺序、精度都可能出错。我们的校验分三层第一层表数量与行数校验。用脚本对比源库和目标库每张表的行数差异超过阈值直接定位。第二层关键字段抽样校验。对大表和重要业务表按主键抽样查询关键字段比较数值、金额、日期类型的值。这里要注意金额字段的精度Oracle 的 NUMBER 有 scale转成 MySQL 的 DECIMAL 后精度必须对齐否则会出现 0.01 级别的财务差错。第三层业务逻辑验证。在准生产环境跑一遍核心业务链路用测试数据完成一笔完整的下单、支付、对账流程确认应用侧功能正常。写校验脚本时我习惯用一个公共方法把源库和目标库的连接参数、表清单抽出来按批跑输出异常报告。校验结果必须有留存交接给测试团队继续验证时也方便。3.4 回滚预案宁可备而不用数据迁移最怕的是“切过去了回不来”。我们执行割接前强制要求做冻结备份也就是在源库停止写入后打一个 Rman 或冷备份保证即使在 TaurusDB 侧数据全部损坏也能把源库恢复回割接前的状态。实际操作中我们的回滚预案分两个层次。第一层是应用回滚保留旧版的数据库连接配置切换后如果 TaurusDB 出现严重故障直接改回源库地址重启服务。这个方案最快但回滚后源库到 TaurusDB 的增量数据会丢失只适用于割接后很短时间内发现问题。第二层是数据回补如果割接后运行了一段时间才发现问题需要把 TaurusDB 的新增数据逆向同步回源库这个复杂度很高最好提前想清楚业务的取舍原则。我的建议是割接后至少保持双轨运行 48 小时源库以只读方式保留TaurusDB 承载完整读写流量。一旦发现重大问题应用立即回切到源库。过了 48 小时观察期再清理源库资源。4. 应用适配与 SQL 改造开发侧要动的那些地方4.1 连接方式与驱动调整应用连接从 Oracle 迁到 TaurusDB第一件事就是改 JDBC 驱动和连接串。团队里很多开发对 Oracle 的jdbc:oracle:thin:写法非常熟但换成 MySQL 协议时容易漏配参数。我们的标准连接串如下jdbc:mysql://读写分离内网地址:3306/database名?useUnicodetruecharacterEncodingutf8mb4useSSLfalseserverTimezoneAsia/ShanghairewriteBatchedStatementstrueallowPublicKeyRetrievaltrue几个参数逐个解释一下。characterEncodingutf8mb4必须指定否则字符集可能落到库表默认值上带来隐式乱码。serverTimezoneAsia/Shanghai必须和数据库侧时区一致否则时间字段会偏移 8 小时。rewriteBatchedStatementstrue建议开启可以让批量插入性能提升数倍。allowPublicKeyRetrievaltrue是针对 MySQL 8.0 以上驱动连接时的附加项不开有可能出现公钥检索错误。驱动版本建议统一使用com.mysql:mysql-connector-j8.0.x 以上旧版 5.1.x 驱动虽然兼容 MySQL 协议但连接属性和报错信息都不够完善排查问题很难受。另外连接池如果用 Druid需要把validationQuery设置为SELECT 1并调整testWhileIdle、testOnBorrow参数确保数据库主备切换时连接池能自动感知。4.2 SQL 与存储过程兼容性处理从 Oracle 迁到 TaurusDBSQL 改造是无法回避的工作。最容易踩坑的是以下几类分页查询。Oracle 用ROWNUM或FETCH FIRSTMySQL 用LIMIT。公司里一些老项目用的还是rownum ?这种写法必须手动改成LIMIT ?或LIMIT ?, ?。如果系统里有大量此类 SQL建议在改造阶段先全局搜索rownum集中提测。日期函数。Oracle 的SYSDATE、TO_DATE、TO_CHAR在 MySQL 中对应NOW()、STR_TO_DATE()、DATE_FORMAT()。类似逻辑如果写在存储过程里要格外小心因为 MySQL 存储过程对语法错误的提示远没有 Oracle 友好调试成本高。序列Sequence。Oracle 的序列在发号器场景中很常用MySQL 和 TaurusDB 没有 Sequence 对象原生自增主键是最接近的替代方案。如果业务要求不连续且有序的号段可以自己建序列表用事务加行锁实现但注意并发能力有限高并发场景建议交给应用侧发号器。字符串拼接、空值处理、隐式转换这些细节也很容易翻车。Oracle 的空字符串默认就是 NULLMySQL 里空字符串和 NULL 是两回事。如果旧代码里用空字符串判断过字段迁移后可能出现条件永远不成立的问题。我们的做法是整理一份新旧语法对照表发给所有开发要求提交代码前先自查。4.3 ORM 框架与连接池对接团队里主流的 Java 框架是 Spring Boot 加 MyBatis这块对接 TaurusDB 基本没有障碍因为 MyBatis 的方言很简单不涉及复杂的数据库差异。需要注意的反而是那些直接写 SQL 的接口比如用 JdbcTemplate 或 MyBatis XML 里写原生 SQL 的场景。我的建议是项目里所有 XML 文件里的 SQL 全部过一遍严格 review重点检查分页方式、函数调用、日期格式。另一个容易忽略的是事务配置。Oracle 隔离级别默认是 READ COMMITTEDMySQL 默认是 REPEATABLE READ。如果应用代码里没有显式指定隔离级别迁移后潜在行为会发生变化。比如某些报表 SQL 在可重复读隔离级别下可能因为一致性读快照导致读到旧数据。我们的处理是在关键事务方法上显式声明Transactional(isolation Isolation.READ_COMMITTED)避免隐式依赖。连接池的参数配置同样要按 TaurusDB 的特性调整。maxActive不能盲目设大因为每个连接都会占内存500 个连接对 16 核 64GB 的实例已经偏高。建议先按应用实例数量乘每个实例的池大小估算总量再结合压测结果回调整。maxWait建议保持默认 10 秒内太长了故障时请求堆积严重。4.4 慢 SQL 治理从 Oracle 执行计划到 MySQL 习惯旧系统在 Oracle 上跑 SQL习惯和 MySQL 差异很大。迁移后最容易出现的性能问题是原先能走索引的 SQL 在 TaurusDB 上走了全表扫描。我们割接后的第一周监控系统每天都能捞到几十条慢 SQL大部分问题集中在隐式类型转换和索引失效上。举一个典型案例。旧库订单表的order_no是 VARCHAR2用户输入查询条件时传的是数字字符串Oracle 里能正常走索引到了 TaurusDB 后因为表结构迁移把order_no定成了 VARCHAR(64)而应用传入的是 Long 类型MySQL 会做隐式类型转换导致索引失效。排查时看执行计划发现 type 是 ALL才定位到根因。解决方案是应用层强制把参数转成字符串再查询。慢 SQL 治理的关键不是一个个改而是建立固化的查询分析流程。我要求 DBA 每两天导一次慢日志按平均耗时排序挑出 TOP 20 条发给对应开发组限时优化。三个月跑下来整体慢 SQL 数量下降了一多半。数据库侧能做的优化主要是合理设计索引但根本还是开发侧要养成 MySQL 的 SQL 编写习惯。5. 日常运维与性能调优上线只是开始5.1 监控与巡检先盯住这几个指标TaurusDB 控制台自带监控面板CPU、内存、磁盘、IOPS、连接数都有曲线但只看面板远远不够。我建议搭建一套多维度的监控体系重点盯这些指标的组合CPU 使用率要和慢 SQL 数量联动看。CPU 突然升高先查慢日志看是否有新上线 SQL 走了全表扫描。磁盘 IOPS 要和读写延迟联动看TaurusDB 的分布式存储有缓存层一般 IOPS 不会成为瓶颈但如果有大量全表扫描IO 压力会异常升高。活跃连接数和线程数要配合看连接数高不一定有问题但活跃会话接近 80% 就要警惕。每天自动巡检时我习惯加几条 SQL检查是否有长时间未提交的事务、是否有锁等待、表空间碎片情况。下面这条是查长时间运行事务的改一下时间窗口就能用SELECT trx_id, trx_state, trx_started, TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS run_seconds, trx_mysql_thread_id FROM information_schema.innodb_trx WHERE TIMESTAMPDIFF(SECOND, trx_started, NOW()) 60;监控不设告警等于白做。我们用的是华为云 CES 云监控加告警规则核心指标全部接入企业微信机器人通知。阈值可以这样起步CPU 超过 80% 持续 5 分钟告警磁盘使用率超过 85% 告警慢 SQL 每分钟超过 20 条告警活跃会话超过 200 告警。上线后根据实际情况逐步收紧。5.2 备份恢复与 PITR别等出事了再验证备份这件事很多团队的态度是“开了自动备份就放心了”但备份是否可恢复、恢复需要多久、能恢复到什么时间点很多人并不清楚。TaurusDB 的备份分为自动备份和手动快照支持基于时间点恢复 PITR默认可以恢复到 7 天内任意秒级时间点。我的建议是核心库默认保留至少 7 天的备份并且每个月做一次完整的恢复演练。恢复演练切记要恢复到单独的新实例不要在原实例上操作否则万一误操作会把生产环境搞坏。演练时记录恢复所需时间一旦真实故障发生按演练数据评估恢复窗口是否满足 SLA。还有一个小细节TaurusDB 的自动备份默认是在每天的备份窗口内执行我建议把备份窗口设置在业务低峰比如凌晨 2 点到 4 点。同时备份是会占用部分 IO 资源的如果低峰期还有批处理任务运行要留意任务是否被拖慢。5.3 容量规划与扩容提前留出安全冗余数据库容量规划做得不好最容易在节假日前爆发事故。先看磁盘空间。TaurusDB 存储是共享存储池容量上限看总存储大小。我通常按“当前已用空间加未来 6 个月增量”来预留并且设置存储容量达到 80% 时预警达到 90% 时告警。特别要注意 binlog 空间如果下游同步链路长时间积压binlog 占用会持续增长磁盘容量可能被不知不觉吃满。计算资源扩容要区分两种场景。第一种是纵向升级就是直接变配更大的 CPU 内存规格。TaurusDB 支持在线变配不需要停业务但变配过程仍有秒级闪断风险建议在低峰期操作。第二种是横向扩展增加只读节点。分析类查询、报表类查询都可以通过只读节点分流但写压力大的场景加只读节点并不能解决根本问题。扩容之前一定要先在测试环境做一次相同操作的演练把影响时间评估出来。我们有一次生产变配原本预计 10 分钟完成实际执行了将近 30 分钟原因是表数量太多底层存储迁移耗时超出预期。有了这次经验后续所有变配操作都强制先做演练再上生产。5.4 版本升级小版本也别拖TaurusDB 服务端有内核小版本的概念云厂商会不定期发布补丁和性能优化。有的团队觉得“数据库不坏就不动”这在小规模环境可以但核心系统上我建议小版本升级也要有节奏地推进。我们的做法是先在测试环境升级验证跑完核心回归用例后再在生产环境低峰期升级。升级过程通常不需要重启实例但如果涉及内核参数调整可能会有连接闪断所以升级前务必通知应用团队并预留连接池重连时间。跨大版本升级要更谨慎。比如从 MySQL 5.7 内核升级到 8.0虽然 TaurusDB 有兼容层但底层字符集、认证插件、SQL 模式都有差异。我们遇到过连接报Unable to load authentication plugin caching_sha2_password的问题是驱动版本太老不兼容新认证方式。这类问题在升级前就要通过文档确认好并把驱动版本统一升级到位。6. 常见问题与避坑实录我踩过的几个坑6.1 应用连接池的连接被“静默杀死”上线第一周我们遇到一个诡异现象每天早上业务高峰应用偶发报错Communications link failure重启应用后恢复过几小时又出现。排查后发现是数据库侧wait_timeout设置偏小空闲连接被服务端回收应用连接池没有及时发现失效连接下次请求时继续使用旧连接导致报错。这个问题的标准解法是给 Druid 连接池配置testWhileIdletrue、timeBetweenEvictionRunsMillis60000、validationQuerySELECT 1让连接池在空闲时定期探活自动剔除失效连接。同时应用侧要有重连机制使用spring.datasource.hikari.connection-timeout之类的参数控制等待时间。我们的经验是数据库参数、连接池参数、驱动参数必须一起调任何一层不配套故障表现都可能不同。6.2 大事务把主从延迟和只读节点拖垮迁移后第一次大促前的压测我们遇到了只读节点延迟持续上升、甚至跟不上主节点的问题。定位后发现是后台任务里有一个定时脚本每天晚上对一张 2000 万行的流水表做批量更新单条 SQL 涉及几十万行。这个操作在传统 MySQL 主从里已经足够危险在 TaurusDB 的共享存储架构下大事务还会加大存储层压力导致只读节点读取延迟明显增加。解决措施是把大事务拆成小批每次处理 5000 行分批提交批次之间加短暂休眠。调整后只读节点延迟从持续数分钟降到了 1 秒以内。这个案例也提醒我们TaurusDB 虽强但 MySQL 生态的事务使用规约仍然适用大批量数据处理必须避免长事务。6.3 字符集和排序规则不一致导致的“奇怪”结果有一张用户表迁移后应用层反馈一个中文排序接口的结果和以前不一样。排查发现是老库表默认字符集是utf8mb4_general_ci而 TaurusDB 建库时我们用默认的utf8mb4_0900_ai_ci两者对中文排序的规则不同。问题本身不大但在报表系统里会让某些固定排序结果出现漂移。处理方式是统一规范所有新建的库、表、字段都显式指定字符集和排序规则不要依赖全局默认。迁移前 DRS 会自动翻译表结构但翻译出来的字符集可能和源库不一致需要在迁移完成后核对一遍。查询结果的比较和排序涉及中文和多字节字符的最好在测试阶段就确认排序结果符合预期。6.4 自增主键耗尽差点引发写入故障我们订单表的主键是INT类型迁移前的数据量其实不高但迁移后因为测试和补数据频繁插入自增 ID 逼近了INT上限差一点就无法插入新记录。这个问题的风险被很多人低估尤其从 Oracle 迁过来的表如果原主键是NUMBER(10)转换成 MySQL 后要特别确认类型长度。如果已经耗尽在线修改主键类型难度很大建议业务侧尽早把主键类型改为BIGINT。还有一种做法是使用雪花 ID 等应用层生成主键完全脱离数据库自增约束但改造成本较高。我的建议是所有新表主键直接使用BIGINT UNSIGNED AUTO_INCREMENT存量表在迁移时提前评估剩余可用空间快耗尽的大表提前规划改造。6.5 可重复读导致的报表重复行问题迁移后有一张对账报表在特定条件下出现重复数据开发排查了很久没发现问题最后定位到事务隔离级别。源库 Oracle 默认读已提交同一事务内每次查询能看到最新已提交数据TaurusDB 默认可重复读同一事务内多次读取的是同一快照对账报表里先查主表再查明细时明细表在两次查询之间被其他事务插入了新数据导致结果不一致。解决方案不是全局改掉隔离级别而是对报表这类需要实时读取最新数据的场景在事务注解或连接上显式指定READ COMMITTED。双向比较下来大部分业务场景可重复读没什么感知影响但历史报表和定时统计类任务要特别留意。代码里所有Transactional注解的隔离级别默认值都应该过一遍。6.6 快速排查问题参考表把常见问题按现象、可能原因、处理方案整理成一张表对 DBA 值班时很有帮助现象可能原因处理方案连接报 Communications link failure数据库参数超时回收空闲连接连接池没感知调整 wait_timeout 与连接池探活参数只读节点延迟升高大事务批量更新存储层压力大拆批提交降低单事务影响行数中文排序结果不一致字符集排序规则不统一统一 utf8mb4_0900_ai_ci迁移后核对自增主键写入报错INT 类型自增达到上限改用 BIGINT评估存量表剩余量同一事务查询结果不一致隔离级别使用可重复读对实时报表显式指定 READ COMMITTED慢 SQL 突然增多隐式类型转换导致索引失效检查执行计划修正参数类型磁盘使用率异常升高binlog 积压或备份空间占用清理过期备份检查下游同步链路写在最后的一点体会数据库国产替代这件事很多人以为难点在“选哪个库”开始做之后才发现真正的挑战是迁移的完整性和团队的协同节奏。TaurusDB 本身的能力已经足够成熟它的分布式存储架构、MySQL 生态兼容性、托管运维能力让我这个历经 Oracle 时代的老 DBA 都觉得很顺手。如果让我给一个刚准备启动类似项目的团队提建议我会说不要压缩评估周期不要跳过兼容性清单不要省掉恢复演练更不要低估应用侧 SQL 改造的工作量。准备越充分割接越平淡反而说明项目越成功。数据迁移只是替代的表象团队建立对新技术栈的掌控力才是这轮国产化替代真正的价值所在。