在SQL语句中使用LIMIT时,性能提高了多少？

Question

假设我的数据库中有一个包含1.000.000记录的表.

如果我执行:

SELECT * FROM [Table] LIMIT 1000

这个查询会花费同样的时间,好像我有那个包含1000记录的表,只是这样做:

SELECT * FROM [Table]

？

我不是在寻找是否需要完全相同的时间.我只是想知道第一个是否比第二个花费更多的时间来执行.

我说1.000.000记录,但它可能20.000.000.那只是一个例子.

编辑:
当然,当使用LIMIT并且不在同一个表中使用它时,使用LIMIT构建的查询应该更快地执行,但我不是要求...

使其通用:

Table1:X记录
Table2:Y记录

(X << Y)

我想要比较的是:

SELECT * FROM Table1

和

SELECT * FROM Table2 LIMIT X

编辑2:
这就是我问这个问题的原因:

我有一个数据库,有5个表和一些表之间的关系.其中一个表(我100%肯定)包含大约5.000.000记录.我使用SQL Server CE 3.5,Entity Framework作为ORM和LINQ to SQL来进行查询.

我需要基本上执行三种非简单查询,而我正在考虑向用户显示记录限制(就像很多网站一样).如果用户想要查看更多记录,则他/她具有的选项是限制更多搜索.

所以,问题出现了,因为我正在考虑这样做(限制X每个查询的记录)或者如果只在数据库中存储X结果(最近的那些),这将需要在数据库中做一些删除,但我只是在想...

因此,该表可能包含5.000.000更多记录,而我不想要的是显示用户1000左右,即使是这样,查询仍然会像返回5.000.000行一样慢.

Answer 1

TAKE 1000从1000000条记录的表中读取-将= 1000快1000000/1000（）倍，因为它只需要查看（并返回）1000/1000000条记录。由于它做得更少，因此自然更快。

结果是很漂亮的（伪随机），因为您没有指定任何执行顺序。但是，如果您确实引入了一个订单，则以下两个条件之一将成立：

ORDER BY子句位于索引之后-上面的语句仍然为真。
ORDER BY子句不能使用任何索引-仅比没有TAKE快一点，因为
- 它必须检查所有记录，并按 ORDER BY
- 仅提供一个子集（“获取”计数）
- 因此第一步并不快，但是第二步比所有记录涉及更少的IO /网络

如果您从1000条记录的表中获取1000条记录，则只要遵循（1）无顺序或（2）进行，它就等于从10亿条记录中获取1000条记录。按索引排序

Answer 2

假设两个表在索引、行大小和其他结构方面是等效的。还假设您正在运行该简单的 SELECT 语句。如果ORDER BY你的 SQL 语句中有一个子句，那么显然较大的表会更慢。我想你不是在问这个。

如果 X = Y，那么显然它们应该以相似的速度运行，因为对于这个简单的 SELECT 语句，查询引擎将以完全相同的顺序遍历记录（基本上是表扫描）。查询计划不会有任何差异。

如果 Y > X 仅一点点，则速度也相似。

但是，如果 Y >> X（意味着 Y 的行数比 X 多很多），则 LIMIT 版本可能会更慢。不是因为查询计划——同样应该是相同的——而只是因为数据布局的内部结构可能有更多的层次。例如，如果数据存储为树上的叶子，则可能有更多的树级别，因此访问相同数量的页面可能需要稍多的时间。

换句话说，1000 行可以存储在 10 个页面的 1 个树级别中。1000000 行可以存储在 10000 个页面的 3-4 个树级别中。即使从这 10000 个页面中只取出 10 个页面，存储引擎仍然需要经过 3-4 个树级别，这可能需要稍长的时间。

现在，如果存储引擎按顺序或以链表的形式存储数据页，那么执行速度不会有任何差异。