是否存在数据库查询的规范形式？

Question

说我想制作一个“优化的查询生成器”。基本上是一个SQL查询优化器，它比基于时间/空间限制的SQL服务器更好。它将查询和数据库统计信息作为输入，并生成为目标系统量身定制的SQL查询，以便快速优化到近乎理想的计划。

需要支持多少SQL？是否有一个SQL的子集足够灵活，可以轻松描述大多数有用的查询，但足够小于完整的SQL，以使其值得将其修改为？如果您不需要“贴近机器”，还有更好的方法来描述查询吗？

我不是在想一个你将通过现有SQL处理的程序，而是一个用于创建新SQL的工具。 只要输入语言能够描述查询的要求，就不需要将 SQL作为输入。

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

---

正如有人指出这需要“大量产品特定知识”而且（例如嵌套的子查询与任何东西，应该使用什么样的索引，那种东西）正是该工具将是什么旨在封装，以便用户不需要学习该知识。

---

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

Answer 1

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

Answer 2

我很惊讶地听到你将SQL描述为“靠近机器”。 SQL本身是声明性的而不是程序性的，关系数据库的一个有趣方面是自由实现者必须进行创新，因为SQL本身对如何执行查询几乎没有规定。

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

Answer 3

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

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

编辑：

1. 我不认为大多数查询在如何执行方面都有很多选项，
2. 我认为你无法对SQL做任何事情来迫使数据库引擎以“你的方式”创建一个执行计划，即使你做得更好也是一个更优化的解决方案。
3. 除非您打算创建自己的数据库引擎！

我对这个问题非常困惑;它看起来像重新发明轮子，但没有马车安装它！？

Answer 4

您可能会发现“SQL Queries for Mere Mortals”中的模式非常有用，因为它们使用从英语描述开始的结构化规范格式。

在Safari在线，如果你想快速浏览一下。

Answer 5

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

问题在于，查询优化仅依赖于关系理论，而且非常依赖于DB的内部和所持数据的详细知识。即使您能够提取数据库的元数据，我怀疑您将难以产生比数据库本身更好的查询计划 - 如果您没有获得数据库的元数据，那么您的原因是无望的。

Answer 6

祝你好运 - 你选择与微软和甲骨文这样的公司竞争，这些公司的生活或死因是他们的查询优化者完全符合你的建议。将一个数据库产品与另一个数据库产品进行比较的第一种和主要方法是使用基准测试，其中相同的查询工作负载应用于每个数据库，进行定时测量，并且大多数情况下的获胜者由执行速度决定。

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

Answer 7

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

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