如要迁移到国产数据库，通过什么样的技术方案能使迁移对业务的影响最小化？

数据的迁移一般根据业务影响要求、数据量大小方面来选择相关的迁移方案。
一般国产数据库都会带有相关的迁移工具，或者一些开源的迁移工具。通过迁移工具迁移是十分简单方便的。通常的迁移工具都是有全量迁移和增量同步的，然后再来一个全量校验。例如OceanBase的OMS工具就支持全量迁移、增量同步、全量校验流程，这些都是在一个迁移任务里，图形化操作是非常方便的。
迁移方案简单的一句话是能够停业的情况下，通过工具一次性迁移，减少增量数据导致的数据不准确。由于停业窗口有限，不能停业的就通过迁移工具全量迁移+增量同步+全量校验流程。
注意事项：但要清楚每种迁移工具都是有局限性的，例如存储过程、触发器、无主键表、外键这些迁移要多加小心，有些工具可能不支持，需要充分测试。数据的校验不只要工具的校验，还要针对重要业务表进行业务数据的校验（例如sum（余额））。

这种迁移一般有三种方式：
1 全量离线迁移：需要停业务来保障一致性，建议设置好并发度，加快速度。例如分区表的多个分区都应该搞起并发来。
2 增量离线迁移：这种需要结合业务属性，找到不再修改的历史数据先行迁移，然后在增量迁移剩下的数据。操作较为复杂，需要业务支持。
3 同步复制迁移：这种依赖异构数据库之间有产品做数据同步，那么这种方式最快，最终切换一下就好。

补充一点：
如果数据结构改动小，可以让目标数据库厂商提供工具和协助迁移
如果数据结构改动大，那只能业务研发来迁移

看资源吧，影响最小那就系统并行，不论是在压力测试还是数据质量比对的情况下，都可以使问题得到体现

首先应该评估 数据库 的兼容性，如果没有解决主要的兼容性问题，即使完成了数据迁移也会影响实际使用。
在评估兼容性的同时可以考虑迁移方案，数据量小的环境使用备份恢复的方式可以完成；数据量大的一般借助厂商提供的数据迁移工具实现迁移

可以用OceanBase 的OMA 迁移评估工具先跑一遍，看下代码影响的程度，有一些老系统可能需要涉及到部份代码的改造比如像Proc*C 之类的，可以根据跑下来的迁移评估报告来进行迁移评估以及迁移策略的制定

跨数据库产品的迁移，还是要尽量结合目标数据库厂商的官方指导方案吧，兼容性和注意事项考虑周全一些。