Oracle 和 DB2，比较和兼容性/流程模型/优化器
速度优先。
用户与数据库中数据交互的方式是通过查询，在多用户系统中，查询量可能非常高。根据查询类型，它们也可能非常复杂。体量和复杂性的双重因素意味着 DBMS 分配用户请求的效率至关重要。为了实现这一点，查询优化器（简称为优化器）会分析用户查询并找出执行它们的最佳方式。优化器的工作方式是查看查询可以分解和实现的每种可能方式（查询计划），然后计算每个计划的开销（或成本）。开销成本考虑诸如将产生多少磁盘 I/O 以及所需的 CPU 量等因素。这些信息通过存储在内存中的数据字典提供给优化器，并且数据字典中的信息由从数据库表收集的统计信息填充。
这种优化方法称为基于成本的优化，Oracle 和 DB2 都使用它。还有一种基于规则的历史优化方法，恰如其分地称为基于规则的优化。基于规则的优化不再使用，这里仅出于完整性考虑提及。
优化器使用数据字典中的索引统计信息，因此默认情况下，优化器的效率是索引统计信息准确性的函数。虽然优化器使用这些统计信息来创建每个查询计划，但索引统计信息的变化率取决于表上的插入、更新和删除活动。虽然单个表的波动性决定了需要更新索引统计信息的频率，但此信息不会立即提供给优化器，并且更新统计信息需要完全扫描表——这不是一项简单的任务。
对于大量修改的大表和大量表，统计信息可能会很快过时。在这种情况下，优化器可能无法选择最佳执行路径。此外，异常情况（例如具有索引的小表（可以容纳在几个块或页面中的表））会影响优化器。优化器使用索引统计信息，因此如果这些小表上存在索引，即使表扫描效率更高，优化器也会使用这些索引。这是因为可以使用单个 I/O 访问该表。要使用这些表上的索引，需要读取索引（Oracle 和 DB2 都将索引与表数据分开存储），然后读取页面（或块）——两个代价高昂的 I/O 操作。根据任一数据库中的扩展大小，可以使用单个 I/O 获取整个表。因此，Oracle 和 DB2 都允许您覆盖优化器做出的决策。
总的来说，这就像调整汽车的引擎，您希望最大化性能并最小化油耗——由于这两个目标之间存在明显的权衡，因此如何平衡这些权衡非常重要。虽然不可能在无限的性能和零资源消耗之间实现完美的平衡，但目标是接近，并且这些权衡可能会产生戏剧性的后果——您可以做出损害性能和占用资源的决策。调整值也可能成为收益递减的练习，并且普遍共识是，一旦您将其调整到所需的位置，就将其固定并保持不变。