查詢的速度是否取決於表中的行數？

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

幾乎總是肯定的。 真正的問題是：隨着表格大小的增加，查詢速度會降低多少？ 答案是：如果rx被索引，則不是很多，如果不是，則大量的。

Answer 4

不是行（在某種程度上當然）本身，但數據量（列）是可以使查詢變慢的原因。 數據也需要從后端傳輸到前端。

Answer 5

答案是肯定的。 但不是唯一的因素。 如果您進行了適當的優化並且調整性能下降將是可忽略不計的主要性能因素

• 索引聚簇或無聚簇
• 數據緩存
• 表分區
• 執行計划緩存
• 數據分布
• 硬件規格

還有一些其他因素，但主要考慮這些因素。 甚至你如何設計Schema也會影響性能。

Answer 6

您應該假設您的查詢總是取決於行數。 實際上，您應該假設最壞的情況（您提供的示例的線性或O(N) ）和更復雜查詢的指數。 有一些數據庫特定的手冊充滿了技巧，以幫助您避免最壞的情況，但SQL本身是一種語言，並沒有指定如何執行您的查詢。 相反，數據庫實現決定如何執行任何給定的查詢：如果您已在數據庫中索引了一列或一組列，那么您將獲得簡單查找的O(log(N))性能; 如果系統具有有效的查詢緩存，則可能會得到O(1)響應。 這是一篇很好的介紹性文章： 高可伸縮性：SQL和計算復雜性