数据库在客户端-服务器时代具有非常显著的地位，但现今其中心地位已有所淡化。它们仅构成三个重要架构层的其中之一，不仅已高度商品化，而且很少并入内置业务逻辑。然而，数据库仍对应用程序的性能起着至关重要的作用，其中有两大主要原因：

     *   只有数据库需要用来执行大量的物理磁盘 I/O，而现今的磁盘 I/O（相对于磁盘大小和 CPU 速度）比过 去更为关键。

     *   在多层应用程序中，中间件层可方便地通过群集和负载平衡来扩展（但数据库却非常难于组建群集；对于大多数应用程序而言，扩展数据库服务器的难度要远大于扩展应用程序或 Web 服务器）

I/O 因素

在应用程序堆栈的所有层中，只有数据库层需要用来执行大量的物理 I/O，而众所周知 I/O 是所有操作中最缓慢的。尽管摩尔定律使  CPU  和内存访问速度呈指数级增长，但  I/O  设备的速度却只呈线性增长。也就是说，在  CPU  速度提升了 30 倍的这段时期里，磁盘 I/O  的速度仅提升了 4 倍。除此之外，磁盘存储容量也比 I/O 速度增长要快，这意味着对于任意给定容量的磁盘存储而言，I/O 能力实际上是下降了。

 查看大图

图 1. 虽然磁盘 I/O 速率提高了，但相对于 CPU 和磁盘存储容量却下降了。

由于 SQL 语句负责应用程序产生的几乎所有 I/O，因此调整 SQL 便成了避免应用程序 I/O 受限的关键。 

非 I/O 性能问题

但很矛盾的是，调整不佳的 SQL  通常会使 CPU  受限而不是 I/O  受限。这是因为 RDBMS  系统采用了先进的高速缓存机制来避免发生不必要的物理 I/O。

某些次优的  SQL  语句会在执行期间反复访问数据。例如，臭名昭著的“嵌套表扫描”在读取外部表每一行的同时读取内部表的每一行。这些行基本上会缓存在内存中，因此当  SQL 在 I/O  方面显得非常高效时，由于会反复读取内存的相同块，因而将过度消耗 CPU。