管理非常大的 SQL 查询

Posted 2023-03-29

【中文标题】管理非常大的 SQL 查询

【英文标题】：Managing very large SQL queries

【发布时间】：2014-08-07 15:21:03

【问题描述】：

我正在寻找一些在 Oracle 中管理超大型 SQL 查询的想法。

我的雇主希望为每个报告构建非常广泛的报告 (150 - 200) 列数据。 每个项目都是一个子查询或视图中的一个元素。数据必须是实时的，所以 DW 风格的批处理不是一个选项。我们也没有使用任何 BI 工具，只是一个生成 Excel 的 java 应用程序（需要在 Excel 中输出数据）

查询还包含联合作为来自其他系统的提要。 查询会产生非常大的 SQL（大约 1500 行），很难管理。

我可以采用哪些策略来使工​​作更易于管理？

这也不是性能问题。我能够将查询优化得非常高效，它主要是查询的宽度，管理 200 列本身就是一个挑战。

【问题讨论】：

这种开放式问题更适合programmers.stackexchange.com

我讨厌当我有一个长长的答案几乎完成时人们关闭这样的东西。这是一个可以回答的问题。

@HLGEM 到目前为止，它获得了 3 次重新投票，所以如果你仍然有这个答案，请坚持下去

我知道这对你没有多大帮助，但这种数据集实时 500 列）不可能被人类消费。你能澄清一下这是人类实际使用的还是数据馈送？是否有人运行 500 列 Excel 提取，以便将其输入到他们的小型独立 Excel 模型中？

嗯.. 这是百万美元的问题。客户以非常严格的格式规则要求 Excel 格式的数据，以及他们如何分析数据，我们无法了解。最终最终版本最终由监管机构完成，据我所知，它相当长。我是金融行业的新手，但 Excel 和 Access 是他们主要的数据分析工具。

【参考方案1】：

我每天都会处理这么长的查询，以下是一些有助于我维护它们的方法：

第一个别名这些列中的每一个。当您构建它时，您可能知道每一列的来源，但是当需要进行更改时，准确了解每一列的来源真的很有帮助。这适用于连接条件、分组依据和位置条件以及选择列。

组织成易于理解和可测试的块。我使用临时表将有意义的东西拉到一起，因此在测试模式下我可以在最终查询之前看到结果。

这让我进入了测试模式。如果我有大量数据，我会使用测试模式设计 proc，然后在测试模式下查询各个临时表，这样如果有错误，我可以看到数据出错的地方。不知道 Oracle 是如何工作的，但是在 SQL Server 中，我将它作为最后一个参数并给它一个默认值，这样它就不需要由应用程序传入。

考虑记录执行细节和传入参数的值，当然还要记录任何错误消息。当您必须解决为什么这个已经完美运行了六年的报告不适用于这个用户时，这将非常有帮助。

将每一列放在单独的行上，并且对 where 子句执行相同的操作。有时您可能不得不通过注释掉连接来解决问题，直到找到导致问题的连接。如果您也可以轻松地注释掉关联的字段，那就更容易了。

如果您没有技术设计文档，那么至少使用 cmets 来解释您的思考过程。您想了解为什么而不是任何 cmets 中的方法。这些东西以后很难回过头来理解，即使你写了它。给未来的自己一些帮助。

在从头开始开发时，我将选择列表放入其中，然后注释除第一项之外的所有内容。然后我只构建查询直到我得到那个值 - 测试直到我确定我得到的是正确的。然后我添加下一个以及任何连接或我可能需要获取它的条件。再次测试确保它是正确的。 （糟糕，当我添加它时，为什么从 1000 条记录变为 20000 条？嗯，也许我需要在那里处理一些事情，或者对吗？）一次只添加一个东西，你会发现逻辑中有很多错误更快，对您的结果更有信心。与尝试一次性构建大量查询相比，它花费的时间也更少。

最后，了解您的数据是无可替代的。有很多复杂的查询有效，但没有给出正确的答案。知道您是否需要内连接或左连接。知道你需要什么条件才能得到你想要的记录。知道当您有一对多关系时如何处理记录（这可能需要推回要求）；您应该有 3 行（每个子记录一个），还是应该将该数据放在逗号分隔的列表中，或者您应该只选择众多记录中的一个并使用聚合有一行。如果是后者，选择要保留的记录的标准是什么？

【参考方案2】：

在没有看到您的问题的具体细节的情况下，以下是一些立即浮现在脑海中的想法：

如果您只是在寻找管理，我可能建议您将子查询组织为多个 views，然后在最终查询中引用这些视图。

另一方面，为了提高性能，您可能需要考虑创建临时表甚至 materialized views（它们是固定视图）来分解流程中较重的部分。

如果您的查询需要大量子查询才能获得可用数据，您可能需要重新考虑您的数据库设计并可能创建多个datamarts 以轻松访问报告数据。将这些视为没有多年趋势数据的小型仓库。

最后，我知道您说过您不使用任何 BI 工具，但是通过将您的数据组织成“多维数据集”或业务对象“宇宙”，这个问题似乎很有意义。至少考虑一下引入 BI 工具的成本与支持当前设置的编程时间可能是值得的。

【讨论】：

感谢您的回复。数据集市是个好主意，但是在需要实时数据的地方是否可以支持设计？报告必须反映数据的实时视图。

我相信它可以使用适当的工具。我应该强调我不是 DBA，所以我在实际设置数据集市方面的经验是有限的，但我已经看到这解决了过去的报告问题。我目前的 App 团队有一些基于物化视图创建的仓储表，但这些数据每晚更新一次，而不是实时更新。

我必须为这个出色的答案添加一件事：我们有超过 50 列的报告，每一个都是用 CASE 语句计算的，因此我们使用存储条件的 excel 表。我们通过 ETL 工具访问它，但您也可以在 java 代码中进行访问。因此，当经理想要在 XYZ 列中添加一些条件时，我们只需将其添加到 Excel 表 XYZ 并重新运行主查询。