核心应用和分布式数据库的适配性改造难点有哪些？

应用和分布式数据库的适配性改造是难度最大以及最需要资源投入的部分，既需要应用的适配改造，甚至数据库层面也需要做一定的改造，我行采用的方式是找专业的团队做专业的事，找应用的厂商做应用，找数据库的厂商做数据库，最关键的是由行方、应用厂商、数据库厂商组成技术攻坚小组，专门解决各类改造过程中的问题，也能达到培养行方开发和运维人员的目的。

我行新核心系统的整个改造实施过程分为两个阶段，第一个阶段是产品适配和功能性改造，第二个阶段是性能优化。整个改造过程是从简单到复杂，我们是先从高频交易入手，集中处理与高频交易相关的业务以及子系统，然后是跑批类交易，跑批与高频交易相比， SQL 相对复杂冗余但是占总交易类的比重较低。解决了高频交易其实就已经解决了大部分匹配问题，我行在这个过程中积累了丰富的调优经验，这些经验再应用到其它业务系统中可以更方便迅速地解决问题。

总的原则就是尽可能让 SQL 语句限制在同一个数据节点内，减少跨节点数据关联查询。

这里列举几个调优的经验：

1） 分布式数据库数据是分布在多个节点的，当需要进行多表关联时，如果分区键设置不合理，关联查询嵌套较多，就无法避免数据在节点间流动，导致查询效率较低。针对这个问题，从以下几个方面进行优化：

a) 对所有的库表进行重新设计，合理设置分区键，分区键也是表的字段，表根据分区键字段将数据打散在各个节点，因此分区键设置时要从全局和交易局综合考虑，将交易中经常用来关联的字段设置为分区键，比如客户账户。

b) 对于更新评论较少且数据量不大的表，建议设置成全局表，即每个数据节点保存该表的全量数据，这样分片表和全局表进行关联时，也不会有节点间数据流动。

c) 对复杂 SQL 进行拆分，控制 SQL 嵌套层次，一条 SQL 控制只有两个表进行关联，嵌套不超过两层。拆分过程中可以考虑使用临时表（中间表），将中间数据放到临时表，中间表进行承上启下的关联。

d) 对交易业务逻辑进行重新设计，避免复杂 SQL 。

e) 数据库层面进行查询逻辑优化，支持复杂某些复杂 SQL 。如：子查询上提、左连接消除、丰富下推逻辑以及基于统计信息的条件推导逻辑等，尽可能提高处理这种复杂 SQL 语句的性能。