Question

我有一个关于如何使用整体SQL查询处理错误的问题。我们正在使用Oracle PL / SQL。我们的大部分代码库都是逐行处理，最终导致性能极差。据我所知，最大的问题是PL / SQL和SQL引擎之间的上下文切换。

问题在于用户不知道出了什么问题。旧式会像：

某些数据上方的光标
如果数据存在，则在另一个表中激活SELECT（count），如果不显示errormsg
选择该数据
如果数据存在，则在另一个表中触发第二个SELECT（count），如果不显示errormsg
选择该数据
修改其他表格

这可能会持续10-20桌。它基本上就像一个C程序。可以将其改造为：

UPDATE (
  SELECT TAB1.Status,
         10 AS New_Status
  FROM   TAB1
  INNER  JOIN TAB2 ON TAB1.FieldX = TAB2.FieldX
  INNER  ..
  INNER  ..
  INNER  ..
  INNER  ..
  LEFT   ..
  LEFT   ..
  WHERE  TAB1.FieldY = 2
  AND    TAB3.FieldA = 'ABC'
  AND    ..
  AND    ..
  AND    ..
  AND    ..
) TAB
SET   TAB.Status = New_Status
WHERE TAB.Status = 5;

像这样的整体SELECT会极大地加速很多事情。我更改了一些类似的查询，这些内容从5小时缩短到3分钟，但这很简单，因为它是一项没有人工干预的服务。

问题是你如何处理这样的东西，有人填写某种形式并等待回应。因此，如果出现问题，他们需要一个errormsg。我想到的唯一解决方案是检查行是否已更新，如果没有跳转到另一个仍然执行所有单一选择以确定该错误的代码部分。但在每次更改后，我们都必须更新整体选择和所有单一选择。猜猜一段时间后他们会有所不同并导致更多问题。

另一种解决方案是一般的errormsg，它会导致每天进行100次调用，并且我们将50个变量替换为查询，杀死一些where条件/连接以找出过滤掉所需行的条件。

那么什么是正确的方法来获得性能并且仍然是用户友好的。目前我们的系统感觉无法使用缓慢。如果你按一个按钮，你经常需要等待很长时间（通常是3-10秒，对于一些更复杂的任务，需要5分钟）。

Answer 1

对于大量数据，基于集合的操作比基于行的操作更快。但基于集合的操作主要适用于批处理任务。 UI任务通常按行方式处理少量数据。

所以看来你的真正目标应该是理解为什么你的个人陈述需要这么长时间。

“如果你按一个按钮，你经常需要等待很长时间（对于一些复杂的任务，通常需要3-10秒才能完成5分钟”

这显然是不可接受的。同样清楚的是，我们无法解释它：我们没有诊断系统性能问题的访问权限或领域知识。可能你需要说服你的老板在几天的现场咨询中蹦蹦跳跳。

但这是一条探索的途径：锁定。

“许多其他人使用相同的数据，所以状态很重要”

也许您的问题不是由于查询速度慢，而是更新等待共享资源的语句？如果是这样，更好（即悲观）的锁定策略可能有所帮助。

“这就是为什么我说人们不需要了解更多”

数据结构决定了算法。业务域的特定性质及其数据的存储方式是编写性能代码的关键。为什么搜索中涉及20个表？为什么在这些表上运行查询需要这么长时间？ STORAGE_BIN_ID不是所有这些表的主键吗？

或者，为什么用户在个别垃圾箱上扫描条形码直到找到他们想要的？看起来为bin指定条件会更有效，然后基于集合的查询可以分配最接近其位置的匹配。

或许您正在尝试编写一个查询来解决多个用例？

整体SQL查询（在Oracle PLSQL中）和UX

1 个答案: