查询优化器的类型和内部工作原理是什么？

Question

据我了解，大多数查询优化器都是“基于成本的”。其他人是“基于规则的”，或者我相信他们称之为“基于语法”。那么，优化 SQL 语句的语法以帮助优化器产生更好结果的最佳方法是什么？

一些基于成本的优化器可能会受到 FIRST_ROWS() 等“提示”的影响。其他的则是为 OLAP 量身定做的。是否有可能了解关于 Informix IDS 和 SE 的优化器如何决定处理查询的最佳路径（除了 SET EXPLAIN）的更详细逻辑？是否有任何文档说明 SELECT 语句的排名，假设它已被索引，那么访问行的最快方法是什么？

我想“SELECT col FROM table WHERE ROWID = n”是最快的（排名 1）。

如果我没记错的话，Informix SE 的 ROWID 是一个 SERIAL(INT)，它允许一个最大值。 2GB nrows，或者它使用 INT9 作为 TB 的 nrows？ SE 的优化器是基于成本的，当它有足够的数据但它不使用像 IDS 优化器这样的分布时。

IDS'ROWID 不是 INT，它是行左页的逻辑地址 移位 8 位加上包含行数据的页面上的插槽号。

IDS 的优化器是基于成本的优化器，它使用数据 关于索引的深度和宽度、行数、页数和 由更新统计 MEDIUM 和 HIGH 创建的数据分布来决定 哪个查询路径成本最低，但没有语句排名？

我认为 Oracle 使用 HEX 值作为 ROWID。太糟糕了 ROWID 不能经常使用，因为行 ROWID 可以更改。所以也许优化器可以使用 ROWID 作为计数器来报告查询进度？我在“在查询完成之前开始查看查询结果”问题中提到的一个想法？我觉得在处理时报告查询的进度并不难，也许会以一些轻微的开销为代价，但提前知道会很好：“类似谷歌”的估计有多少行满足查询的条件，每 100、200、500 或 1,000 行显示它的进度，让用户能够随时取消它，并在它们被放入当前列表时开始显示符合条件的行，同时继续搜索？.. 这个只是一个例子，也许我们可以考虑其他简洁/有用的功能，这些元素或多或少都在那里。

也许我们可以比当前可用的更精细地微调每个查询？ OLTP 查询往往是静态的和预定义的。 “假设”更多的是 OLAP，所以让我们尝试为其添加更多控制和智能？因此，需要能够更精确地控制，而不仅仅是“提示/影响”优化器。然后，我们可以针对特定情况使用更多动态 SELECT 语句！甚至可能告诉 IDS 一次读取索引节点块，而不是一个接一个，等等。

Answer 1

对于 Oracle，您最好的资源是 Cost Based oracle Fundamentals。它大约有 500 页（按第 1 卷计费，但还没有任何后续行动）。

对于（非常）简单的全表扫描，有时可以通过 v$session_longops 监控进度。 Oracle 知道它必须扫描多少块，它已经扫描了多少块，它必须走多少，并报告进度。

索引是另一回事。如果我搜索客户“弗兰克”的记录并使用索引，数据库将猜测表中有多少“弗兰克”条目，但这种猜测可能会大打折扣。可能您有 1000 个“弗兰肯斯坦”而只有 1 个“弗兰克”，反之亦然。

当您添加其他过滤器和访问谓词（例如，可以选择多个索引的位置）时，它会变得更加复杂，并且在您包含表连接时会再次飞跃。这还没有涉及到关于远程数据库、域索引（如 Oracle Text 和 Locator）的复杂内容。

简而言之，它非常复杂。了解您是否负责调整大型应用程序很有用。即使对于基本开发，您也需要对数据库如何以物理方式检索您感兴趣的数据有一定的了解。

但我想说你在这里走错路了。 RDBMS 的重点是抽象细节，以便在大多数情况下，它们只是发生。 Oracle 雇佣了聪明的人将查询转换内容写入优化器，这样我们的开发人员就可以摆脱“语法摆弄”以获得最佳计划（不完全是，但它正在变得更好）。

Answer 2

我不太确定您的目标是什么，但这里有一些关于我最近阅读的 SQL Server 查询优化器的信息：

13 Things You Should Know About Statistics and the Query Optimizer

SQL Server Query Execution Plan Analysis

还有一个我刚刚使用 google 找到的 Informix：
Part 1: Tuning Informix SQL