前些天看了一个老外写的程序,在 MySQL 查询中使用了很多 Limit 关键字,这就让我很感兴趣了,因为在我印象中, Limit 关键字似乎更多被使用 MySQL 数据库的程序员用来做查询分页(当然这也是一种很好的查询优化),那在这里举个例子,假设我们需要一个分页的查询 ,Oracle中一般来说都是用以下 SQL 句子实现:
SELECT * FROM
( SELECT a1.*, rownum rownum_
FROM testtable a1
WHERE rownum > 20)
WHERE rownum_ <= 1000
这个语句就能查询到 testtable 表中的 20 到 1000 记录,而且还需要嵌套查询,效率不会太高,看看 MySQL 的实现:
SELECT * FROM testtable a1 limit 20,980;
这样就能返回 testtable 表中的 21 条到( 20 + 980 =) 1000 条的记录。
实现语法确实简单,但如果要说这里两个 SQL 语句的效率,那就很难做比较了,因为在 MySQL 中 Limit 选项有多种不同的解释方式,不同方式下的速度差异是很大的,因此我们不能从这语句的简洁程度就说谁的效率高。
不过对程序员来说,够简单就好,因为维护成本低,呵呵。
下面讲讲这个 Limit 的语法吧:
SELECT ……. --Select 语句的其他参数
[LIMIT {[offset,] row_count | row_count OFFSET offset}]
这里 offset 是偏移量(这个偏移量的起始地址是 0 ,而不是 1 ,这点很容易搞错的)顾名思义就是离开起始点的位置,而 row-count 也是很简单的,就是返回的记录的数量限制。
Eg. SELECT * FROM testtable a limit 10,20 where ….
这样就能使结果返回 10 行以后(包括 10 行自身)的符合 where 条件的 20 条记录。
那么如果没有约束条件就返回 10 到 29 行的记录。
那这跟避免全表扫描有什么关系呢? 下面是 MySQL 手册对 Limit 参数优化扫描的一些说明:
在一些情况中,当你使用 LIMIT 选项而不是使用 HAVING 时, MySQL 将以不同方式处理查询。
l 如果你用 LIMIT 只选择其中一部分行,当 MySQL 一般会做完整的表扫描时,但在某些情况下会使用索引(跟 ipart 有关)。
l 如果你将 LIMIT n 与 ORDER BY 同时使用,在 MySQL 找到了第一个符合条件的记录后,将结束排序而不是排序整个表。
l 当 LIMIT n 和 DISTINCT 同时使用时, MySQL 在找到一个记录后将停止查询。
l 某些情况下, GROUP BY 能通过顺序读取键 ( 或在键上做排序 ) 来解决,并然后计算摘要直到键值改变。在这种情况下, LIMIT n 将不计算任何不必要的 GROUP 。
l 当 MySQL 完成发送第 n 行到客户端,它将放弃余下的查询。
l 而 LIMIT 0 选项总是快速返回一个空记录。这对检查查询并且得到结果列的列类型是有用的。
l 临时表的大小使用 LIMIT # 计算需要多少空间来解决查询。
免责声明:本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除!
更新日志
- 凤飞飞《我们的主题曲》飞跃制作[正版原抓WAV+CUE]
- 刘嘉亮《亮情歌2》[WAV+CUE][1G]
- 红馆40·谭咏麟《歌者恋歌浓情30年演唱会》3CD[低速原抓WAV+CUE][1.8G]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[320K/MP3][193.25MB]
- 【轻音乐】曼托凡尼乐团《精选辑》2CD.1998[FLAC+CUE整轨]
- 邝美云《心中有爱》1989年香港DMIJP版1MTO东芝首版[WAV+CUE]
- 群星《情叹-发烧女声DSD》天籁女声发烧碟[WAV+CUE]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[FLAC/分轨][748.03MB]
- 理想混蛋《Origin Sessions》[320K/MP3][37.47MB]
- 公馆青少年《我其实一点都不酷》[320K/MP3][78.78MB]
- 群星《情叹-发烧男声DSD》最值得珍藏的完美男声[WAV+CUE]
- 群星《国韵飘香·贵妃醉酒HQCD黑胶王》2CD[WAV]
- 卫兰《DAUGHTER》【低速原抓WAV+CUE】
- 公馆青少年《我其实一点都不酷》[FLAC/分轨][398.22MB]
- ZWEI《迟暮的花 (Explicit)》[320K/MP3][57.16MB]