SCAN for safe key iteration in Redis - Step-by-Step Execution

Concept Flow - SCAN for safe key iteration

Start with cursor = 0

↓

Call SCAN cursor MATCH pattern COUNT n

↓

Receive new cursor and keys batch

↓

Process keys batch

↓

Is cursor == 0?

No→Repeat SCAN with new cursor

Yes↓

End iteration

SCAN starts with cursor 0, returns a batch of keys and a new cursor. Repeat until cursor returns to 0, safely iterating keys without blocking.

Execution Sample

Redis

SCAN 0 MATCH user:* COUNT 2
SCAN 3 MATCH user:* COUNT 2
SCAN 0 MATCH user:* COUNT 2

This example shows scanning keys matching 'user:*' in batches of 2, iterating safely until cursor returns to 0.

Execution Table

Step	Input Cursor	Command	Returned Cursor	Keys Returned	Action
1	0	SCAN 0 MATCH user:* COUNT 2	3	[user:1, user:2]	Process keys user:1, user:2
2	3	SCAN 3 MATCH user:* COUNT 2	0	[user:3]	Process key user:3
3	0	End	-	-	Cursor 0 means iteration complete

💡 Cursor returned 0 at step 2, so iteration ends safely without blocking.

Variable Tracker

Variable	Start	After Step 1	After Step 2	Final
cursor	0	3	0	0
keys_batch	[]	[user:1, user:2]	[user:3]	[]

Key Moments - 3 Insights

Why do we start SCAN with cursor 0?

SCAN always starts with cursor 0 to begin iteration from the start. See execution_table step 1 where input cursor is 0.

What does it mean when SCAN returns cursor 0?

Cursor 0 means the iteration is complete and no more keys remain. See execution_table step 2 where returned cursor is 0, ending iteration.

Why is SCAN safer than KEYS for large datasets?

SCAN returns keys in small batches without blocking Redis, unlike KEYS which blocks. This is shown by multiple steps returning partial keys in execution_table.

Visual Quiz - 3 Questions

Look at the execution_table, what is the cursor value after step 1?

A 2

B 3

C 0

D 1

💡 Hint

Check the 'Returned Cursor' column in execution_table row for step 1.

At which step does the SCAN command indicate the iteration is complete?

A Step 3

B Step 1

C Step 2

D Step 4

💡 Hint

Look for the step where 'Returned Cursor' is 0 in execution_table.

If COUNT was increased to 5, how would the keys returned per step change?

A More keys per batch, fewer steps

B Fewer keys per batch, more steps

C No change in keys per batch

D SCAN would return all keys at once

💡 Hint

COUNT controls batch size, see how keys returned relate to COUNT in execution_table.

Concept Snapshot

SCAN command iterates keys safely without blocking.
Start with cursor 0.
Each SCAN returns a new cursor and a batch of keys.
Repeat SCAN with new cursor until cursor returns 0.
Use MATCH to filter keys and COUNT to control batch size.

Full Transcript

The SCAN command in Redis allows safe iteration over keys without blocking the server. It starts with cursor 0 and returns a batch of keys plus a new cursor. You process the keys returned, then call SCAN again with the new cursor. When SCAN returns cursor 0, the iteration is complete. This method is safer than using KEYS because it does not block Redis and handles large datasets efficiently. You can use MATCH to filter keys and COUNT to control how many keys are returned per batch.

Practice

1. What is the main advantage of using SCAN over KEYS in Redis for iterating keys?

easy

A. SCAN returns all keys at once for faster access.

B. SCAN only works with sorted sets.

C. SCAN deletes keys while iterating.

D. SCAN does not block Redis and returns keys in batches.

Solution

1. Step 1: Understand KEYS behavior

   KEYS returns all matching keys at once and blocks Redis during execution.

2. Step 2: Understand SCAN behavior

   SCAN returns keys in small batches without blocking Redis, allowing safe iteration.

3. Final Answer:

   SCAN does not block Redis and returns keys in batches. -> Option D

4. Quick Check:

   Safe iteration = SCAN non-blocking [OK]

Hint: Remember: SCAN is non-blocking, KEYS blocks [OK]

Common Mistakes:

• Thinking SCAN returns all keys at once
• Confusing SCAN with key deletion
• Assuming SCAN only works on sorted sets

2. Which of the following is the correct syntax to start a SCAN iteration from the beginning in Redis CLI?

easy

A. SCAN 1

B. SCAN 0

C. SCAN *

D. SCAN start

Solution

1. Step 1: Identify the starting cursor for SCAN

   The SCAN command requires a cursor argument; starting cursor is always 0.

2. Step 2: Check options for correct cursor

   SCAN 0 starts iteration from the beginning; other options are invalid.

3. Final Answer:

   SCAN 0 -> Option B

4. Quick Check:

   Start cursor = 0 [OK]

Hint: Always start SCAN with cursor 0 [OK]

Common Mistakes:

• Starting with cursor 1 instead of 0
• Using wildcard * as cursor
• Using invalid strings like 'start'

3. Given the following Redis commands executed sequentially, what will be the output of the last SCAN command?

SET user:1 Alice
SET user:2 Bob
SET admin:1 Carol
SCAN 0 MATCH user:*

medium

A. [cursor, ["user:1", "user:2"]]

B. [0, ["user:1", "user:2"]]

C. [cursor, ["user:1", "user:2", "admin:1"]]

D. [0, ["admin:1"]]

Solution

1. Step 1: Understand SCAN with MATCH

   The MATCH user:* filters keys starting with 'user:'. So keys 'user:1' and 'user:2' match; 'admin:1' does not.

2. Step 2: Understand SCAN output format

   SCAN returns a two-element array: a cursor (string) and a list of keys matching the pattern in this batch. Cursor is not necessarily 0 unless iteration is complete.

3. Final Answer:

   [cursor, ["user:1", "user:2"]] -> Option A

4. Quick Check:

   Filtered keys = user keys only [OK]

Hint: MATCH filters keys; cursor is a string, not always 0 [OK]

Common Mistakes:

• Expecting cursor 0 on first SCAN call
• Including keys not matching pattern
• Confusing cursor with count

4. You wrote this Redis command to iterate keys safely:

SCAN 0 MATCH user:*

But you notice it returns only a partial list of keys matching the pattern. What is the likely mistake?

medium

A. Not repeating SCAN with the returned cursor until it returns 0.

B. Using MATCH with an incorrect pattern.

C. Starting SCAN with cursor 1 instead of 0.

D. Using COUNT option with a value too high.

Solution

1. Step 1: Understand SCAN iteration process

   SCAN returns a cursor and a batch of keys; to get all keys, you must repeat SCAN with the new cursor until it returns 0.

2. Step 2: Identify the mistake

   Running SCAN 0 MATCH user:* only once returns partial keys; not looping causes incomplete results.

3. Final Answer:

   Not repeating SCAN with the returned cursor until it returns 0. -> Option A

4. Quick Check:

   Repeat SCAN until cursor 0 [OK]

Hint: Always loop SCAN calls until cursor returns 0 [OK]

Common Mistakes:

• Expecting all keys in one SCAN call
• Misusing MATCH pattern syntax
• Starting with wrong cursor

5. You want to safely iterate all keys starting with session: in Redis but avoid blocking the server. You also want to limit each batch to about 10 keys. Which command sequence correctly achieves this?

hard

A. Use SCAN 0 COUNT 10 without MATCH.

B. Run KEYS session:* once to get all keys.

C. Repeat SCAN cursor MATCH session:* COUNT 10 until cursor returns 0.

D. Use SCAN 0 MATCH session:* once without COUNT.

Solution

1. Step 1: Use SCAN with MATCH and COUNT

   To filter keys starting with 'session:' and limit batch size, use MATCH session:* and COUNT 10.

2. Step 2: Repeat SCAN calls until cursor is 0

   Iterate by passing the returned cursor each time until it returns 0 to get all keys safely without blocking.

3. Final Answer:

   Repeat SCAN cursor MATCH session:* COUNT 10 until cursor returns 0. -> Option C

4. Quick Check:

   Safe iteration + filter + batch size = Repeat SCAN cursor MATCH session:* COUNT 10 until cursor returns 0. [OK]

Hint: Combine MATCH and COUNT, loop until cursor 0 [OK]

Common Mistakes:

• Using KEYS which blocks Redis
• Not looping SCAN calls
• Omitting MATCH or COUNT when needed