redis怎么緩存用戶列表，做到可以分頁(yè)展示？General pagingGeneral paging caching是直接查找出來，逐頁(yè)放入緩存，但是這種緩存方法有很多缺點(diǎn)。如果無法及時(shí)更新緩存，則

redis怎么緩存用戶列表，做到可以分頁(yè)展示？

General paging

General paging caching是直接查找出來，逐頁(yè)放入緩存，但是這種緩存方法有很多缺點(diǎn)。

如果無法及時(shí)更新緩存，則一旦數(shù)據(jù)更改，所有以前的分頁(yè)緩存都將無效。

例如，在像微博這樣的場(chǎng)景中，微博下有排名靠前的次數(shù)。這在傳統(tǒng)的分頁(yè)中很難處理。

一個(gè)主意

最近，我想到了另一個(gè)主意。

數(shù)據(jù)緩存在redis中，ID為key；

數(shù)據(jù)ID和排序得分保存在redis的skip list中，即Zset；

查找數(shù)據(jù)時(shí)，首先從redis的skip list中提取相應(yīng)的分頁(yè)數(shù)據(jù)，得到ID list。

使用multi-get一次從redis獲取ID列表中的所有數(shù)據(jù)。如果有缺少某個(gè)ID的數(shù)據(jù)，將從數(shù)據(jù)庫(kù)中搜索并返回給用戶，搜索到的數(shù)據(jù)將按ID緩存在redis中

在最后一步，您可以有一些提示：

例如，如果缺少某個(gè)ID數(shù)據(jù)，首先直接返回給用戶，然后前端使用Ajax請(qǐng)求丟失的ID數(shù)據(jù)，然后動(dòng)態(tài)刷新。

還有一些優(yōu)化可能會(huì)將操作與Lua腳本合并，但是考慮到Lua腳本比較慢，您可能需要仔細(xì)測(cè)試它們。

如果您使用的是Lua腳本，則可以在一個(gè)請(qǐng)求中完成以下操作：

查找頁(yè)面上的所有文章，返回緩存文章的ID和內(nèi)容，以及不在緩存中的文章的ID列表。

其他事項(xiàng)：Lua支持LRU模式，類似memcached。但奇怪的是，沒有人這樣使用它。

也許redis已經(jīng)準(zhǔn)備好存儲(chǔ)redis很長(zhǎng)時(shí)間了，我不擔(dān)心內(nèi)存容量。

為什么MySQL在數(shù)據(jù)庫(kù)較大的時(shí)候分頁(yè)查詢很慢，如何優(yōu)化？

正如房東所說，分頁(yè)查詢?cè)谖覀兊膶?shí)際應(yīng)用中非常常見，也是問題最多的查詢場(chǎng)景。例如，對(duì)于下面的簡(jiǎn)單語(yǔ)句，通常的思考方式是在name、age、register中u在time字段上創(chuàng)建一個(gè)復(fù)合索引。這樣，條件排序可以有效地利用索引，性能得到快速提高。

如上例所示，當(dāng)limit子句變?yōu)椤發(fā)imit 100000，50”時(shí)，我們會(huì)發(fā)現(xiàn)，如果只選擇了50條語(yǔ)句，為什么會(huì)變慢？

，所以我們會(huì)覺得很慢。

通常，在分頁(yè)查詢時(shí)，可以在上一頁(yè)中獲取數(shù)據(jù)標(biāo)志，以縮小查詢范圍，如時(shí)間。我們可以將上一頁(yè)的最長(zhǎng)時(shí)間作為查詢條件的一部分。SQL可以優(yōu)化如下：