十年DBA老兵：警惕，重Java轻SQL乃性能大忌

为了实现这种结构转换，当时的架构设计如下：

1. 通过 SQL 从 DB 获取每个里程碑、交付区域的 plan_start_time、plan_end_time、actural_start_time、actural_end_time 及 du 集合，即 SQL 中的 wm_concat 拼凑后的结果。

2. Java 应用程序拿到这个结果后，循环结果集，并依次分解由 wm_concat 拼凑的内容：

• 计算每一个里程碑内 DU 的平均时间间隔；

• 判断里程碑的前后置关系；

• 计算前后置里程碑间的天数间隔；

• 最终将计算结果展现在前端页面。

水到渠成，一战而定

从上述描述中，我们可以提炼出如下信息：

• WM_CONCAT 拼凑的内容只是过渡的，在 Java 中还需要依次分解。

• Java 处理的几个步骤完全可以由 SQL 来实现。这样就可以省却以下几个“麻烦”：

1. 省却了大量数据从 DB 传输到 Java 服务器的成本开销。

2. 可以顺理成章的拔掉 wm_concat 这根刺。

那么，如果用 SQL 来实现上述逻辑功能，存在两个难点，其一是如何判断里程碑（task_name）前后置关系，其二是计算前后置里程碑的时间差。

进一步分析后发现，里程碑（task_name）前后置关系可以通过 SQL 来获取，而在时间间隔的计算上，可以通过 lead 窗口分析函数获取后置时间，然后相减即可。

改造后的 SQL 如下：

将 SQL 在 DB 中运行，不到 3 秒就执行完成。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!