语法通用是因为需要遵守SQL标准所致，换言之如果没有了SQL标准的存在，则语法可能都会差异很大；性能上有差异是因为 每个数据库产品的优化器的算法是不一样的，就算都是B+树的算法，效率也未必一致。这需要应用开发商根据数据库的特点进行处理了。SQL性能的事情很难取巧...

如果开展市场调研，几乎所有的分布式数据库都在推出 for mysql和for oracle的版本，宣称兼容语法。我们在选型的时候，特别测试了兼容性，选取了真实业务代码，覆盖常用的业务数据库使用场景，去进行了测试。在测试过程中进行代码改造。从而得出代码改造率，和改造工作量。选则可接...

MySQL to PG, 迁移工具  mysql2pgsql  挺好用的.另外也可以考虑用  FDW (FOREIGN DATA WRAPPER)功能 将 MySQL数据拉到PG里去.

目前国产数据库的技术架构（除阿里云的PolarDB外），可以参考文章：https://cloud.tencent.com/developer/article/1574148。 以及 白鳝老师的：金融行业分布式数据库技术选型及成本分析：https://www.talkwithtrend.com/Article/257383。总之一句话：选择适合自己业务类型的数据库，以...

数据迁移后，前后环境处于静态切面，做数据对比是比较简单的。操作上可有几种方式： 1.自研-数据 可通过SQL语句完成简单的数据对比，如记录条目数，多维度统计报告进行比对。 2.自研-过程 可针对迁移过程中的日志的方式，通过代码提取对比。这种方式对目标库无影响。 3.外部工...

1.应用侧改造内容应用侧需改造内容，分为几个方面：1).数据处理逻辑这方面指使用数据库的业务逻辑，简单分为结构改造和语句改造。部分情况，可通过简单的Mapping方式去解决，但还有些需要重构逻辑，甚至重新设计结构来完成。有些特别复杂的或存在数据库端无法实现的逻辑，就需要第二方...

从商业数据库迁移到国产库，风险是来自多方面的：1.技术风险国产库的功能较大型商业数据库仍存在一定差距，需要在选型时期就有清晰认识。不同国产库架构不同、技术路线各异，需要建立符合企业自身要求的评测体系。通过完善的测试，对国产库有着全面细致的了解。虽然无法做到功能一...

以前还真接触过一类产品。叫做数据库一体机，大体的东西类似以前oracle收购sun以后推出的那种数据库宝箱，不过是在一台X86设备上整合了多套安装好的数据库，对于用户来说。不需要考虑数据安全配置。而只考虑使用就行了。数据库都是整合好的。用那个直接通过数据链接连那个...

OB OMS商业版本已经支持DB2迁移，其他的厂家未发现可以迁移DB2的自动化工具。相对来说，DB2数据库用的还是比较少，一般都是商业性银行，但是现在也很少用了，导致DB2数据库迁移缺少练手的机会。开源类迁移DB2的组件比较多了，像flink，datax都可以实现数据的迁移。...

针对数据校验，如之前谈到可以有多种方式。对于比较重要的系统，对数据一致性要求很高，可能综合应用多种方式进行比对。对于小系统来说，选择其中一种进行比对即可。