在迁移至分布式数据库的过程中，传统数据库中的存储过程、自定义函数、触发器如何处理改造？
刚刚看了下TDSQL的官方文档，TDSQL 不支持 MySQL 的一些特性如下：
- 自定义函数。
- 视图，存储过程，触发器，游标。
- 外键，自建分区。
- 复合语句，如 BEGIN END，LOOP，UNION。
- 子查询，having 子句（但支持带 shardkey 的 derived table）。
我们知道银行业务系统中，使用了大量的存储过程以及自定义函数，但是在迁移至分布式数据库的过程中，由于TDSQL不支持这些。贵行是如何改造的呢？
各位老师能否分享一下经验？
4同行回答
分布式数据库在核心系统的应用，一定要重构应用。
重构应用就是业务逻辑尽量在应用层完成，在数据库都是简单的SQL语句，避免复杂查询和跨库处理。
Oracle针对数据库市场最重要的成功因素就是存储过程，使得应用用上瘾之后，数据库没法迁移。
侧面可知分布式数据库改造最简单场景就是替换DB2的场景。
- 您的意思是，重新写套业务应用来适配分布式架构，应用逻辑放到应用层；分布式数据库做数据存储层只负责数据的访存！
- 对，把复杂的应用逻辑放到应用层面，数据库尽量做简单的操作，当然，事务等基本的数据库要点，都仍由数据库来控制。
- 从设计角度讲，直接在数据库写很多复杂的sql，其实并不是好的设计，后续改造，即使原开发人员都很难看明白。只是限于时间等各方面的考虑，造成很多的改造需求，简单的在数据库语句方面叠加一些逻辑。
新一代的核心系统，其原型设计，在交易型已经不再使用存储过程，所以交易层面，所做的工作就是进行SQL的适配改写。
1、SQL改写是基础，是首先要完成的，主要有函数替换和语法替换。在这部分工作完成后，基本可以进行交易的试跑。初期，确实发现性能不尽如人意。经过对一个帐务类交易的一周的集中分析与优化，最终使性能达到预期。
2、所以SQL适配的第二部分工作，就是效率优化，这部分内容更多，持续时间也更长。性能存在问题的地方，主要是联表查询，联表查询优化的关键，则在于分区键shardkey的设计。
另外，日终跑批处理，原设计确实仍有使用存储过程，这部分则仍靠应用的拆分，将存储过程通过应用、临时表来完成相关工作。
使用分布式数据库要转换思路，不再或少用复杂sql，通过合理的表结构的全局设计，将语句简单化，才能适配。
如果应用在交易层都大量使用存储过程，那进行数据库的替换，确实将比较困难。
收起