2

假设我想做一个“优化的查询生成器”。基本上是一个 SQL 查询优化器，它比基于时间/空间限制的 SQL 服务器中的优化器要好得多。它将查询和数据库统计信息作为输入，并生成为目标系统量身定制的 SQL 查询，该查询将快速优化为几乎理想的计划。

需要支持多少 SQL？是否有一个 SQL 子集足够灵活，可以轻松描述最有用的查询，但又比完整的 SQL 小，值得将其缩减为？如果您不需要坚持“靠近机器”，还有更好的方法来描述查询吗？

我不是在考虑一个程序来处理现有的 SQL，而是一个用于创建新 SQL 的工具。只要输入语言能够描述查询的要求，实际上不需要将SQL 作为输入。

我想问题的另一种形式是：它们的 SQL 的任何部分是否仅用于性能并且从不提高可读性/可理解性？

正如有人指出的那样，这样做需要“大量特定于产品的知识”，并且（例如嵌套子查询与其他任何东西，应该使用什么样的索引，诸如此类）正是该工具旨在封装的内容这样用户就不需要学习这些知识。

注意：我对生成实际的查询计划不感兴趣，因为那是 DBMS 的工作，无论如何都不能从 SQL 中完成。我对一个系统感兴趣，该系统可以从不需要为该 DBMS 调整的输入中自动为给定 DBMS 生成良好的 SQL 的工作。

4

7 回答 7

4

听到您将 SQL 描述为“接近机器”，我感到很惊讶。SQL 本身是声明式的，而不是过程式的，关系数据库的有趣方面之一是实现者必须创新的自由，因为 SQL 本身很少规定应该如何执行查询。

我认为纯粹的实用性，很难改进 SQL。我并不是说它是完美的语言，但它是关系（甚至一些非关系）数据库的通用语言。

于 2009-01-13T01:57:54.280 回答
2

Bramha，我不确定你是否知道你在问什么。SQL 优化不仅仅是确保查询组件的顺序正确的问题。您似乎意识到您需要对索引、数据页面布局等有深入的了解，但您仍然只需要重新排序查询子句，除非您在 SQL Server 查询中获得了适当的“挂钩”处理器。因为这就是 MS 所做的——它本质上将查询“编译”成更深、更基础的级别，以优化数据访问。

于 2009-01-13T01:56:33.533 回答
1

嗯...有（我想，懒得去 google 了）九个关系运算符（扫描、跳转、哈希合并等）用于构建 SQL 查询的执行计划。运算符的选择基于目标数据库表的使用统计信息、可用索引等。

听起来您正在尝试重新创建查询计划器已经执行的操作...？

编辑：

  1. 我认为大多数查询在执行方式上没有那么多选择，并且
  2. 我不认为你可以对 SQL 做任何事情来强制数据库引擎以“你的方式”创建一个执行计划，即使你做了一个更优化的解决方案。
  3. 除非您打算创建自己的数据库引擎！

我对这个问题很困惑；看起来像是在重新发明轮子，但没有马车可以安装它！？

于 2009-01-13T03:02:41.607 回答
0

您是否打算为单个特定的数据库引擎编写此代码？如果没有，我怀疑你会度过一段相当艰难的时期。数据库查询的优化在很大程度上依赖于引擎实现和内部的具体细节，以及表、索引、主/外键关系、数据的类型和分布等。创建优化查询的实际逻辑将不同的数据库引擎之间可能几乎没有重叠。（就此而言，至少对于 MySQL 而言，表类型会对优化产生巨大影响。）每个受支持的数据库引擎的每个版本也可能具有显着不同的特征——请记住，如果您正在生成 SQL，那么您需要能够预测引擎自己的优化器/查询计划器将如何处理您的 SQL

问题是，查询优化仅微弱地依赖于关系理论，并且非常依赖于对 DB 的内脏和所持有的数据的详细了解。即使您能够提取数据库的元数据，我怀疑您将很难制定比数据库本身更好的查询计划 - 如果您没有获得数据库的元数据，那么您的原因是没有希望的.

于 2009-01-13T04:41:37.553 回答
0

您可能会发现“普通人的 SQL 查询”中的模式很有用，因为它们通过以英语描述开头的结构化规范格式工作。

如果您想快速浏览一下，请访问Safari在线。

于 2009-01-13T01:50:55.993 回答
0

祝你好运 - 您选择与 Microsoft 和 Oracle 等公司竞争，这些公司的生死存亡取决于他们的查询优化器是否完全按照您的建议执行。将一个数据库产品与另一个进行比较的第一种也是主要的方法是基准测试，其中对每个数据库产品应用相同的查询工作负载，进行时间测量，并且在大多数情况下，获胜者取决于执行速度。

如果您可以使用他们的产品在任何这些基准测试中做得比发布商好得多，那么世界将会给世界留下深刻的印象。至少你将有一个坚实的职业机会，无论你使用哪个（S）。

于 2009-03-01T02:52:26.587 回答
0

到目前为止，这是一个非常古老的问题，我同意其他大多数答案，即它可能有点误导。但它有一些东西。您是否阅读过 Gulutzan 和 Pelzer 的“SQL 性能调优”（Addison-Wesley，2003 年）？它比较了许多 DBMS，以及等效但不同形式的查询如何影响执行时间。换句话说，查询优化器中存在哪些特质和错误。

例如，他们发现在大多数系统中，WHERE 子句（例如）WHERE column1 = 'A' AND column2 = 'B'将从左到右进行评估，但在 Oracle 中从右到左进行评估（在某些条件下，并且在他们撰写本书时当前的特定 Oracle 版本中） . 因此，在 Oracle 中，最不可能的条件应该放在最后，但在大多数其他系统中应该放在首位。

于 2017-06-14T12:41:49.553 回答