据我了解，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 调用来更改某些查询优化器假设。不要在生产服务器上使用这些
两者的默认值均为 1。尝试使用它们，看看您是否可以提出不同的值，从而在大多数情况下始终产生更好的计划。你会发现小的改变不会改变大部分的计划，而大的改变会产生非常奇怪的计划。
另外一点是，虽然SQL在编译计划时不考虑io性能，但它确实在计划执行期间响应io性能（如果io饱和则限制预读等）
Db2 for LUW 查询优化器了解它所运行的机器的硬件性能特征并将它们考虑在内。
具体来说，每个表空间都有两个反映底层存储性能的数值参数：
overhead，它反映了 I/O 控制器开销和磁盘寻道以及以毫秒为单位的延迟时间，以及transferrate，它表示将一个表空间页面从磁盘传输到内存所需的时间。这些参数可以在表空间创建时指定，以覆盖启发式派生的默认值。
I/O 性能参数以及
cpu_speed数据库管理器级参数被优化器用来计算每个查询计划运算符的 I/O 和 CPU 成本，因此将影响最终选择哪个计划。随后，您的场景在 Db2 中将完全合理。同样，在 CPU 速度非常高而磁盘性能一般的系统上，优化器可能更喜欢 CPU 密集型操作符（例如表扫描加排序）而不是 I/O 密集型操作符（例如基于索引的表访问）。我相信 Db2 for z/OS 同样考虑了底层硬件性能特征，从存储管理层获取它们，而不是作为数据库配置的一部分。