数据库查询优化器是否意识到存储性能差异？

据我了解，SQL Server（或其他任何RDBMS）中的查询优化器并不了解数据库下面存储的性能，并且会像所有存储具有相同的成本一样做出决策。这是否准确，或者是否考虑了一些有关存储性能的知识？

在一个完全人为的示例中，假设我的表行以瞬时访问时间存储在SAN中的SSD驱动器上，其中索引存储在极度超载的SAS驱动器上，从而导致磁盘饱和和恒定的磁盘队列。当RDBMS生成执行计划时，是否比索引操作更可能支持表扫描（或者可能是瘦索引和关联的表查找，而不是覆盖索引，因为它在SAS磁盘上的IO更少）？

我怀疑答案是肯定的，“优化器不会聪明甚至不会意识到磁盘性能”，但是我只是想看看那里是否有人肯定知道。我正在使用SQL Server，但对任何数据库系统都感兴趣。

编译查询计划时，SQL Server的查询优化器没有考虑磁盘性能的变化。Paul White在这里提供了Sql Server基于成本的优化器的概述：

https://sqlkiwi.blogspot.com/2010/09/inside-the-optimizer-plan-costing.html

一些关键点是：

• 优化器没有尝试计算计划的确切成本。它正在尝试在几种替代方案之间以相对最低的成本来选择计划。

• 这是现实的简化视图。假设服务器可以执行320 io / sec的速度，并且十年来CPU性能没有增加。

• 尽管当今的服务器具有截然不同的性能特征，但优化器在大多数情况下仍能发挥出色的作用。

那么，Microsoft为什么不向优化器添加一些其他智能呢？但是，将来它们可能会更细微地调整单个迭代器的成本。当前，尚无好处来证明这一努力。

您可以使用未记录的dbcc调用来更改某些查询优化器假设。不要在生产服务器上使用这些

DBCC SETIOWEIGHT(<multiplier>)
DBCC SETCPUWEIGHT(<multiplier>)

两者的默认值均为1。试一试，看看能否在大多数情况下提供能够始终如一地制定更好计划的不同值。您会发现，小的更改不会更改大多数计划，而大的更改会生成真正奇怪的计划。

还有一点是，尽管SQL在编译计划时不考虑io性能，但它确实在计划执行期间响应io性能（如果io饱和则限制预读操作，等等）。

用于LUW查询优化器的Db2知道运行它的计算机的硬件性能特征，并将其考虑在内。

具体来说，每个表空间都有两个数字参数，它们反映了基础的存储性能：overhead，它反映I / O控制器开销以及磁盘查找和等待时间（以毫秒为单位）；以及transferrate，它指示从磁盘到内存转移一个表空间页面所需的时间。

可以在表空间创建时指定这些参数，以覆盖启发式派生的默认值。

优化器使用I / O性能参数以及cpu_speed数据库管理器级参数来计算每个查询计划操作员的I / O和CPU成本，因此将影响最终选择哪个计划。随后，您的方案在Db2中将完全合理。同样，在CPU速度非常快且磁盘性能一般的系统上，优化器可能更喜欢CPU密集型操作员（例如，表扫描加排序），而不是I / O密集型操作员（例如，基于索引的表访问）。

我相信Db2 for z / OS同样考虑了底层硬件性能特征，它们是从存储管理层中获得的，而不是作为数据库配置的一部分。