大佬求助，生成 6000 条数据居然花费 30 分钟？

不知不觉，做开发已有 2 年，传统行业的 IT 开发，需求的大概是全能手，SAP 上了一期，对接了 SAP，了解了一些 ABAP 语法，写了几个接口，慢慢的对语言不在执着，对技术也不再执着，因为出身工厂，对工厂业务还算熟悉，对解决方案的思考还算比较热衷。所以就沉浸在计算的一块，但是技术算法认知的先天不足，所以想请大佬把把脉，以后的学习方向。比如以下一题：

一个财务的一个清账模拟功能
已知系统目前有几千个客户
计算周期为一月一次清账

大概业务逻辑如下：

有 3 个数组，第一个数组是客户组，大概有几千条。第二个数组是各个收款明细，有几千条，不一定全部客户都有，第三个数组是应收发票，大概有几千条，不一定全部客户都有
需求是每个客户的收款与发票对碰核销，记录每笔核销的记录及每个客户的期末余额。

目前这个模块我是通过暴力遍历实现的,但是速度太慢了，逻辑如下

遍历每个客户
读取该客户的收款及发票
遍历收款，取发票一条一条核销，一条销完，换另一张发票，未销完，记录发票 INDEX 及剩余金额
最后将结果批量插入数据库。大概 6000 多条核销明细花了我 30 分钟+ 不可忍受。

因为没到月末，基本收款及发票是不一定真实的，有可能会冲销掉。实时清账就有可能反清账，所以目前清账功能财务需求是预清账，点击就跑，期末定了再关账。

第二个问题是关于动态计算的表达式引擎问题，2W 条数据动态计算，用了 C#的库，居然还要几分钟。大概需求如下
一个单据，有很多属性，然后不同的属性，会对应不同的成本及利润计算公式。所以我把它放在前端用动态表达式的方式配置，而不是代码写 IF （因为情况大概目前有 70+种，再加以后的新的营销活动啥的，财务提一个需求就要改一次代码太麻烦，所以找了一些动态表达式的库，通过前端配置触发条件） for example.

某个人（参与 A 活动），提成是，毛利提成》销售额提成，则毛利提成，反之销售额提成
某个人是负责 A 区域的，结果此张单成交区域在区域外，提成需打折。
某个活动提成不计成本，直接按某个比例算提成。等等。

1.目前逻辑是，遍历 2W 条，先匹配布尔条件生效判定（可能不止 1 个布尔条件），但终归 70+种情况组组合，最后得到的算法，然后计算提成。

因为用了 C#的表达式引擎，Flee （ Fast Lightweight Expression Evaluator ）,目前用时 3~5 分钟，但是这 5 分钟不太适合体感使用，因为在结算的时候，表达式会调整的，然后重算验证就等的不耐烦了。

题外话：公司的技术大佬是中小方案很熟练，BS/CS 端直接上手，打印报表配置，运维都可以，中小企业不可少的人才，但是技术深度不行，喜欢代码一把梭，项目 MVC 还是我来了之后分的，以前直接控制器+静态类打天下，我想了一下我又不想成为绑定公司的人才，所以对多语言的学习比较抗拒，对技术逻辑比较感兴趣，对技术遇到的难题，也喜欢思考，但是非科班，所以很多时候都是暴力算法，然后因公司上市，业务发展的复杂度也越来越高，传统行业对 IT 技术人才是不太尊重，感觉目前的代码不重构，会因为复杂度，迟早黑盒子一样的存在.....

laminux29

2020-12-18 01:16:48 +08:00

1.C/Cpp 以及传统主流数据库，对于 1000 * ( 1000 + 1000 )规模的两层 for 循环或游标遍历，甚至 1000 * 1000 * 1000 规模的 3 层循环或游标遍历，根本毫无压力。

如果有瓶颈，需要分析瓶颈在哪。

比如常见的错误实践，在编程语言中这样写：

for
----for
----.----for
----.----.----string SQL = "SELECT *....";
----.----.----db.search(SQL)；

那么主要的瓶颈就在 [db.search(SQL)；] 这条语句这里，具体一点就是编程语言的数据库客户端驱动，与数据库的接口调用这里。这种问题需要把程序逻辑全部移动到数据库的存储过程里，然后编程语言这边对数据库进行一次调用，瓶颈就解决了。

2.就算不改这些东西，总体时间也只是 30 分钟的话，可以考虑增加 N 台服务器，把数据分为 N 组，每台跑一组，这样总体时间可以缩减到 30 分钟 ÷ N + 汇总时间。