记一次曲折的性能优化经历

前几日，有个用户提了个需求：

他系统里面有个按钮，用户点了这个按钮后，需要把系统里面的数据更新为最新状态。而需要同步的数据位于另一个系统，总行数大概14W行。数据库不能直接连接。那个系统对外暴露了一个一次只能返回1000条数据的接口。

一、最直观的想法，循环请求那个API接口，把返回的JSON反序列化了，循环变量数组，使用数据表插入命令逐行插入。
经过测试，发现这种方式非常慢，3000行数据用了20分钟

二、活字格服务端命令支持执行SQL命令

可以通过拼接SQL语句，利用INSERT语句可以一次插入多行的特性，与数据库建立连接一次，批量写入数据。这种方式能够降低循环次数，提高效率。

这个思路来自于低代码开发实践（https://help.grapecity.com.cn/pa ... ion?pageId=78939725）此处


三、因为用户点击按钮是系统无法预测的，点了后要同步这么大数据量的数据。这个需求本身听起来就非常离谱。所以可以换个思路，我们利用活字格计划任务功能的定时任务，让批量更新数据的task在每天固定时间点执行，比如每天凌晨1点执行、每半天执行一次。如果用户能够接受数据的更新频率如此，那么这个方案就是可行的。

四、目前数据量是14W，那么后面到40W，100W呢？哪怕是计划任务，大数据量同步其实也是需要大量时间的。这个时候可以再换个思路：本系统对外通过服务端命令暴露API接口，接口里面进行数据的更新逻辑。在另一个系统中，找一些切入点。比如当数据表发生插入、更新、删除时候，调用下本系统的API接口。
这种思路把大量数据同步分解为了一次次的小任务，从而提高数据同步效率。

论坛里的大牛们，相信你们也会有更多的好办法，不妨评论区说出你的想法哦

数据库Binlog监听同步？

之前做 logstash 同步 数据库到 es 任务时候,有个类似的情况。
当然会对要同步的系统有些限制，这里只说方案，就暂时不考虑其他限制，以下描述中以A数据库表示对应接口的数据库，B数据库表示 我们要实现同步的本地数据库
1. A 数据库实现 最新更新时间字段，当 upsert 发生时都会生成当前时间作为该更新字段的值
2. B 数据库去存一个上次更新时间
3. 系统开始同步任务
    ① 获取本地上次更新时间
    ② 获取A系统中 最新更新时间 大于本地更新日期的数据
    ③ 使用Task 任务 批量 upsert 获取到的数据 到 B 数据库，更新本地上次更新时间
注:  这个思路其实是在 正文中提到的 小更新机制的 另一种体现，将大任务拆解为多次小任务，当然 为了避免漏数，再设置 上次更新时间时，尽量做到时间窗口的一部分重合。还有就是 Delete 需要实现软删除，硬删除就处理不了了。

nimotea 发表于 2023-7-31 14:56
之前做 logstash 同步 数据库到 es 任务时候,有个类似的情况。
当然会对要同步的系统有些限制，这里只说方 ...

活字格中数据库里的表自带了一个最新更新时间，是自动更新的；
活字格的全局变量可以存储上次更新时间；
活字格的计划任务支持监听数据库里的具体表，可以在后台触发执行；
软删除在活字格中也很方便实现；

综上，这个思路应应该可以落地的。