SQL Limit 用法_MySQL
Limit 中第一个参数为offset。
在MySQL 中limit是按顺序取数据的，所以要随机取数据时，使用 order by random();
Netezza: 使用random() 函数
select setseed(random());
select * from table order by random() limit 100;
Mysql 使用Rand() 函数。
----------------------------------------------------------------------------
//为了检索从某一个偏移量到记录集的结束所有的记录行，可以指定第二个参数为
mysql> //如果只给定一个参数，它表示返回最大的记录行数目： mysql> //换句话说，LIMIT select * from table LIMIT 5; #返回前5行
select * from table LIMIT 0,5; #返回前5行
1、offset比较小的时候。
select * from yanxue8_visit limit 10,10
多次运行，时间保持在0.0004-0.0005之间
Select * From yanxue8_visit Where vid >=(
Select vid From yanxue8_visit Order By vid limit 10,1
) limit 10
多次运行，时间保持在0.0005-0.0006之间，主要是0.0006
结论：偏移offset较小的时候，直接使用limit较优。这个显然是子查询的原因。
2、offset大的时候。
select * from yanxue8_visit limit 10000,10
多次运行，时间保持在0.0187左右
Select * From yanxue8_visit Where vid >=(
Select vid From yanxue8_visit Order By vid limit 10000,1
) limit 10
多次运行，时间保持在0.0061左右，只有前者的1/3。可以预计offset越大，后者越优。
性能优化：
1.
Select * From cyclopedia Where ID>=(
Select Max(ID) From (
) As tmp
) limit 100;
2.
Select * From cyclopedia Where ID>=(
Select Max(ID) From (
) As tmp
) limit 100;
同样是取90000条后100条记录,第1句快还是第2句快?
第1句是先取了前90001条记录,取其中最大一个ID值作为起始标识,然后利用它可以快速定位下100条记录
第2句择是仅仅取90000条记录后1条,然后取ID值作起始标识定位下100条记录
第1句执行结果.100 rows in set (0.23) sec
第2句执行结果.100 rows in set (0.19) sec
很明显第2句胜出.看来limit好像并不完全像我之前想象的那样做全表扫描返回limit offset+length条记录,这样看来limit比起MS-SQL的Top性能还是要提高不少的.
其实第2句完全可以简化成
Select * From cyclopedia Where ID>=(
Select ID From cyclopedia limit 90000,1
)limit 100;
直接利用第90000条记录的ID,不用经过Max运算,这样做理论上效率因该高一些,但在实际使用中几乎看不到效果,因为本身定位ID返回的就是1条记录,Max几乎不用运作就能得到结果,但这样写更清淅明朗,省去了画蛇那一足.
可是,既然MySQL有limit可以直接控制取出记录的位置,为什么不干脆用Select * From cyclopedia limit 90000,1呢?岂不更简洁?
这 样想就错了,试了就知道,结果是:1 row in set (8.88) sec,怎么样,够吓人的吧,让我想起了昨天在4.1中比这还有过之的"高分".Select * 最好不要随便用,要本着用什么,选什么的原则, Select的字段越多,字段数据量越大,速度就越慢. 上面2种分页方式哪种都比单写这1句强多了,虽然看起来好像查询的次数更多一些,但实际上是以较小的代价换取了高效的性能,是非常值得的.
第1种方案同样可用于MS-SQL,而且可能是最好的.因为靠主键ID来定位起始段总是最快的.
Select Top 100 * From cyclopedia Where ID>=(
Select Top 90001 Max(ID) From (
) As tmp
)
但不管是实现方式是存贮过程还是直接代码中,瓶颈始终在于MS-SQL的TOP总是要返回前N个记录,这种情况在数据量不大时感受不深,但如果成百上千万,效率肯定会低下的.相比之下MySQL的limit就有优势的多,执行:
Select ID From cyclopedia limit 90000
Select ID From cyclopedia limit 90000,1
的结果分别是:
90000 rows in set (0.36) sec
1 row in set (0.06) sec
而MS-SQL只能用Select Top 90000 ID From cyclopedia 执行时间是390ms,执行同样的操作时间也不及MySQL的360ms.----------------------------------------------------------LIMIT 思考
***************** 1. row **************
id: 1
select_type: SIMPLE
table: message
type: index
possible_keys: NULL
key: PRIMARY
key_len: 4
ref: NULL
rows: 10020
Extra:
1 row in set (0.00 sec)limit 10000,20的意思扫描满足条件的10020行，扔掉前面的10000行，返回最后的20行，问题就在这里，如果是limit 100000,100，需要扫描100100行，在一个高并发的应用里，每次查询需要扫描超过10W行，性能肯定大打折扣。文中还提到limit n性能是没问题的，因为只扫描n行。文中提到一种”clue”的做法，给翻页提供一些”线索”，比如还是SELECT * FROM message ORDER BY id DESC，按id降序分页，每页20条，当前是第10页，当前页条目id最大的是9527，最小的是9500，如果我们只提供”上一页”、”下一页”这样 的跳转（不提供到第N页的跳转），那么在处理”上一页”的时候SQL语句可以是：SELECT * FROM message WHERE id > 9527 ORDER BY id ASC LIMIT 20;处理”下一页”的时候SQL语句可以是：SELECT * FROM message WHERE id ”这样的链接方式，怎么办呢？如果LIMIT m,n不可避免的话，要优化效率，只有尽可能的让m小一下，我们扩展前面的”clue”做法，还是SELECT * FROM message ORDER BY id DESC，按id降序分页，每页20条，当前是第10页，当前页条目id最大的是9527，最小的是9500，比如要跳到第8页，我看的SQL语句可以这 样写：SELECT * FROM message WHERE id > 9527 ORDER BY id ASC LIMIT 20,20;跳转到第13页：SELECT * FROM message WHERE id SELECT
//为了检索从某一个偏移量到记录集的结束所有的记录行，可以指定第二个参数为
mysql> //如果只给定一个参数，它表示返回最大的记录行数目： mysql> //换句话说，LIMIT select * from table LIMIT 5; #返回前5行
select * from table LIMIT 0,5; #返回前5行
1、offset比较小的时候。
select * from yanxue8_visit limit 10,10
多次运行，时间保持在0.0004-0.0005之间
Select * From yanxue8_visit Where vid >=(
Select vid From yanxue8_visit Order By vid limit 10,1
) limit 10
多次运行，时间保持在0.0005-0.0006之间，主要是0.0006
结论：偏移offset较小的时候，直接使用limit较优。这个显然是子查询的原因。
2、offset大的时候。
select * from yanxue8_visit limit 10000,10
多次运行，时间保持在0.0187左右
Select * From yanxue8_visit Where vid >=(
Select vid From yanxue8_visit Order By vid limit 10000,1
) limit 10
多次运行，时间保持在0.0061左右，只有前者的1/3。可以预计offset越大，后者越优。
性能优化：
1.
Select * From cyclopedia Where ID>=(
Select Max(ID) From (
) As tmp
) limit 100;
2.
Select * From cyclopedia Where ID>=(
Select Max(ID) From (
) As tmp
) limit 100;
同样是取90000条后100条记录,第1句快还是第2句快?
第1句是先取了前90001条记录,取其中最大一个ID值作为起始标识,然后利用它可以快速定位下100条记录
第2句择是仅仅取90000条记录后1条,然后取ID值作起始标识定位下100条记录
第1句执行结果.100 rows in set (0.23) sec
第2句执行结果.100 rows in set (0.19) sec
很明显第2句胜出.看来limit好像并不完全像我之前想象的那样做全表扫描返回limit offset+length条记录,这样看来limit比起MS-SQL的Top性能还是要提高不少的.
其实第2句完全可以简化成
Select * From cyclopedia Where ID>=(
Select ID From cyclopedia limit 90000,1
)limit 100;
直接利用第90000条记录的ID,不用经过Max运算,这样做理论上效率因该高一些,但在实际使用中几乎看不到效果,因为本身定位ID返回的就是1条记录,Max几乎不用运作就能得到结果,但这样写更清淅明朗,省去了画蛇那一足.
可是,既然MySQL有limit可以直接控制取出记录的位置,为什么不干脆用Select * From cyclopedia limit 90000,1呢?岂不更简洁?
这 样想就错了,试了就知道,结果是:1 row in set (8.88) sec,怎么样,够吓人的吧,让我想起了昨天在4.1中比这还有过之的"高分".Select * 最好不要随便用,要本着用什么,选什么的原则, Select的字段越多,字段数据量越大,速度就越慢. 上面2种分页方式哪种都比单写这1句强多了,虽然看起来好像查询的次数更多一些,但实际上是以较小的代价换取了高效的性能,是非常值得的.
第1种方案同样可用于MS-SQL,而且可能是最好的.因为靠主键ID来定位起始段总是最快的.
Select Top 100 * From cyclopedia Where ID>=(
Select Top 90001 Max(ID) From (
) As tmp
)
但不管是实现方式是存贮过程还是直接代码中,瓶颈始终在于MS-SQL的TOP总是要返回前N个记录,这种情况在数据量不大时感受不深,但如果成百上千万,效率肯定会低下的.相比之下MySQL的limit就有优势的多,执行:
Select ID From cyclopedia limit 90000
Select ID From cyclopedia limit 90000,1
的结果分别是:
90000 rows in set (0.36) sec
1 row in set (0.06) sec
而MS-SQL只能用Select Top 90000 ID From cyclopedia 执行时间是390ms,执行同样的操作时间也不及MySQL的360ms.----------------------------------------------------------LIMIT 思考
***************** 1. row **************
id: 1
select_type: SIMPLE
table: message
type: index
possible_keys: NULL
key: PRIMARY
key_len: 4
ref: NULL
rows: 10020
Extra:
1 row in set (0.00 sec)limit 10000,20的意思扫描满足条件的10020行，扔掉前面的10000行，返回最后的20行，问题就在这里，如果是limit 100000,100，需要扫描100100行，在一个高并发的应用里，每次查询需要扫描超过10W行，性能肯定大打折扣。文中还提到limit n性能是没问题的，因为只扫描n行。文中提到一种”clue”的做法，给翻页提供一些”线索”，比如还是SELECT * FROM message ORDER BY id DESC，按id降序分页，每页20条，当前是第10页，当前页条目id最大的是9527，最小的是9500，如果我们只提供”上一页”、”下一页”这样 的跳转（不提供到第N页的跳转），那么在处理”上一页”的时候SQL语句可以是：SELECT * FROM message WHERE id > 9527 ORDER BY id ASC LIMIT 20;处理”下一页”的时候SQL语句可以是：SELECT * FROM message WHERE id ”这样的链接方式，怎么办呢？如果LIMIT m,n不可避免的话，要优化效率，只有尽可能的让m小一下，我们扩展前面的”clue”做法，还是SELECT * FROM message ORDER BY id DESC，按id降序分页，每页20条，当前是第10页，当前页条目id最大的是9527，最小的是9500，比如要跳到第8页，我看的SQL语句可以这 样写：SELECT * FROM message WHERE id > 9527 ORDER BY id ASC LIMIT 20,20;跳转到第13页：SELECT * FROM message WHERE id
热AI工具
Undresser.AI Undress
人工智能驱动的应用程序，用于创建逼真的裸体照片
AI Clothes Remover
用于从照片中去除衣服的在线人工智能工具。
Undress AI Tool
免费脱衣服图片
Clothoff.io
AI脱衣机
Video Face Swap
使用我们完全免费的人工智能换脸工具轻松在任何视频中换脸！
热门文章
热工具
记事本++7.3.1
好用且免费的代码编辑器
SublimeText3汉化版
中文版，非常好用
禅工作室 13.0.1
功能强大的PHP集成开发环境
Dreamweaver CS6
视觉化网页开发工具
SublimeText3 Mac版
神级代码编辑软件(SublimeText3)
热门话题
与MySQL中使用索引相比，全表扫描何时可以更快？
Apr 09, 2025 am 12:05 AM
全表扫描在MySQL中可能比使用索引更快，具体情况包括：1)数据量较小时；2)查询返回大量数据时；3)索引列不具备高选择性时；4)复杂查询时。通过分析查询计划、优化索引、避免过度索引和定期维护表，可以在实际应用中做出最优选择。
说明InnoDB全文搜索功能。
Apr 02, 2025 pm 06:09 PM
InnoDB的全文搜索功能非常强大，能够显着提高数据库查询效率和处理大量文本数据的能力。 1）InnoDB通过倒排索引实现全文搜索，支持基本和高级搜索查询。 2）使用MATCH和AGAINST关键字进行搜索，支持布尔模式和短语搜索。 3）优化方法包括使用分词技术、定期重建索引和调整缓存大小，以提升性能和准确性。
可以在 Windows 7 上安装 mysql 吗
Apr 08, 2025 pm 03:21 PM
是的，可以在 Windows 7 上安装 MySQL，虽然微软已停止支持 Windows 7，但 MySQL 仍兼容它。不过，安装过程中需要注意以下几点：下载适用于 Windows 的 MySQL 安装程序。选择合适的 MySQL 版本（社区版或企业版）。安装过程中选择适当的安装目录和字符集。设置 root 用户密码，并妥善保管。连接数据库进行测试。注意 Windows 7 上的兼容性问题和安全性问题，建议升级到受支持的操作系统。
InnoDB中的聚类索引和非簇索引（次级索引）之间的差异。
Apr 02, 2025 pm 06:25 PM
聚集索引和非聚集索引的区别在于：1.聚集索引将数据行存储在索引结构中，适合按主键查询和范围查询。2.非聚集索引存储索引键值和数据行的指针，适用于非主键列查询。
mysql：简单的概念，用于轻松学习
Apr 10, 2025 am 09:29 AM
MySQL是一个开源的关系型数据库管理系统。1）创建数据库和表：使用CREATEDATABASE和CREATETABLE命令。2）基本操作：INSERT、UPDATE、DELETE和SELECT。3）高级操作：JOIN、子查询和事务处理。4）调试技巧：检查语法、数据类型和权限。5）优化建议：使用索引、避免SELECT*和使用事务。
mysql用户和数据库的关系
Apr 08, 2025 pm 07:15 PM
MySQL 数据库中，用户和数据库的关系通过权限和表定义。用户拥有用户名和密码，用于访问数据库。权限通过 GRANT 命令授予，而表由 CREATE TABLE 命令创建。要建立用户和数据库之间的关系，需创建数据库、创建用户，然后授予权限。
mysql 和 mariadb 可以共存吗
Apr 08, 2025 pm 02:27 PM
MySQL 和 MariaDB 可以共存，但需要谨慎配置。关键在于为每个数据库分配不同的端口号和数据目录，并调整内存分配和缓存大小等参数。连接池、应用程序配置和版本差异也需要考虑，需要仔细测试和规划以避免陷阱。在资源有限的情况下，同时运行两个数据库可能会导致性能问题。
说明不同类型的MySQL索引（B树，哈希，全文，空间）。
Apr 02, 2025 pm 07:05 PM
MySQL支持四种索引类型：B-Tree、Hash、Full-text和Spatial。1.B-Tree索引适用于等值查找、范围查询和排序。2.Hash索引适用于等值查找，但不支持范围查询和排序。3.Full-text索引用于全文搜索，适合处理大量文本数据。4.Spatial索引用于地理空间数据查询，适用于GIS应用。
