1、RENAME
RENAME key newkey

將 key 改名為 newkey 。

當 key 和 newkey 相同，或者 key 不存在時，返回一個錯誤。

當 newkey 已經存在時， RENAME 命令將覆蓋舊值。

可用版本：
1.0.0及以上

返回值：
改名成功時提示 OK ，失敗時候返回一個錯誤。
key 存在且 newkey 不存在

redis> SET message “hello world”
OK

redis> RENAME message greeting
OK

redis> EXISTS message # message 不復存在
(integer) 0

redis> EXISTS greeting # greeting 取而代之
(integer) 1

當 key 不存在時，返回錯誤

redis> RENAME fake_key never_exists
(error) ERR no such key

newkey 已存在時， RENAME 會覆蓋舊 newkey

redis> SET pc “lenovo”
OK

redis> SET personal_computer “dell”
OK

redis> RENAME pc personal_computer
OK

redis> GET pc
(nil)

redis:1> GET personal_computer # 原來的值 dell 被覆蓋了
“lenovo”

2、RENAMENX
RENAMENX key newkey

當且僅當 newkey 不存在時，將 key 改名為 newkey 。

當 key 不存在時，返回一個錯誤。

可用版本：
1.0.0及以上

返回值：
修改成功時，返回 1 。
如果 newkey 已經存在，返回 0 。

newkey 不存在，改名成功

redis> SET player “MPlyaer”
OK

redis> EXISTS best_player
(integer) 0

redis> RENAMENX player best_player
(integer) 1

newkey存在時，失敗

redis> SET animal “bear”
OK

redis> SET favorite_animal “butterfly”
OK

redis> RENAMENX animal favorite_animal
(integer) 0

redis> get animal
“bear”

redis> get favorite_animal
“butterfly”

3、RESTORE

RESTORE key ttl serialized-value [REPLACE]

反序列化給定的序列化值，並將它和給定的 key 關聯。

引數 ttl 以毫秒為單位為 key 設定生存時間；如果 ttl 為 0 ，那麼不設定生存時間。

RESTORE 在執行反序列化之前會先對序列化值的 RDB 版本和資料校驗和進行檢查，如果 RDB 版本不相同或者資料不完整的話，那麼 RESTORE 會拒絕進行反序列化，並返回一個錯誤。

如果鍵 key 已經存在， 並且給定了 REPLACE 選項， 那麼使用反序列化得出的值來代替鍵 key 原有的值； 相反地， 如果鍵 key 已經存在， 但是沒有給定 REPLACE 選項， 那麼命令返回一個錯誤。

更多資訊可以參考 DUMP 命令。

可用版本：
2.6.0及以上

返回值：
如果反序列化成功那麼返回 OK ，否則返回一個錯誤。
建立一個鍵，作為 DUMP 命令的輸入

redis> SET greeting “hello, dumping world!”
OK

redis> DUMP greeting
“\x00\x15hello, dumping world!\x06\x00E\xa0Z\x82\xd8r\xc1\xde”

將序列化資料 RESTORE 到另一個鍵上面

redis> RESTORE greeting-again 0 “\x00\x15hello, dumping world!\x06\x00E\xa0Z\x82\xd8r\xc1\xde”
OK

redis> GET greeting-again
“hello, dumping world!”

在沒有給定 REPLACE 選項的情況下，再次嘗試反序列化到同一個鍵，失敗

redis> RESTORE greeting-again 0 “\x00\x15hello, dumping world!\x06\x00E\xa0Z\x82\xd8r\xc1\xde”
(error) ERR Target key name is busy.

給定 REPLACE 選項，對同一個鍵進行反序列化成功

redis> RESTORE greeting-again 0 “\x00\x15hello, dumping world!\x06\x00E\xa0Z\x82\xd8r\xc1\xde” REPLACE
OK

嘗試使用無效的值進行反序列化，出錯

redis> RESTORE fake-message 0 “hello moto moto blah blah”
(error) ERR DUMP payload version or checksum are wrong

4、SORT

SORT key [BY pattern] [LIMIT offset count] [GET pattern [GET pattern …]] [ASC | DESC] [ALPHA] [STORE destination]

返回或儲存給定列表、集合、有序集合 key 中經過排序的元素。

排序預設以數字作為物件，值被解釋為雙精度浮點數，然後進行比較。

一般 SORT 用法
最簡單的 SORT 使用方法是 SORT key 和 SORT key DESC ：

SORT key 返回鍵值從小到大排序的結果。
SORT key DESC 返回鍵值從大到小排序的結果。
假設 today_cost 列表儲存了今日的開銷金額， 那麼可以用 SORT 命令對它進行排序：

開銷金額列表

redis> LPUSH today_cost 30 1.5 10 8
(integer) 4

排序

redis> SORT today_cost
1) “1.5”
2) “8”
3) “10”
4) “30”

逆序排序

redis 127.0.0.1:6379> SORT today_cost DESC
1) “30”
2) “10”
3) “8”
4) “1.5”
使用 ALPHA 修飾符對字串進行排序
因為 SORT 命令預設排序物件為數字， 當需要對字串進行排序時， 需要顯式地在 SORT 命令之後新增 ALPHA 修飾符：

網址

redis> LPUSH website “www.reddit.com”
(integer) 1

redis> LPUSH website “www.slashdot.com”
(integer) 2

redis> LPUSH website “www.infoq.com”
(integer) 3

預設（按數字）排序

redis> SORT website
1) “www.infoq.com”
2) “www.slashdot.com”
3) “www.reddit.com”

按字元排序

redis> SORT website ALPHA
1) “www.infoq.com”
2) “www.reddit.com”
3) “www.slashdot.com”
如果系統正確地設定了 LC_COLLATE 環境變數的話，Redis能識別 UTF-8 編碼。

使用 LIMIT 修飾符限制返回結果
排序之後返回元素的數量可以通過 LIMIT 修飾符進行限制， 修飾符接受 offset 和 count 兩個引數：

offset 指定要跳過的元素數量。
count 指定跳過 offset 個指定的元素之後，要返回多少個物件。
以下例子返回排序結果的前 5 個物件( offset 為 0 表示沒有元素被跳過)。

新增測試資料，列表值為 1 指 10

redis 127.0.0.1:6379> RPUSH rank 1 3 5 7 9
(integer) 5

redis 127.0.0.1:6379> RPUSH rank 2 4 6 8 10
(integer) 10

返回列表中最小的 5 個值

redis 127.0.0.1:6379> SORT rank LIMIT 0 5
1) “1”
2) “2”
3) “3”
4) “4”
5) “5”
可以組合使用多個修飾符。以下例子返回從大到小排序的前 5 個物件。

redis 127.0.0.1:6379> SORT rank LIMIT 0 5 DESC
1) “10”
2) “9”
3) “8”
4) “7”
5) “6”
使用外部 key 進行排序
可以使用外部 key 的資料作為權重，代替預設的直接對比鍵值的方式來進行排序。

假設現在有使用者資料如下：

uid user_name_{uid} user_level_{uid}
1 admin 9999
2 jack 10
3 peter 25
4 mary 70
以下程式碼將資料輸入到 Redis 中：

admin

redis 127.0.0.1:6379> LPUSH uid 1
(integer) 1

redis 127.0.0.1:6379> SET user_name_1 admin
OK

redis 127.0.0.1:6379> SET user_level_1 9999
OK

jack

redis 127.0.0.1:6379> LPUSH uid 2
(integer) 2

redis 127.0.0.1:6379> SET user_name_2 jack
OK

redis 127.0.0.1:6379> SET user_level_2 10
OK

peter

redis 127.0.0.1:6379> LPUSH uid 3
(integer) 3

redis 127.0.0.1:6379> SET user_name_3 peter
OK

redis 127.0.0.1:6379> SET user_level_3 25
OK

mary

redis 127.0.0.1:6379> LPUSH uid 4
(integer) 4

redis 127.0.0.1:6379> SET user_name_4 mary
OK

redis 127.0.0.1:6379> SET user_level_4 70
OK
BY 選項

預設情況下， SORT uid 直接按 uid 中的值排序：

redis 127.0.0.1:6379> SORT uid
1) “1” # admin
2) “2” # jack
3) “3” # peter
4) “4” # mary
通過使用 BY 選項，可以讓 uid 按其他鍵的元素來排序。

比如說， 以下程式碼讓 uid 鍵按照 user_level_{uid} 的大小來排序：

redis 127.0.0.1:6379> SORT uid BY user_level_*
1) “2” # jack , level = 10
2) “3” # peter, level = 25
3) “4” # mary, level = 70
4) “1” # admin, level = 9999
user_level_* 是一個佔位符， 它先取出 uid 中的值， 然後再用這個值來查詢相應的鍵。

比如在對 uid 列表進行排序時， 程式就會先取出 uid 的值 1 、 2 、 3 、 4 ， 然後使用 user_level_1 、 user_level_2 、 user_level_3 和 user_level_4 的值作為排序 uid 的權重。

GET 選項

使用 GET 選項， 可以根據排序的結果來取出相應的鍵值。

比如說， 以下程式碼先排序 uid ， 再取出鍵 user_name_{uid} 的值：

redis 127.0.0.1:6379> SORT uid GET user_name_*
1) “admin”
2) “jack”
3) “peter”
4) “mary”
組合使用 BY 和 GET

通過組合使用 BY 和 GET ， 可以讓排序結果以更直觀的方式顯示出來。

比如說， 以下程式碼先按 user_level_{uid} 來排序 uid 列表， 再取出相應的 user_name_{uid} 的值：

redis 127.0.0.1:6379> SORT uid BY user_level_* GET user_name_*
1) “jack” # level = 10
2) “peter” # level = 25
3) “mary” # level = 70
4) “admin” # level = 9999
現在的排序結果要比只使用 SORT uid BY user_level_* 要直觀得多。

獲取多個外部鍵

可以同時使用多個 GET 選項， 獲取多個外部鍵的值。

以下程式碼就按 uid 分別獲取 user_level_{uid} 和 user_name_{uid} ：

redis 127.0.0.1:6379> SORT uid GET user_level_* GET user_name_*
1) “9999” # level
2) “admin” # name
3) “10”
4) “jack”
5) “25”
6) “peter”
7) “70”
8) “mary”
GET 有一個額外的引數規則，那就是 —— 可以用 # 獲取被排序鍵的值。

以下程式碼就將 uid 的值、及其相應的 user_level_* 和 user_name_* 都返回為結果：

redis 127.0.0.1:6379> SORT uid GET # GET user_level_* GET user_name_*
1) “1” # uid
2) “9999” # level
3) “admin” # name
4) “2”
5) “10”
6) “jack”
7) “3”
8) “25”
9) “peter”
10) “4”
11) “70”
12) “mary”
獲取外部鍵，但不進行排序

通過將一個不存在的鍵作為引數傳給 BY 選項， 可以讓 SORT 跳過排序操作， 直接返回結果：

redis 127.0.0.1:6379> SORT uid BY not-exists-key
1) “4”
2) “3”
3) “2”
4) “1”
這種用法在單獨使用時，沒什麼實際用處。

不過，通過將這種用法和 GET 選項配合， 就可以在不排序的情況下， 獲取多個外部鍵， 相當於執行一個整合的獲取操作（類似於 SQL 資料庫的 join 關鍵字）。

以下程式碼演示了，如何在不引起排序的情況下，使用 SORT 、 BY 和 GET 獲取多個外部鍵：

redis 127.0.0.1:6379> SORT uid BY not-exists-key GET # GET user_level_* GET user_name_*
1) “4” # id
2) “70” # level
3) “mary” # name
4) “3”
5) “25”
6) “peter”
7) “2”
8) “10”
9) “jack”
10) “1”
11) “9999”
12) “admin”
將雜湊表作為 GET 或 BY 的引數

除了可以將字串鍵之外， 雜湊表也可以作為 GET 或 BY 選項的引數來使用。

比如說，對於前面給出的使用者資訊表：

uid user_name_{uid} user_level_{uid}
1 admin 9999
2 jack 10
3 peter 25
4 mary 70
我們可以不將使用者的名字和級別儲存在 user_name_{uid} 和 user_level_{uid} 兩個字串鍵中， 而是用一個帶有 name 域和 level 域的雜湊表 user_info_{uid} 來儲存使用者的名字和級別資訊：

redis 127.0.0.1:6379> HMSET user_info_1 name admin level 9999
OK

redis 127.0.0.1:6379> HMSET user_info_2 name jack level 10
OK

redis 127.0.0.1:6379> HMSET user_info_3 name peter level 25
OK

redis 127.0.0.1:6379> HMSET user_info_4 name mary level 70
OK
之後， BY 和 GET 選項都可以用 key->field 的格式來獲取雜湊表中的域的值， 其中 key 表示雜湊表鍵， 而 field 則表示雜湊表的域：

redis 127.0.0.1:6379> SORT uid BY user_info_*->level
1) “2”
2) “3”
3) “4”
4) “1”

redis 127.0.0.1:6379> SORT uid BY user_info_*->level GET user_info_*->name
1) “jack”
2) “peter”
3) “mary”
4) “admin”
儲存排序結果
預設情況下， SORT 操作只是簡單地返回排序結果，並不進行任何儲存操作。

通過給 STORE 選項指定一個 key 引數，可以將排序結果儲存到給定的鍵上。

如果被指定的 key 已存在，那麼原有的值將被排序結果覆蓋。

測試資料

redis 127.0.0.1:6379> RPUSH numbers 1 3 5 7 9
(integer) 5

redis 127.0.0.1:6379> RPUSH numbers 2 4 6 8 10
(integer) 10

redis 127.0.0.1:6379> LRANGE numbers 0 -1
1) “1”
2) “3”
3) “5”
4) “7”
5) “9”
6) “2”
7) “4”
8) “6”
9) “8”
10) “10”

redis 127.0.0.1:6379> SORT numbers STORE sorted-numbers
(integer) 10

排序後的結果

redis 127.0.0.1:6379> LRANGE sorted-numbers 0 -1
1) “1”
2) “2”
3) “3”
4) “4”
5) “5”
6) “6”
7) “7”
8) “8”
9) “9”
10) “10”
可以通過將 SORT 命令的執行結果儲存，並用 EXPIRE 為結果設定生存時間，以此來產生一個 SORT 操作的結果快取。

這樣就可以避免對 SORT 操作的頻繁呼叫：只有當結果集過期時，才需要再呼叫一次 SORT 操作。

另外，為了正確實現這一用法，你可能需要加鎖以避免多個客戶端同時進行快取重建(也就是多個客戶端，同一時間進行 SORT 操作，並儲存為結果集)，具體參見 SETNX 命令。

可用版本：
1.0.0及以上

返回值：
沒有使用 STORE 引數，返回列表形式的排序結果。
使用 STORE 引數，返回排序結果的元素數量。

5、TTL
TTL key

以秒為單位，返回給定 key 的剩餘生存時間(TTL, time to live)。

可用版本：
1.0.0及以上

返回值：
當 key 不存在時，返回 -2 。
當 key 存在但沒有設定剩餘生存時間時，返回 -1 。
否則，以秒為單位，返回 key 的剩餘生存時間。
在 Redis 2.8 以前，當 key 不存在，或者 key 沒有設定剩餘生存時間時，命令都返回 -1 。
不存在的 key

redis> FLUSHDB
OK

redis> TTL key
(integer) -2

key 存在，但沒有設定剩餘生存時間

redis> SET key value
OK

redis> TTL key
(integer) -1

有剩餘生存時間的 key

redis> EXPIRE key 10086
(integer) 1

redis> TTL key
(integer) 10084

6、TYPE

TYPE key

返回 key 所儲存的值的型別。

可用版本：
1.0.0及以上

返回值：
none (key不存在)
string (字串)
list (列表)
set (集合)
zset (有序集)
hash (雜湊表)
字串

redis> SET weather “sunny”
OK

redis> TYPE weather
string

列表

redis> LPUSH book_list “programming in scala”
(integer) 1

redis> TYPE book_list
list

集合

redis> SADD pat “dog”
(integer) 1

redis> TYPE pat
set

7、SCAN
SCAN cursor [MATCH pattern] [COUNT count]

SCAN 命令及其相關的 SSCAN 命令、 HSCAN 命令和 ZSCAN 命令都用於增量地迭代（incrementally iterate）一集元素（a collection of elements）：

SCAN 命令用於迭代當前資料庫中的資料庫鍵。
SSCAN 命令用於迭代集合鍵中的元素。
HSCAN 命令用於迭代雜湊鍵中的鍵值對。
ZSCAN 命令用於迭代有序集合中的元素（包括元素成員和元素分值）。
以上列出的四個命令都支援增量式迭代， 它們每次執行都只會返回少量元素， 所以這些命令可以用於生產環境， 而不會出現像 KEYS 命令、 SMEMBERS 命令帶來的問題 —— 當 KEYS 命令被用於處理一個大的資料庫時， 又或者 SMEMBERS 命令被用於處理一個大的集合鍵時， 它們可能會阻塞伺服器達數秒之久。

不過， 增量式迭代命令也不是沒有缺點的： 舉個例子， 使用 SMEMBERS 命令可以返回集合鍵當前包含的所有元素， 但是對於 SCAN 這類增量式迭代命令來說， 因為在對鍵進行增量式迭代的過程中， 鍵可能會被修改， 所以增量式迭代命令只能對被返回的元素提供有限的保證 （offer limited guarantees about the returned elements）。

因為 SCAN 、 SSCAN 、 HSCAN 和 ZSCAN 四個命令的工作方式都非常相似， 所以這個文件會一併介紹這四個命令， 但是要記住：

SSCAN 命令、 HSCAN 命令和 ZSCAN 命令的第一個引數總是一個數據庫鍵。
而 SCAN 命令則不需要在第一個引數提供任何資料庫鍵 —— 因為它迭代的是當前資料庫中的所有資料庫鍵。
SCAN 命令的基本用法
SCAN 命令是一個基於遊標的迭代器（cursor based iterator）： SCAN 命令每次被呼叫之後， 都會向用戶返回一個新的遊標， 使用者在下次迭代時需要使用這個新遊標作為 SCAN 命令的遊標引數， 以此來延續之前的迭代過程。

當 SCAN 命令的遊標引數被設定為 0 時， 伺服器將開始一次新的迭代， 而當伺服器向用戶返回值為 0 的遊標時， 表示迭代已結束。

以下是一個 SCAN 命令的迭代過程示例：

redis 127.0.0.1:6379> scan 0
1) “17”
2) 1) “key:12”
2) “key:8”
3) “key:4”
4) “key:14”
5) “key:16”
6) “key:17”
7) “key:15”
8) “key:10”
9) “key:3”
10) “key:7”
11) “key:1”

redis 127.0.0.1:6379> scan 17
1) “0”
2) 1) “key:5”
2) “key:18”
3) “key:0”
4) “key:2”
5) “key:19”
6) “key:13”
7) “key:6”
8) “key:9”
9) “key:11”
在上面這個例子中， 第一次迭代使用 0 作為遊標， 表示開始一次新的迭代。

第二次迭代使用的是第一次迭代時返回的遊標， 也即是命令回覆第一個元素的值 —— 17 。

從上面的示例可以看到， SCAN 命令的回覆是一個包含兩個元素的陣列， 第一個陣列元素是用於進行下一次迭代的新遊標， 而第二個陣列元素則是一個數組， 這個陣列中包含了所有被迭代的元素。

在第二次呼叫 SCAN 命令時， 命令返回了遊標 0 ， 這表示迭代已經結束， 整個資料集（collection）已經被完整遍歷過了。

以 0 作為遊標開始一次新的迭代， 一直呼叫 SCAN 命令， 直到命令返回遊標 0 ， 我們稱這個過程為一次完整遍歷（full iteration）。

SCAN 命令的保證（guarantees）
SCAN 命令， 以及其他增量式迭代命令， 在進行完整遍歷的情況下可以為使用者帶來以下保證： 從完整遍歷開始直到完整遍歷結束期間， 一直存在於資料集內的所有元素都會被完整遍歷返回； 這意味著， 如果有一個元素， 它從遍歷開始直到遍歷結束期間都存在於被遍歷的資料集當中， 那麼 SCAN 命令總會在某次迭代中將這個元素返回給使用者。

然而因為增量式命令僅僅使用遊標來記錄迭代狀態， 所以這些命令帶有以下缺點：

同一個元素可能會被返回多次。 處理重複元素的工作交由應用程式負責， 比如說， 可以考慮將迭代返回的元素僅僅用於可以安全地重複執行多次的操作上。
如果一個元素是在迭代過程中被新增到資料集的， 又或者是在迭代過程中從資料集中被刪除的， 那麼這個元素可能會被返回， 也可能不會， 這是未定義的（undefined）。
SCAN 命令每次執行返回的元素數量
增量式迭代命令並不保證每次執行都返回某個給定數量的元素。

增量式命令甚至可能會返回零個元素， 但只要命令返回的遊標不是 0 ， 應用程式就不應該將迭代視作結束。

不過命令返回的元素數量總是符合一定規則的， 在實際中：

對於一個大資料集來說， 增量式迭代命令每次最多可能會返回數十個元素；
而對於一個足夠小的資料集來說， 如果這個資料集的底層表示為編碼資料結構（encoded data structure，適用於是小集合鍵、小雜湊鍵和小有序集合鍵）， 那麼增量迭代命令將在一次呼叫中返回資料集中的所有元素。
最後， 使用者可以通過增量式迭代命令提供的 COUNT 選項來指定每次迭代返回元素的最大值。

COUNT 選項
雖然增量式迭代命令不保證每次迭代所返回的元素數量， 但我們可以使用 COUNT 選項， 對命令的行為進行一定程度上的調整。

基本上， COUNT 選項的作用就是讓使用者告知迭代命令， 在每次迭代中應該從資料集裡返回多少元素。

雖然 COUNT 選項只是對增量式迭代命令的一種提示（hint）， 但是在大多數情況下， 這種提示都是有效的。

COUNT 引數的預設值為 10 。
在迭代一個足夠大的、由雜湊表實現的資料庫、集合鍵、雜湊鍵或者有序集合鍵時， 如果使用者沒有使用 MATCH 選項， 那麼命令返回的元素數量通常和 COUNT 選項指定的一樣， 或者比 COUNT 選項指定的數量稍多一些。
在迭代一個編碼為整數集合（intset，一個只由整數值構成的小集合）、 或者編碼為壓縮列表（ziplist，由不同值構成的一個小雜湊或者一個小有序集合）時， 增量式迭代命令通常會無視 COUNT 選項指定的值， 在第一次迭代就將資料集包含的所有元素都返回給使用者。
並非每次迭代都要使用相同的 COUNT 值。
使用者可以在每次迭代中按自己的需要隨意改變 COUNT 值， 只要記得將上次迭代返回的遊標用到下次迭代裡面就可以了。

MATCH 選項
和 KEYS 命令一樣， 增量式迭代命令也可以通過提供一個 glob 風格的模式引數， 讓命令只返回和給定模式相匹配的元素， 這一點可以通過在執行增量式迭代命令時， 通過給定 MATCH pattern 引數來實現。

以下是一個使用 MATCH 選項進行迭代的示例：

redis 127.0.0.1:6379> sadd myset 1 2 3 foo foobar feelsgood
(integer) 6

redis 127.0.0.1:6379> sscan myset 0 match f*
1) “0”
2) 1) “foo”
2) “feelsgood”
3) “foobar”
需要注意的是， 對元素的模式匹配工作是在命令從資料集中取出元素之後， 向客戶端返回元素之前的這段時間內進行的， 所以如果被迭代的資料集中只有少量元素和模式相匹配， 那麼迭代命令或許會在多次執行中都不返回任何元素。

以下是這種情況的一個例子：

redis 127.0.0.1:6379> scan 0 MATCH 11
1) “288”
2) 1) “key:911”

redis 127.0.0.1:6379> scan 288 MATCH 11
1) “224”
2) (empty list or set)

redis 127.0.0.1:6379> scan 224 MATCH 11
1) “80”
2) (empty list or set)

redis 127.0.0.1:6379> scan 80 MATCH 11
1) “176”
2) (empty list or set)

redis 127.0.0.1:6379> scan 176 MATCH 11 COUNT 1000
1) “0”
2) 1) “key:611”
2) “key:711”
3) “key:118”
4) “key:117”
5) “key:311”
6) “key:112”
7) “key:111”
8) “key:110”
9) “key:113”
10) “key:211”
11) “key:411”
12) “key:115”
13) “key:116”
14) “key:114”
15) “key:119”
16) “key:811”
17) “key:511”
18) “key:11”
如你所見， 以上的大部分迭代都不返回任何元素。

在最後一次迭代， 我們通過將 COUNT 選項的引數設定為 1000 ， 強制命令為本次迭代掃描更多元素， 從而使得命令返回的元素也變多了。

併發執行多個迭代
在同一時間， 可以有任意多個客戶端對同一資料集進行迭代， 客戶端每次執行迭代都需要傳入一個遊標， 並在迭代執行之後獲得一個新的遊標， 而這個遊標就包含了迭代的所有狀態， 因此， 伺服器無須為迭代記錄任何狀態。

中途停止迭代
因為迭代的所有狀態都儲存在遊標裡面， 而伺服器無須為迭代儲存任何狀態， 所以客戶端可以在中途停止一個迭代， 而無須對伺服器進行任何通知。

即使有任意數量的迭代在中途停止， 也不會產生任何問題。

使用錯誤的遊標進行增量式迭代
使用間斷的（broken）、負數、超出範圍或者其他非正常的遊標來執行增量式迭代並不會造成伺服器崩潰， 但可能會讓命令產生未定義的行為。

未定義行為指的是， 增量式命令對返回值所做的保證可能會不再為真。

只有兩種遊標是合法的：

在開始一個新的迭代時， 遊標必須為 0 。
增量式迭代命令在執行之後返回的， 用於延續（continue）迭代過程的遊標。
迭代終結的保證
增量式迭代命令所使用的演算法只保證在資料集的大小有界（bounded）的情況下， 迭代才會停止， 換句話說， 如果被迭代資料集的大小不斷地增長的話， 增量式迭代命令可能永遠也無法完成一次完整迭代。

從直覺上可以看出， 當一個數據集不斷地變大時， 想要訪問這個資料集中的所有元素就需要做越來越多的工作， 能否結束一個迭代取決於使用者執行迭代的速度是否比資料集增長的速度更快。

可用版本：

2.8.0及以上

返回值：

SCAN 命令、 SSCAN 命令、 HSCAN 命令和 ZSCAN 命令都返回一個包含兩個元素的 multi-bulk 回覆： 回覆的第一個元素是字串表示的無符號 64 位整數（遊標）， 回覆的第二個元素是另一個 multi-bulk 回覆， 這個 multi-bulk 回覆包含了本次被迭代的元素。

SCAN 命令返回的每個元素都是一個數據庫鍵。

SSCAN 命令返回的每個元素都是一個集合成員。

HSCAN 命令返回的每個元素都是一個鍵值對，一個鍵值對由一個鍵和一個值組成。

ZSCAN 命令返回的每個元素都是一個有序集合元素，一個有序集合元素由一個成員（member）和一個分值（score）組成