这事儿我琢磨了好久，终于决定把公司那套跑了三年的MySQL系统迁移到瀚高数据库上。说实话，刚开始心里真没底，毕竟MySQL是开源界的扛把子，瀚高虽然也是国产数据库里的一把好手，但真要动刀动枪地搬家，谁都不敢打包票说零风险。但架不住政策要求和国产化的趋势，硬着头皮干吧。
先说说迁移前的准备工作。很多人一上来就想着用工具一把梭，结果数据倒进去发现乱码、字段对不上、存储过程跑不动，心态直接崩了。我踩过的坑是：一定要先做兼容性评估。瀚高数据库虽然兼容MySQL的语法，但细节上差别不小。比如MySQL里用自增，瀚高用的是类型；MySQL的在瀚高里压根不存在，你得提前把建表语句里的引擎定义去掉。我花了整整两天，把项目里所有DDL语句过了一遍，用瀚高官方提供的评估工具跑了一遍，发现大概有20%的语法需要手工调整。别嫌麻烦，这一步省了，后面就是填坑。
迁移过程里最头疼的是数据类型的转换。MySQL的在瀚高里对应，要改成，长度限制也得注意。我用了瀚高自带的迁移工具，它能自动映射大部分类型，但碰上字段就傻眼了。MySQL的类型在瀚高里对应的是，工具直接报错。我只能写了个Python脚本，把字段先转成字符串存到列里，再手动改成。还有类型，瀚高不支持，得改成约束加组合。这些细节看着小，但几百张表堆在一起，工作量真不小。
数据迁移完了，还得检查完整性。我写了个校验脚本，对比源库和目标库的行数、字段哈希值、主键唯一性。发现有个大表少了3000条记录，排查了半天，原来是迁移工具在处理字段时内存溢出了。解决方案是分批次迁移，每次只倒50万条数据，中间加个操作让数据库喘口气。还有索引重建的问题，瀚高默认的索引类型是B-tree，跟MySQL一样，但有些复合索引的顺序需要调整。我跑了一遍，发现原来在MySQL里秒出的查询，在瀚高上要等5秒，赶紧调整了索引字段的顺序，把过滤性最强的字段放前面。
性能调优才是重头戏。刚迁移完那几天，线上业务慢得像蜗牛，用户投诉电话打爆了。我翻遍了瀚高的官方文档，发现几个关键参数得改。首先是，默认只有128MB，我直接调到服务器内存的25%，大概8GB。然后是，这个参数控制排序和哈希操作的内存，默认4MB太保守，改到64MB后，复杂查询速度快了3倍。最坑的是，MySQL默认是4，瀚高默认也是4，但实际用的是SSD硬盘，应该改成1.1。改了之后，那些依赖索引扫描的查询直接从10秒降到0.5秒。
连接池和并发控制也得重新调。MySQL下我们用设到500，瀚高默认才100，业务一高峰直接报连接拒绝。我改到300，配合做连接池，效果立竿见影。还有，这个参数在MySQL里是50秒，瀚高默认是1秒，太容易触发死锁重试了。我调到5秒，明显减少了应用层的重试次数。别忘了开启，把超过2秒的SQL全记录下来，一个个优化。我抓出来20多条慢查询，大部分是关联查询里用了，改成后速度飞起。
应用层的调整也不能忽视。我们的业务代码里用了大量MySQL特有的函数，比如、、，这些在瀚高里都不支持。我改成了瀚高兼容的写法：用替代，用，用加组合。还有和的写法，MySQL直接用，瀚高得写成，其实语法一样，但要注意瀚高不支持后面跟变量，得用子句。这些改动不大，但牵一发动全身，每个存储过程和触发器都得重新测试。
说说回滚方案。迁移不是一锤子买卖，万一瀚高扛不住线上流量，得能快速切回MySQL。我做了三手准备：第一，保留MySQL主库的只读权限，每天用备份增量数据；第二，写了个双向同步脚本，用导出瀚高数据，再导入MySQL，但注意要处理数据类型转换和自增ID冲突；第三，提前跟运维同事演练了两次切换流程，从发现问题到切回MySQL，控制在15分钟内。虽然没用上，但有了这个兜底，心里踏实多了。迁移完成后，我跑了一周的压测，TPCC性能比MySQL提升了12%，但写入性能下降了8%，主要是瀚高的MVCC实现更保守。不过对于我们的业务场景，读多写少，完全够用。
