使用limit的深度分页，查询比较缓慢怎么办。

1. 查询字段不要直接 * ，可以都列出来，还可以加索引。
2. 页面上的查询条件可以给多一点，多个条件才能查询，不要仅是分页。
3. 可以加缓存，加静态页。

这种情况一般不允许无限分页了，只展示最近的 N 条，如 id > 最大id - 100000，分页器的 total 数量也直接写死

1. 模仿百度、谷歌方案（前端业务控制）

类似于分段。我们给每次只能翻100页、超过一百页的需要重新加载后面的100页。这样就解决了每次加载数量数据大 速度慢的问题了

2. 记录每次取出的最大id， 然后where id > 最大id

select * from table_name Where id > 最大id limit 10000, 10; 这种方法适用于：除了主键ID等离散型字段外，也适用连续型字段datetime等 最大id由前端分页pageNum和pageIndex计算出来

这种一般是计算总数量的时候，速度缓慢。建议使用 forPage 直接获取。然后每次请求都是传第几页，一直到下一页没数据了，表示数据已经请求完成，

这种分页查询方式会从数据库第一条记录开始扫描，所以越往后，查询速度越慢.所以你得跳过前 10万条. Where id > 100000,不过实际业务会有查询条件,所以得用子查询加上查询条件找这个 ID的值

select * from users where `type`=1 and where id > (select id from users where `type`=1 limit 100000,1) limit 100

除了楼上的思路，还要就是可以上ES等存储检索引擎，检索后回表重新取出数据

不改业务需求的话，无解！

首先要锁死最多查多少条多少页，不允许无限分页

如果一定要查的话，那么加上主键id，比如上一次查询主键id是 10000000，那么你就是 where id > 10000000 limit 100

升序降序的话自己改where条件就好了

• 1、计算出offset。 limit 100000,100 -> where id > 100000 limit 100 。
• 2、延迟关联。先用索引覆盖查到分页主键，再用主键获取数据

查询的时候 可以带上id 比如id倒叙排列 where('id','<',$min_id)

可以利用覆盖索引减少一些查询时间。

方案一

SELECT*FROM users AS a 
INNER JOIN (SELECT id FROM users WHERE `type`=1 LIMIT 100000,100) AS b 
ON a.id=b.id;

方案二

SELECT id FROM users WHERE `type`=1 LIMIT 100000,100;
SELECT * FROM users WHERE id IN(上一步结果);

当使用limit进行分页时，查询可能会变得缓慢，这通常是因为limit需要查询整个表然后再返回所需的部分。，可以尝试使用下面的方法来提高查询的效率。

• 使用索引：索引可以提高查询的速度，因此，可以尝试在查询的字段上建立索引。
• 使用更高效的分页方法：可以尝试使用基于记录ID的分页方法，例如偏移量分页。这种方法可以避免查询整个表，并可以快速找到所需的记录。
• 使用缓存：如果某些查询特别缓慢，可以尝试使用缓存来存储查询结果，以便在下一次查询时直接返回缓存的结果。这可以减少查询的次数，提高查询的效率。
• 优化查询语句：您可以尝试优化查询语句，以减少查询所需的时间。例如，可以避免在查询中使用不必要的函数或运算符，以及使用适当的约束条件来限制查询的范围。

让用户条件筛选缩小范围 不允许 这种查询行为 :see_no_evil: