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

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

General paging

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

如果無法及時更新緩存，則一旦數據更改，所有以前的分頁緩存都將無效。

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

一個主意

最近，我想到了另一個主意。

數據緩存在redis中，ID為key；

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

查找數據時，首先從redis的skip list中提取相應的分頁數據，得到ID list。

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

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

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

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

如果您使用的是Lua腳本，則可以在一個請求中完成以下操作：

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

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

也許redis已經準備好存儲redis很長時間了，我不擔心內存容量。

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

正如房東所說，分頁查詢在我們的實際應用中非常常見，也是問題最多的查詢場景。例如，對于下面的簡單語句，通常的思考方式是在name、age、register中u在time字段上創(chuàng)建一個復合索引。這樣，條件排序可以有效地利用索引，性能得到快速提高。

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

，所以我們會覺得很慢。

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