数据库查询优化器是否知道存储性能差异？

Question

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

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

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

Answer 1

Sql server 的查询优化器在编译查询计划时不会考虑磁盘性能的变化。Paul White 在这里提供了 Sql Server 基于成本的优化器的一个很好的概述：

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

一些关键点是：

• 优化器并不试图计算计划的确切成本。它试图在几个备选方案中选择成本相对最低的计划。

• 这是对现实的简化视图。它假设服务器可以执行 320 io/sec 并且 cpu 性能在十多年来没有增加。

• 尽管今天的服务器具有截然不同的性能特征，但优化器在大多数情况下仍然做得非常好。

那么，为什么微软不为优化器添加一些额外的智能呢？然而，在未来，它们更有可能是对单个迭代器的成本进行小幅调整。目前没有好处来证明努力的合理性。

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

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

两者的默认值都是 1。尝试使用它们，看看您是否可以提出在大多数情况下始终生成更好计划的不同值。你会发现小的改变不会改变大部分计划，大的改变会产生非常奇怪的计划。

另外一点是，虽然 SQL 在编译计划时不考虑 io 性能，但它确实在计划执行期间响应 io 性能（如果 io 饱和，则限制预读读取等）