HEXISTS for field check in Redis - Time & Space Complexity
We want to understand how long it takes to check if a field exists in a Redis hash using HEXISTS.
Specifically, how the time changes when the hash grows bigger.
Analyze the time complexity of the following code snippet.
# Check if field "user:123" exists in hash "session_data"
HEXISTS session_data user:123
This command checks if a specific field is present inside a Redis hash.
Look for any repeated steps that affect time.
- Primary operation: Searching for the field key inside the hash.
- How many times: The search happens once per HEXISTS call.
The time to find the field depends on how Redis stores the hash internally.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 1 step (direct lookup) |
| 100 | About 1 step (direct lookup) |
| 1000 | About 1 step (direct lookup) |
Pattern observation: The lookup time stays almost the same even if the hash grows larger.
Time Complexity: O(1)
This means checking if a field exists takes about the same time no matter how many fields are in the hash.
[X] Wrong: "Checking a field takes longer as the hash gets bigger because Redis must look through all fields."
[OK] Correct: Redis uses a fast internal structure (like a hash table) that lets it find fields quickly without scanning all entries.
Knowing that Redis commands like HEXISTS run in constant time helps you understand how to design fast data checks in real projects.
"What if the hash was stored as a simple list instead of a hash table? How would the time complexity change?"
Practice
HEXISTS key field do?Solution
Step 1: Understand the HEXISTS command purpose
HEXISTS checks if a specific field exists inside a Redis hash stored at a given key.Step 2: Identify the correct behavior
It returns 1 if the field exists, otherwise 0. It does not delete, list, or set fields.Final Answer:
Checks if the specified field exists in the hash stored at key -> Option DQuick Check:
HEXISTS checks field existence = B [OK]
- Confusing HEXISTS with HDEL (delete)
- Thinking HEXISTS returns the field value
- Assuming HEXISTS lists all fields
age exists in hash user:1 using HEXISTS?Solution
Step 1: Recall HEXISTS command syntax
The correct syntax isHEXISTS key field, where key is the hash key and field is the field name.Step 2: Match syntax with options
HEXISTS user:1 age matches the correct syntax:HEXISTS user:1 age. Other options have wrong order or invalid format.Final Answer:
HEXISTS user:1 age -> Option AQuick Check:
HEXISTS key field syntax = C [OK]
- Swapping key and field positions
- Using colon between key and field
- Adding commas between arguments
user:2 with fields {"name": "Alice", "email": "alice@example.com"}, what will HEXISTS user:2 phone return?Solution
Step 1: Check if field 'phone' exists in hash user:2
The hash has fields 'name' and 'email' only. 'phone' is not present.Step 2: Understand HEXISTS return value
HEXISTS returns 1 if field exists, 0 if it does not. Since 'phone' is missing, it returns 0.Final Answer:
0 -> Option CQuick Check:
Field missing returns 0 = D [OK]
- Expecting nil instead of 0
- Thinking it returns an error for missing fields
- Confusing with HGET which returns nil
HEXISTS user:3 name but get an error. Which of the following is the most likely cause?Solution
Step 1: Understand HEXISTS error causes
HEXISTS returns error if the key exists but is not a hash type. If key does not exist, it returns 0, no error.Step 2: Eliminate distractors
Misspelled field returns 0, no error. HEXISTS checks one field. Server down causes connection failure, not command error. Wrong key type causes WRONGTYPE error.Final Answer:
The key user:3 exists but is not a hash -> Option BQuick Check:
Wrong key type causes HEXISTS error = A [OK]
- Assuming misspelled field causes error
- Thinking HEXISTS needs multiple fields
- Ignoring key type mismatch
status to a Redis hash order:100 only if it does not already exist. Which sequence of commands correctly uses HEXISTS to check before adding?Solution
Step 1: Understand the goal
You want to add 'status' only if it does not exist, so first check with HEXISTS if field is missing (returns 0).Step 2: Analyze command sequences
HEXISTS order:100 status IF 0 THEN HSET order:100 status 'pending' END checks HEXISTS, then if result is 0 (field missing), it sets the field. This matches the requirement. HSET order:100 status 'pending' HEXISTS order:100 status sets field unconditionally first. HEXISTS order:100 status IF 1 THEN HSET order:100 status 'pending' END sets field if HEXISTS returns 1 (field exists), which is wrong. HGET order:100 status IF nil THEN HSET order:100 status 'pending' END uses HGET and nil check, which is valid but not using HEXISTS as asked.Final Answer:
HEXISTS order:100 status IF 0 THEN HSET order:100 status 'pending' END -> Option AQuick Check:
Check HEXISTS=0 before HSET = A [OK]
- Setting field without checking existence
- Checking HEXISTS=1 to add field
- Using HGET instead of HEXISTS when asked
Ready to prove it?
Pass the test and this pattern moves unknown
