“不”之间的数学关系是什么？ SQL查询的“受影响的行数”和“执行时间”？

Question

The query remains constant ie it will remain the same.

eg a select query takes 30 minutes if it returns 10000 rows.

Would the same query take 1 hour if it has to return 20000 rows?

I am interested in knowing the mathematical relation between no. of rows(N) and execution time(T) keeping other parameters as constant(K).

ie T= N*K or

T=N*K + C or

any other formula?

Reading http://research.microsoft.com/pubs/76556/progress.pdf if it helps. Anybody who can understand this before me, please do reply. Thanks...

Answer 1

Well that is good question :), but there is not exact formula, because it depends of execution plan.

SQL query optimizer could choose another execution plan on query which return different number of rows. I guess if the query execution plan is the same for both query's and you have some "lab" conditions then time growth could be linear. You should research more on sql execution plans and statistics

Answer 2

Take the very simple example of reading every row in a single table.

In the worst case, you will have to read every page of the table from your underlying storage. The worst case for this is having to do a random seek. The seek time will dominate all other factors. So you can estimate the total time.

time ~= seek time x number of data pages

Assuming your rows are of a fairly regular size, then this is linear in the number of rows.

However databases do a number of things to try and avoid this worst case. For example, in SQL Server table storage is often allocated in extents of 8 consecutive pages. A hard drive has a much faster streaming IO rate than random IO rate. If you have a clustered index, reading the pages in cluster order tend to have a lot more streaming IO than random IO.

The best case time, ignoring memory caching, is (8KB is the SQL Server page size)

time ~= 8KB * number of data pages / streaming IO rate in KB/s

This is also linear in the number of rows.

As long as you do a reasonable job managing fragmentation, you could reasonably extrapolate linearly in this simple case. This assumes your data is much larger than the buffer cache. If not, you also have to worry about the cliff edge where your query changes from reading from buffer to reading from disk.

I'm also ignoring details like parallel storage paths and access.