记录岁月云明细账excel导出的性能优化

财务软件报表还是非常麻烦,因为使用excel最好的就是财务,但是通过java导出excel,使用easyexcel不用报表工具,不是这么容易。采用jprofile对一个导出操作进行监控,其中一家零售企业导出当月全部明细账,检测到工程师编写的这个逻辑执行了2807次。估计很多人难以想想,这种sql是怎么上生产环境的。原因在于如果针对没有多客户的公司,原先的写法是没有问题的,但是针对面向有25万用户的零售企业,这种问题就暴露出来了。
1
查询条件
在这里插入图片描述
导出的报表样式
1
2

1 分析需求
有些工程师有洁癖,比如我。别人的代码写不好,干脆重写,而不是改,哪些防御式代码估计工程师本人也未必能看懂。因此第一步是分析需求,而不是看别人代码的的逻辑。
上图分析

  • sheet的名称是根据一级科目创建
  • 报表有两种默认,一种带辅助核算,一种不带辅助核算。
  • 表格中的数据来自查询期间、账套、科目余额、凭证,和计算出来的本期合计和本年累计。

2 分析问题
从sql入手,而不是程序入手原因是因为去理解有些工程师的思路,个性化太强,而sql语句至少有一个标准。是理解起来最容易的语言。
下面查看多次执行的sql到底做了些什么?
2.1 acc_account_balance
通过分析可以看到acc_account_balance 分别执行了571、463、108次,合计执行了1142次
1
1
2
2.2 acc_voucher
acc_voucher执行了363、70、55、45,合计553次
2
2
3
2
2.3 acc_assisting_accounting
acc_assisting_accounting执行了376、51、42次
在这里插入图片描述
2

2.4 acc_account_set
acc_account_set执行了571次
2
2.5 acc_account_subject
acc_account_subject执行了36次
1
3 优化思路指引

  • 数据库:① 查询利用索引。② 减少查询次数。③ 缓存。
  • 程序:① 多线程并发执行,充分利用计算机资源。② 通过程序计算过滤,而不是数据库。
    4 开干
    4.1 使用CompletableFuture加载数据
    使用CompletableFuture中的任务编排,将所需要的数据加载进来,下面的科目是基础资料,采用二级缓存,这里就不讲了,mysql performance schema 实践,这篇文章我已经讲了3

从下图可以看到获取数据的时间从50s,下降到268ms,单纯的看数据获取,性能优化了99.47%,速度提升187倍2 4.2 组装数据优化
前一个环节只是组装数据,接下来要将这些数据,拼装成excel模板可以用到的数据 。这一款属于业务算法,如果有时间可以重写,但实际改造时间并不会给你太长时间,首先老板会觉得性能优化是员工自身的问题,根本不会在一这个。
我所做的是新建一个v2版本,如果有问题,原来的代码还能用,以免被人诟病,研发工程师内卷,相互轻视的事情也是经常发生的。
在这里插入图片描述
接着将上面的数据传入到一个方法中
1
然后复用之前的一些好的封装逻辑,如果不好可以重写,但还是要注意不要轻易把别人代码删掉,否则那些人有可能会记恨你。
内存中的计算是非常快的,所以筛选也通过流来实现,如下。你会发现你的程序飞快。
2
因为其他的算法不具备通用性,就不黏贴出来了,但总体思路就是这样,不需要把问题想得太复杂

5 实际效果
导出的sql只需要200多ms,这还是我本地的机器。服务器上更快,这个性能优化已经算是很成功了。
1
为什么我愿意把这些岁月会计云的优化分享出来,因为技术这东西老板们是不会关心的,这些属于通用性技术,并不像芯片那样具有核心竞争力。有好的经验分享出来,是一种回向。

  • 15
    点赞
  • 30
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

warrah

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值