十年DBA老兵：鉴戒，重Java轻SQL乃机能大忌

小心翼翼，如履薄冰

没有任何的注释，代码中的表呀，字段呀什么的，我一个也不熟悉，独一密切的就是 select from where join group 这些被标绿的 SQL 要害字。

“这个 SQL 有什么机能症状？”

“跑起来很慢。”

“慢到什么水平？”

“或许必要半个多小时才气跑完。”

“数据量很大吗？”

“也许吧，我还没有执行过，只是听开拓职员这么说的。”

看来我不能从这位同事这里获得更多有代价的信息了。

按下 F5 查察执行打算：

执行打算中，表会见方法根基上都是 index scan，并且也并无大本钱的操纵。稀疏了，题目处在那边呢？我又回到 SQL 窗口，按下 F8，公然只见时刻过，不见数据出来。

在恒久与 SQL 相伴的日子里，我养成了一个风俗，喜畛刳边看着 Oracle 执行，一边说明代码，大有“我忙着说明，你也别闲着偷懒”的“小人嘴脸”。

这个 SQL 有两个部门，第一部门是用 with 封装了一个功效集，第二部门是对第一部门的功效集举办 group by 处理赏罚。按照过往履历，我将 SQL 复制到了另一个 SQL 窗口，选中 with 子句单独执行，秒出呀。

解除了子查询的机能怀疑，那么很显然题目是出在第二部门的 SQL。第二部门 SQL 包括了 group by，莫非是 group by 发生了机能题目。要知道，group by 等聚合操纵的机能对数据量是极其敏感的。莫非是 with 子查询的数据量很是大？

我赶忙 count 了第一部门 SQL 的功效集，表现不到 20 万数据。那就不该该呀，20 万数据做 group by 也不至于慢成“蜗牛”呀。

继承说明第二部门 SQL 代码，在 select 子句中，惊现 wm_concat 函数。此时，我照旧有些小感动的，由于在之前也碰着过因为 wm_concat 激发的机能题目。为了验证判定，我将 wm_concat 注释掉，按F8 运行，公然飞快，不到 1s 就出功效。

至此，通过解除法，病因是找到了：由 wm_conca t激发了机能题目。

顺藤摸瓜，随手牵羊

缘故起因已经找到，那么对症又该怎样下药呢？显然，从 SQL 成果上，wm_concat 是必需的，我也实行过用 listagg 来更换 wm_concat，可是会因高出 4000 字符而报错。

着实 wm_concat 函数之以是慢，就是由于以 task_name 为维度必要拼集的数据量太大导致的。莫非就无解了吗？

我转念一想，为什么要用 wm_concat 函数？应用措施在拿到这个字段后做什么用呢？在前端页面表现吗？

这种表现是没有多大意义的，由于 wm_concat 的功效也许很是大，基础就表现不了。既然表现不完备，那么为什么又要从 DB 中获取完备的内容呢？

带着这些迷惑，我与 SQL 开拓职员举办了雷同，原本，应用措施拿到这个 SQL 的数据后，并不是在前端页面揭示，而是在应用措施中继承加工处理赏罚，在颠末多少伟大的逻辑处理赏罚后，以另一种情势在页面揭示。

此时，多年的从业履历汇报我：既然可以用 Java 来实现的营业逻辑，那么必定也能在 DB 中通过 SQL 来实现，这样就可以避开 wm_concat 函数。

于是我刻意深入相识营业成果，但愿能从营业方案上有所打破。这样就形成了一个起源的事变打算：相识整体营业成果及逻辑-->相识应用措施处理赏罚逻辑-->改写 SQL 语句-->成果性测试-->机能循环调解。

在约莫两个小时的一对一讲授后，我根基上把握了整体营业成果及逻辑、应用技能架构及处理赏罚逻辑。

这个着实是一个报表揭示成果，是按地区、里程碑揭示两个相邻里程碑之间的时距离断，包罗打算隔断时刻与现实隔断天数（均匀）。

（编辑：湖南网）

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