查詢保持不變，即保持不變。SQL查詢的「受影響的行數」和「執行時間」之間的數學關係是什麼？
例如如果返回10000行，則選擇查詢需要30分鐘。
如果必須返回20000行，相同的查詢需要1小時嗎？
我很想知道之間的數學關係。 （N）和執行時間（T）保持其他參數恆定（K）。
即T = N * K或
T = N * K + C或
任何其他公式？
閱讀http://research.microsoft.com/pubs/76556/progress.pdf如果有幫助。任何人都可以在我之前理解這一點，請回復。謝謝...
那麼這是一個很好的問題:)，但沒有確切的公式，因爲它取決於執行計劃。
SQL查詢優化器可以在返回不同行數的查詢中選擇另一個執行計劃。 我猜如果查詢執行計劃對於兩個查詢都是相同的，並且您有一些「實驗室」條件，那麼時間增長可能是線性的。您應該更多地研究sql執行計劃和統計信息
不僅如此，查詢計劃具有不同的增長特徵。例如，對已排序數據的合併連接在輸入大小上將是線性的，但嵌套循環將是二次的。另外，需要考慮緩存效果。與從內存讀取相比，從磁盤讀取速度較慢。 – Laurence 2014-09-13 12:08:15
@Laurence：你能發表一個關於你說的話的鏈接或者一點詳細的解釋嗎？對於沒有連接的選擇/插入/更新（T = N * K或T = N * K + C），它是嚴格線性的嗎？我正在考慮爲我們正在運行的一些SSIS工作提供一個估計執行時間的通用公式。例如如果我估計一份工作要運行5個小時，那麼應該可以，如果它在4或6個小時內完成。但是，如果需要超過6小時或少於3小時，那麼配方失敗。 – 2014-09-13 12:27:25
若要從單個表中選擇沒有where，group by或order，則最差情況將爲線性，並基於存儲的隨機查找時間。但是，如果您擁有聚簇索引，則更可能基於存儲的流式吞吐量。 – Laurence 2014-09-13 12:37:19
以讀取單個表中每一行的非常簡單的示例。
在最糟糕的情況下，您必須從底層存儲中讀取表格的每一頁。最糟糕的情況是不得不隨機尋找。尋找時間將主導所有其他因素。所以你可以估計總時間。
time ~= seek time x number of data pages
假設您的行具有相當規則的大小，那麼這在行數上是線性的。
但是數據庫會做很多事情來避免這種最壞的情況。例如，在SQL Server表中，存儲通常以8個連續頁面的範圍進行分配。硬盤驅動器的流IO速率比隨機IO速率快得多。如果您有聚簇索引，按羣集順序讀取頁面往往會比隨機IO擁有更多流式IO。
最好的情況時，忽略存儲器緩存，是（8KB是SQL Server的頁面大小）
time ~= 8KB * number of data pages/streaming IO rate in KB/s
這也在行數成線性關係。
只要你做一個合理的工作管理碎片，你可以在這種簡單的情況下線性地合理地外推。這假設你的數據比緩衝區緩存大得多。如果不是，那麼您也必須擔心查詢從讀取緩衝區到從磁盤讀取發生變化的懸崖邊緣。
我也忽略了像並行存儲路徑和訪問的細節。
機器上的負載也將起作用。您從本地測試中獲得的數字可能與您在生產中執行相同查詢時發生的情況不一致。 – duffymo 2014-09-13 13:07:16
這基本上只是一個生產問題。我正在考慮登錄號。的記錄和實際執行時間爲ssis工作的各種運行，以便我們可以估計時間基於no。的記錄。我認爲我的公式T = N * K + C應該適用於K和C的平均值。 – 2014-09-13 13:24:47