理论上的 SQL Server 2008 问题：
如果在具有大量“可用”内存的 SQL Server 上执行表扫描，那么该表扫描的结果是否会保存在内存中，从而抵消表上索引可能带来的效率？
更新 1：有问题的表格包含大约的参考数据。每个表 100 - 200 条记录（我不知道每行的平均大小），所以我们这里不讨论海量表。
我已经与客户讨论过为此参考数据引入 memcached / AppFabric 缓存解决方案，但是目前这超出了范围，他们正在寻找风险最小的“快速获胜”。
问问题
754 次
3 回答
6
扫描中读取的每个页面都将被读入缓冲池，并且仅根据缓存驱逐策略在内存压力下释放。
不知道为什么您认为这会否定表上索引可能带来的效率。
索引可能意味着需要读取的页面更少，即使所有页面都已经在缓存中，所以不需要物理读取，减少逻辑读取的数量是一件好事。逻辑读取不是免费的。他们仍然有锁定和读取页面的开销。
于 2012-09-21T09:43:42.903 回答
3
Besides the performance problem (even when all pages are in memory a scan is still going to be many many times slower than an index seek on any table of significant size) there is an additional issue: contention.
The problem with scans is that any operation will have to visit every row. This means that any select will block behind any insert/update/delete (since is guaranteed to visit the row locked by these operations). The effect is basically serialization of operations and adds huge latency, as SELECT now have to wait for DML to commit every time. Even under mild concurrency the effect is an overall sluggish and slow to respond table. With indexes present operations are only looking at rows in the ranges of interest and this, by virtue of simple probabilities, reduces the chances of conflict. The result is a much livelier, responsive, low latency system.
于 2012-09-21T10:14:51.247 回答
1
随着数据的增长，全表扫描也无法扩展。这很简单。随着更多数据添加到表中，全表扫描必须处理更多数据才能完成，因此它们将花费更长的时间。此外，它们会产生更多的磁盘和内存请求，进一步给您的设备带来压力。考虑一个执行全表扫描的 1,000,000 行表。SQL Server 以 8K 数据页的形式读取数据。尽管每个页面中存储的数据量可能会有所不同，但我们假设在我们的示例中，每个 8K 页面中平均有 50 行数据。为了对数据执行全扫描以读取每一行，20,000 次磁盘读取（1,000,000 行/每页 50 行）。这相当于必须处理 156MB 的数据，仅针对这一查询。除非你有一个非常快的磁盘子系统，检索所有数据并进行处理可能需要一段时间。现在，假设这张表的大小每年翻一番。明年，同样的查询必须读取 312MB 的数据才能完成。
于 2012-09-21T09:57:06.050 回答