两个方向上来解决
.
数据库层面
,
这也是我们主要集中关注的
(
虽然收效没那么大
),
类似于
select * from table where age > 20 limit 1000000,10
这种查询其实也是有可以优化的余
地的
.
这条语句需要
load1000000
数据然后基本上全部丢弃
,
只取
10
条当然比较慢
.
当时我们
可 以 修 改 为
select * from table where id in (select id from table where age > 20 limit
1000000,10).
这样虽然也
load
了一百万的数据
,
但是由于索引覆盖
,
要查询的所有字段都在索
引中
,
所以速度会很快
.
同时如果
ID
连续的好
,
我们还可以
select * from table where id >
1000000 limit 10,
效率也是不错的
,
优化的可能性有许多种
,
但是核心思想都一样
,
就是减少
load
的数据
.
从需求的角度减少这种请求…主要是不做类似的需求
(
直接跳转到几百万页之后的具体某一
页
.
只允许逐页查看或者按照给定的路线走
,
这样可预测
,
可缓存
)
以及防止
ID
泄漏且连续被人
恶意攻击
.
解决超大分页
,
其实主要是靠缓存
,
可预测性的提前查到内容
,
缓存至
redis
等
k-V
数据库中
,
直
接返回即可
.
【推荐】利用延迟关联或者子查询优化超多分页场景。
MySQL
并不是跳过
o&set
行,而是取
o&set+N
行,然后返回放弃前
o&set
行,返回
N
行,那
当
o&set
特别大的时候,效率就非常的低下,要么控制返回的总页数,要么对超过特定阈
值的页数进行
SQL
改写。
正例:先快速定位需要获取的
id
段,然后再关联:
SELECT a.* FROM
表
1 a, (select id from
表
1 where
条件
LIMIT 100000,20 ) b where a.id=b.id
评论