数据库查询有规范形式吗?

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

布拉姆哈,我不知道你是否知道你在问什么。SQL优化不仅仅是确保查询组件的顺序正确。您似乎认识到,您需要对索引、数据页布局等有深入的了解,但是除非您获得SQL Server查询处理器的适当“挂钩”,否则您将只能重新排列查询子句。因为微软就是这样做的——它本质上是将查询“编译”到更深层、更基本的层次,以优化数据访问。

嗯…有九个关系运算符(扫描、跳转、散列合并等)被用来构造SQL查询的执行计划(我想,太懒了,不能用谷歌搜索了)。运算符的选择基于目标数据库表的使用统计信息、可用索引等。

听起来你在试图重新创建查询计划器已经做过的事情。。。?

1. 我不认为大多数查询在如何执行方面有那么多选项,而且
2. 我不认为你可以对SQL做任何事情来强迫DB引擎“按你的方式”创建一个执行计划,即使你做了一个更好的解决方案。
3. 除非您计划创建自己的数据库引擎!

您可能会发现“针对凡人的SQL查询”中的模式非常有用,因为它们通过从英语描述开始的结构化规范格式工作。

在线时间 Safari ,如果你想看一眼。

您是否打算为单个特定的数据库引擎编写此文件?如果不是的话,我想你的日子会很艰难。数据库查询的优化在很大程度上依赖于引擎实现和内部的确切细节,以及表、索引、主键/外键关系、数据类型和分布等。创建优化查询的实际逻辑可能在不同的数据库引擎之间几乎没有重叠。(至少对于MySQL来说,表类型在优化上会有很大的不同。)每个受支持的DB引擎的每个版本都可能有显著不同的特性——请记住,如果要生成SQL,然后,您需要能够预测引擎自己的优化器/查询规划器将如何处理生成的SQL。

问题是,查询优化只依赖于关系理论,而非常依赖于数据库内部和所保存数据的详细知识。即使您能够提取数据库的元数据,我怀疑您也很难制定出比数据库本身更好的查询计划——而且如果您没有得到数据库的元数据,那么您的理由是没有希望的。

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

如果你能用他们的产品在这些基准测试中比出版商做得好得多,全世界都会印象深刻。不管你用哪一个,至少你会有一个稳固的职业机会。

例如,他们发现在大多数系统中有一个WHERE子句,比如 WHERE column1 = 'A' AND column2 = 'B' 将从左到右进行评估,但在Oracle中是从右到左的(在某些条件下,以及在他们编写本书时最新的Oracle版本中)。因此,在Oracle中,最不可能出现的情况应该放在最后,而在大多数其他系统中则应放在第一位。