Hash indexes in DBMS Theory - Step-by-Step Execution

Concept Flow - Hash indexes

Start: Query with search key

↓

Apply hash function to key

↓

Compute hash value (bucket address)

↓

Access bucket in hash index

↓

Check bucket for matching record

Yes No↓

Return record

The flow shows how a hash index uses a hash function on a search key to find the bucket address, then accesses that bucket to find the matching record or report it missing.

Execution Sample

DBMS Theory

Search key = 42
Hash function: h(key) = key mod 5
Buckets: 0 to 4
Find bucket for key 42
Check bucket for record

This example shows how a hash function maps a search key to a bucket number to quickly locate the record.

Analysis Table

Step	Action	Input	Hash Function Result	Bucket Accessed	Record Found?
1	Receive search key	42	-	-	-
2	Apply hash function	42	42 mod 5 = 2	-	-
3	Access bucket	-	-	Bucket 2	-
4	Search bucket for key	-	-	Bucket 2	Yes
5	Return record	-	-	-	Record with key 42

💡 Record found in bucket 2, search ends successfully

State Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	Final
search_key	N/A	42	42	42	42
hash_value	N/A	2	2	2	2
bucket_accessed	N/A	N/A	Bucket 2	Bucket 2	Bucket 2
record_found	N/A	N/A	N/A	Yes	Yes

Key Insights - 2 Insights

Why do we use a hash function on the search key?

The hash function converts the search key into a bucket number to quickly locate where the record might be stored, as shown in step 2 of the execution table.

What happens if the record is not found in the bucket?

If the record is not in the bucket, the search ends with no result. This is shown by the 'No' branch in the concept flow after checking the bucket.

Visual Quiz - 3 Questions

Look at the execution table, what is the hash value computed for the search key 42?

A 2

B 5

C 42

D 0

💡 Hint

Check Step 2 in the execution table where the hash function result is shown.

At which step does the system access the bucket in the hash index?

A Step 4

B Step 1

C Step 3

D Step 5

💡 Hint

Refer to the 'Bucket Accessed' column in the execution table.

If the hash function changed to h(key) = key mod 3, which bucket would key 42 map to?

A Bucket 1

B Bucket 0

C Bucket 2

D Bucket 3

💡 Hint

Calculate 42 mod 3 and compare with the bucket numbers.

Concept Snapshot

Hash indexes use a hash function to convert a search key into a bucket address.
The bucket stores pointers to records with keys mapping to it.
Searching involves computing the hash, accessing the bucket, and checking for the record.
This method provides fast direct access but works best for equality searches.

Full Transcript

Hash indexes help databases find records quickly by using a hash function on the search key. The hash function converts the key into a bucket number. The system then looks inside that bucket to find the record. If the record is there, it returns it; if not, it reports no match. This process is fast because it avoids scanning many records. The example shows searching for key 42 using a hash function that takes the key modulo 5, resulting in bucket 2. The record is found in bucket 2, so the search ends successfully.

Practice

1. What is the primary purpose of a hash index in a database?

easy

A. To store data in sorted order

B. To speed up range queries

C. To compress data for storage

D. To speed up exact key lookups

Solution

1. Step 1: Understand the function of hash indexes

   Hash indexes convert keys into hash values to quickly find exact matches.

2. Step 2: Compare with other index types

   Unlike B-tree indexes, hash indexes do not support range queries or sorting.

3. Final Answer:

   To speed up exact key lookups -> Option D

4. Quick Check:

   Hash index = exact key lookup speed [OK]

Hint: Hash indexes are for exact matches, not ranges [OK]

Common Mistakes:

• Thinking hash indexes support range queries
• Confusing hash indexes with sorted indexes
• Assuming hash indexes compress data

2. Which of the following is the correct syntax to create a hash index on a column named user_id in SQL (assuming the database supports hash indexes)?

easy

A. CREATE INDEX idx_user ON users USING HASH (user_id);

B. CREATE HASH INDEX idx_user ON users (user_id);

C. CREATE INDEX idx_user ON users (user_id) HASH;

D. CREATE INDEX idx_user HASH ON users (user_id);

Solution

1. Step 1: Recall standard SQL syntax for hash indexes

   The correct syntax uses CREATE INDEX with USING HASH to specify the index type.

2. Step 2: Analyze each option

   CREATE INDEX idx_user ON users USING HASH (user_id); correctly places USING HASH after the index name and before the column list.

3. Final Answer:

   CREATE INDEX idx_user ON users USING HASH (user_id); -> Option A

4. Quick Check:

   Syntax for hash index = CREATE INDEX ... USING HASH ... [OK]

Hint: Use 'USING HASH' after index name to specify hash index [OK]

Common Mistakes:

• Placing HASH keyword incorrectly
• Omitting USING keyword
• Using non-standard syntax unsupported by SQL

3. Consider the following SQL query on a table with a hash index on email column:

SELECT * FROM users WHERE email = '[e-mail]';

What is the expected behavior of the database when using the hash index?

medium

A. It performs a range scan on the email column

B. It scans the entire table because hash indexes do not support equality

C. It performs a fast exact match lookup using the hash index

D. It returns an error because hash indexes cannot be used in WHERE clauses

Solution

1. Step 1: Understand hash index usage in equality queries

   Hash indexes are designed to quickly find rows matching an exact key value.

2. Step 2: Analyze the query condition

   The WHERE clause uses equality on the indexed column, so the hash index is used efficiently.

3. Final Answer:

   It performs a fast exact match lookup using the hash index -> Option C

4. Quick Check:

   Equality query + hash index = fast lookup [OK]

Hint: Hash indexes speed up exact equality queries [OK]

Common Mistakes:

• Thinking hash indexes do full table scans
• Confusing hash index with range scan
• Assuming hash indexes cause errors in queries

4. A developer created a hash index on the phone_number column but notices that queries with LIKE '%1234' are slow. What is the most likely reason?

medium

A. The hash index is corrupted and needs rebuilding

B. Hash indexes do not support pattern matching or partial searches

C. The database does not support hash indexes on numeric columns

D. The query optimizer ignores all indexes for LIKE queries

Solution

1. Step 1: Understand hash index limitations

   Hash indexes only support exact key lookups, not pattern matching or partial searches.

2. Step 2: Analyze the query pattern

   The LIKE '%1234' pattern searches for suffix matches, which hash indexes cannot optimize.

3. Final Answer:

   Hash indexes do not support pattern matching or partial searches -> Option B

4. Quick Check:

   Hash index ≠ pattern matching support [OK]

Hint: Hash indexes only speed exact matches, not LIKE patterns [OK]

Common Mistakes:

• Assuming hash indexes speed up all LIKE queries
• Blaming index corruption without evidence
• Thinking numeric columns can't have hash indexes

5. You want to optimize a database table for fast lookups on a customer_id column, but also need to efficiently query ranges of order_date. Which indexing strategy is best?

hard

A. Create a hash index on customer_id and a B-tree index on order_date

B. Create hash indexes on both customer_id and order_date

C. Create a B-tree index on customer_id and no index on order_date

D. Create no indexes and rely on full table scans

Solution

1. Step 1: Match index types to query needs

   Hash indexes are best for exact key lookups like on customer_id.

2. Step 2: Use B-tree indexes for range queries

   B-tree indexes efficiently support range queries, so use it on order_date.

3. Final Answer:

   Create a hash index on customer_id and a B-tree index on order_date -> Option A

4. Quick Check:

   Hash for exact, B-tree for range queries [OK]

Hint: Use hash for exact keys, B-tree for ranges [OK]

Common Mistakes:

• Using hash index for range queries
• Not indexing columns needed for fast queries
• Relying on full scans for large tables