mysql中limit的用法

LIMIT 直接将数字相加并返回前几个元素。
示例： LIMIT 1 0：如果表仅包含 5 0 个条目，则仅返回 5 0 个条目。
使用 LIMIT 1 0 OFFSET 5 进行分页。
从点 6 开始，取 1 0 个元素。
排序很重要，需要加上ORDER BY，否则顺序会乱。
示例：LIMIT 5 OFFSET 1 0 ORDER BY id DESC，按ID降序排序，获取元素1 1 到1 5 LIMIT 也可以用于子查询，例如B. SELECT FROM（子查询）LIMIT 1 0 不要使用像 1 0000 这样的大 OFFSET，因为它非常慢并且需要扫描数据库。
索引可以优化，但不要指望它能解决 OFFSET 慢的问题。
PostgreSQL也支持，不过MySQL的OFFSET是从0开始的，PostgreSQL是从1 开始的。
你自己掂量一下吧。

mysql中limit语句如何限制结果条数

哎，你问我使用MySQL LIMIT要注意什么？好吧，我会告诉你我经历过的陷阱和我所知道的有用的东西。

上周有客户问我，为什么他一页一页地检查数据，每次结果的顺序都不一样。
当我看到这个时，好吧，它确实使用 LIMIT 1 0, 1 0 来检查第 2 页，但没有添加 ORDER BY。
你应该注意这一点：如果没有指定ORDER BY，LIMIT返回的顺序是随机的！这对于分页场景来说是很糟糕的，用户肯定不会这样做。
因此，当分页或者需要固定顺序的时候，必须添加ORDER BY，比如ORDER BY id ASC或者ORDER BYcreated_at DESC。

还有一个陷阱——大排量的问题。
想一想，LIMIT 1 00000，1 0，对吧？这意味着跳过前 1 00,000 个项目并获取接下来的 1 0 个项目。
然后，MySQL 必须查找并扫描前 1 0001 0 条记录，然后才能给出结果。
当数据量很大的时候，性能简直惨不忍睹！我曾经有一个项目。
当用户点击第1 00页时，后台要等待十几秒。
后来改为根据ID增量查询。
例如，记住上一页的最后一个条目的 ID，并在下一页检查前 1 0 个 ID 大的条目。
或者使用子查询先找出ID中需要的部分，然后JOIN回来。
用这两种方法可以避免多少麻烦啊！
顺便说一下，如果ORDER BY之后没有索引，MySQL就要对文件进行排序（Filesort），这也会降低性能。
因此，对 ORDER BY 字段建立索引是一个基本操作。
如果能建立一个复合索引就更好了。
例如，如果我们想按日期和状态排序，我们将创建 INDEX(date, status)。

此外，请注意随机抽样。
当数据量很大时，直接使用 ORDER BY RAND() LIMIT 1 0 非常慢，因为必须为整个表的每一行计算一个随机数数字。
我试了一下，几百条数据还好，但是几万条数据就卡住半天了。
在这种情况下，最好使用基于id的随机算法，例如WHERE id >= FLOOR(RAND() MAX(id))。
首先，随机选择一个 ID，然后检查附近的几个 ID。

顺便说一下，LIMIT 在 JOIN 完成后应用，而不是在单独的表上。
例如，如果您编写 SELECT FROM a JOIN b ON a.id=b.id LIMIT 1 0，这实际上意味着在合并 a 和 b 后从结果集中取出前 1 0 条记录，而不是从 a 表中取出 1 0 条记录然后将它们连接到 b 表。
有时这会让人误以为结果是错误的，所以需要小心看清楚。

最后的提示：不要使用 SELECT，而是使用覆盖索引；谨慎使用SQL_CALC_FOUND_ROWS，它会导致全表扫描，需要两次查询（一次查数据，一次查总和），非常麻烦；当涉及到复杂的JOIN时，可以使用STRAIGHT_JOIN来固定连接顺序，或者使用子查询先过滤数据再连接。

无论如何，你都能弄清楚。
这是我从错误中学到的教训。
我希望他们能帮助你。
如果有什么不清楚的，继续问！