DEL and UNLINK for deletion in Redis - Time & Space Complexity

Time Complexity: DEL and UNLINK for deletion

O(n)

Understanding Time Complexity

When deleting keys in Redis, it's important to know how the time it takes grows as you delete more keys.

We want to understand how the commands DEL and UNLINK behave as the number of keys changes.

Scenario Under Consideration

Analyze the time complexity of these Redis commands:

DEL key1 key2 key3 ... keyN
UNLINK key1 key2 key3 ... keyN
    

These commands delete one or more keys from the database, but they work differently internally.

Identify Repeating Operations

Look at what repeats when deleting multiple keys:

• Primary operation: Deleting each key one by one.
• How many times: Once for each key given to DEL or UNLINK.

How Execution Grows With Input

As you increase the number of keys to delete, the work grows roughly in direct proportion.

Input Size (n)	Approx. Operations
10	About 10 delete actions
100	About 100 delete actions
1000	About 1000 delete actions

Pattern observation: The time grows linearly as you add more keys to delete.

Final Time Complexity

Time Complexity: O(n)

This means the time to delete keys grows directly with the number of keys you delete.

Common Mistake

[X] Wrong: "UNLINK deletes keys instantly with no cost regardless of how many keys."

[OK] Correct: UNLINK frees memory asynchronously but still must process each key, so its time grows with the number of keys.

Interview Connect

Understanding how deletion commands scale helps you write efficient Redis code and explain your choices clearly in real projects or interviews.

Self-Check

"What if we delete keys one by one in a loop instead of passing them all at once? How would the time complexity change?"

Practice

1. What is the main difference between DEL and UNLINK commands in Redis?

easy

A. DEL deletes keys immediately and blocks Redis, while UNLINK deletes keys asynchronously in the background.

B. DEL deletes keys asynchronously, while UNLINK deletes keys immediately and blocks Redis.

C. DEL only deletes one key at a time, UNLINK deletes multiple keys.

D. DEL moves keys to a recycle bin, UNLINK permanently deletes keys.

Solution

1. Step 1: Understand DEL behavior

   DEL removes keys immediately and blocks Redis until deletion finishes.

2. Step 2: Understand UNLINK behavior

   UNLINK removes keys asynchronously in the background without blocking Redis.

3. Final Answer:

   DEL deletes keys immediately and blocks Redis, while UNLINK deletes keys asynchronously in the background. -> Option A

4. Quick Check:

   Deletion blocking = DEL [OK]

Hint: Remember: DEL blocks, UNLINK is non-blocking [OK]

Common Mistakes:

• Thinking UNLINK blocks Redis like DEL
• Believing DEL deletes keys asynchronously
• Confusing number of keys each command can delete

2. Which of the following is the correct syntax to delete keys key1 and key2 using the UNLINK command in Redis?

easy

A. UNLINK (key1, key2)

B. UNLINK key1 key2

C. UNLINK [key1, key2]

D. UNLINK 'key1' 'key2'

Solution

1. Step 1: Recall Redis command syntax

   Redis commands take keys as space-separated arguments without brackets or quotes.

2. Step 2: Match syntax for multiple keys

   UNLINK key1 key2 correctly deletes both keys at once.

3. Final Answer:

   UNLINK key1 key2 -> Option B

4. Quick Check:

   Space-separated keys = correct syntax [OK]

Hint: Use space-separated keys without brackets or quotes [OK]

Common Mistakes:

• Adding parentheses or brackets around keys
• Using quotes around keys unnecessarily
• Separating keys with commas

3. Given the following Redis commands executed in order:
SET key1 "value1"
SET key2 "value2"
DEL key1
UNLINK key2
What keys remain in the database after these commands?

medium

A. No keys remain

B. Only key1 remains

C. Only key2 remains

D. Both key1 and key2 remain

Solution

1. Step 1: Analyze DEL key1

   DEL key1 deletes key1 immediately.

2. Step 2: Analyze UNLINK key2

   UNLINK key2 deletes key2 asynchronously, but it will be removed eventually.

3. Final Answer:

   No keys remain -> Option A

4. Quick Check:

   Both keys deleted = no keys left [OK]

Hint: Both DEL and UNLINK remove keys, so none remain [OK]

Common Mistakes:

• Assuming UNLINK does not delete keys
• Thinking UNLINK delays deletion indefinitely
• Believing DEL only marks keys for deletion

4. You run the command DEL key1 key2 but get an error. Which of the following is the most likely cause?

medium

A. One or both keys do not exist

B. You need to use UNLINK instead of DEL

C. DEL cannot delete multiple keys at once

D. You used commas between keys like DEL key1, key2

Solution

1. Step 1: Check syntax for multiple keys

   Redis commands require keys separated by spaces, not commas.

2. Step 2: Identify error cause

   Using commas like DEL key1, key2 causes syntax error.

3. Final Answer:

   You used commas between keys like DEL key1, key2 -> Option D

4. Quick Check:

   Keys must be space-separated [OK]

Hint: Avoid commas; separate keys with spaces only [OK]

Common Mistakes:

• Using commas between keys
• Thinking DEL can't delete multiple keys
• Confusing missing keys with syntax errors

5. You want to delete 1000 large keys in Redis without blocking the server. Which command and approach is best?

hard

A. Delete keys one by one with DEL in a loop

B. Use UNLINK with all 1000 keys at once

C. Use UNLINK on keys in small batches asynchronously

D. Use DEL with all 1000 keys at once

Solution

1. Step 1: Understand blocking behavior of DEL

   DEL blocks Redis and deleting 1000 large keys at once can cause latency spikes.

2. Step 2: Use UNLINK in batches

   UNLINK deletes keys asynchronously; batching avoids large memory spikes and keeps Redis responsive.

3. Final Answer:

   Use UNLINK on keys in small batches asynchronously -> Option C

4. Quick Check:

   Batch UNLINK = safe large deletion [OK]

Hint: Batch UNLINK to delete large keys without blocking [OK]

Common Mistakes:

• Using DEL for large bulk deletes causing blocking
• Deleting keys one by one causing slow performance
• Using UNLINK without batching causing memory spikes