查询的速度是否取决于表中的行数？

Question

假设我有这个问题：

select * from table1 r where r.x = 5

此查询的速度是否取决于table1？

中存在的行数

Answer 1

查询速度有很多因素，其中一个因素可以是行数。

其他包括：

• 索引策略（如果您将列“x”编入索引，您会看到比未编入索引更好的性能）
• 服务器负载
• 数据缓存 - 一旦执行了查询，数据就会被添加到数据缓存中。因此，后续重新运行将更快，因为数据来自内存，而不是磁盘。直到从缓存中删除数据的那一点
• 执行计划缓存 - 在较小程度上。一旦第一次执行查询，SQL Server提出的执行计划将被缓存一段时间，以便将来执行重用。
• 服务器硬件
• 您编写查询的方式（通常是表现不佳的最大连词之一！）。例如用光标而不是基于集合的操作写一些东西

对于表中包含大量行的数据库，通常需要考虑分区（从SQL Server 2005开始，Enterprise Edition有内置支持）。这是将数据拆分为更小的单位。通常，较小的单位=较小的表=较小的索引=较好的表现。

Answer 2

是的，这可能非常重要。

如果有1亿行，SQL服务器必须遍历每个行并查看它是否匹配。 与10行相比，这需要更多的时间。

你可能想要'x'列上的索引，在这种情况下，sql server可能会检查索引而不是遍历所有行 - 这可能会明显更快，因为sql server可能甚至不需要检查所有索引中的值。

另一方面，如果有1亿行匹配x = 5，则它比10行慢。

Answer 3

几乎总是如此。真正的问题是：随着表格大小的增加，查询速度会降低多少？答案是：如果r.x被索引，则不是很多，如果没有，则为很多。

Answer 4

不是行（在某种程度上当然）本身，但数据量（列）可以使查询变慢。数据也需要从后端传输到前端。

Answer 5

答案是肯定的。但不是唯一的因素。 如果你做了适当的优化并且调整性能下降将是微不足道的 主要表现因素

• 索引群集或无群集
• 数据缓存
• 表格分区
• 执行计划缓存
• 数据分发
• 硬件规格

还有一些其他因素，但主要考虑这些因素。 甚至你如何设计Schema也会影响性能。

Answer 6

您应该假设您的查询总是取决于行数。实际上，您应该假设最坏的情况（对于您提供的示例为线性或O(N)）和更复杂查询的指数。有一些数据库特定的手册充满了技巧，以帮助您避免最坏的情况，但SQL本身是一种语言，并没有指定如何执行您的查询。相反，数据库实现决定如何执行任何给定的查询：如果您已在数据库中索引了一列或一组列，那么您将获得O(log(N))性能以进行简单查找;如果系统具有有效的查询缓存，则可能会收到O(1)响应。这是一篇很好的介绍性文章：High scalability: SQL and computational complexity