Skip to content
Zeni Study
  • Pages
    • Learn Python In 7 Days
      • Day 1 : Variable + if/else
      • Day 2: Loops
      • Day 3 : Array + String
      • Day 4 — Functions
      • Day 5 — Dictionaries - Hashmap
      • Day 6 — Files & Errors
      • Day 7 — Mini Project & Programmer Thinking
    • Machine Coding:
      • Day 1 — Bank account + Wallet :
      • Day 2 : RateLimiter + seat booking
      • Day 3 : Library Management + Classroom Attendance System
      • Day 4 : Bank account and notification system.
      • Day 5 : Key-value and payment processor.
      • Day 6 : Discount engine + Seat booking( in depth)
      • Day 7: Parking lot System :
    • Machine coding extended:
      • Day 7.5 — Parking Lot (Constraint-Heavy Variant)
      • Day 8 : Order + Payment System
      • Day 8 — Extension Round (Mid-Interview Change)
      • Day 9 — Ticket Booking with Expiry (Simulated Time)
      • Day 9 — Extension Round (Seat Lock Ownership + Forced Unlock)
    • SQL + DB Thinking course
      • Day 1 — Tables, Rows & Thinking in Data
      • Day 2 — Relationships & Foreign Keys (Thinking in Connections)
      • Day 3 — Filtering, Aggregation & Answering Data Questions
      • Day 4 — JOINs (Combining Tables the Right Way)
      • Day 5 — Subqueries, EXISTS & NOT EXISTS (Thinking in Layers)
      • icon picker
        Day 6 — Indexes, Constraints & How Databases Think
      • Day 7 — Full SQL Interview Simulation (SDE-1 Ready)
      • Extended Day 1 — Core Business Systems (Deep Practice)
      • Extended Day 2 — Booking & Platform Systems (High-Depth Practice)
      • Extended Day 3 — Content & Learning Platforms (Capstone Practice)
    • LLD: Java
      • DAY 1 — Core Foundations (SDE-2 Level)
      • DAY 2 — State, Time & Domain Correctness
      • DAY 3 — Extensibility & Failure Handling (SDE-2 Core Signal)
      • DAY 4 — Concurrency, Scheduling & Consistency (SDE-2 Critical)
      • DAY 5 — Workflow Design & Config-Driven Systems (SDE-2+)
      • DAY 6 — Eventing & Usage-Based Systems (Advanced SDE-2)
      • DAY 7 — Interview Simulation (Hard, Production-Grade)
      • Hidden Edge Cases Interviewers Expect (Day-wise)
      • Detailed Testing file:
    • Assignment:
      • If else Practice Set

Day 6 — Indexes, Constraints & How Databases Think

🟢 Day 6 — Indexes, Constraints & How Databases Think

🎯 Day 6 Outcome

By the end of Day 6, the student should be able to:
Explain why indexes exist
Decide what to index and what not to
Use constraints to protect data
Answer DB design questions verbally
Avoid common performance mistakes
Interviewers don’t expect you to tune databases. They expect you to not do stupid things.

1️⃣ Why Queries Become Slow (Teaching Script)

Ask the student:
“How does the database find a row?”
Without index:
It scans every row
Called full table scan
With index:
Uses a data structure (like sorted map)
Directly jumps to the row
Indexes exist to avoid scanning everything.

2️⃣ What Is an Index? (Simple Explanation)

An index is a separate data structure that helps the database find rows faster.
Example:
Phone book → index on name
Book → index at the end

3️⃣ Example Without Index

SELECT * FROM users WHERE email = 'a@gmail.com';
Database:
Checks every row
Slow if table is large

4️⃣ Creating an Index

CREATE INDEX idx_users_email ON users(email);
Now:
Database jumps directly to matching rows
Much faster for read queries

5️⃣ What Columns Should Be Indexed? (Interview Gold)

Good Candidates for Index

Primary keys (auto-indexed)
Foreign keys
Columns used in:
WHERE
JOIN
ORDER BY

Bad Candidates

Columns with very few unique values (e.g. gender)
Columns rarely queried
Small tables (index overhead > benefit)

6️⃣ Trade-off of Indexes (Must Know)

Advantage
Cost
Faster reads
Slower writes
Faster joins
More memory
Faster filters
Index maintenance
There are no rows in this table
❗ Don’t index everything blindly.

7️⃣ Constraints — Guardrails for Data

Constraints stop bad data from entering DB.

PRIMARY KEY

Unique
Not null
user_id INT PRIMARY KEY

UNIQUE

email VARCHAR(100) UNIQUE
Prevents duplicate emails

NOT NULL

name VARCHAR(100) NOT NULL

FOREIGN KEY

FOREIGN KEY (user_id) REFERENCES users(user_id)
Ensures relationship correctness

8️⃣ What Interviewers Ask (Very Common)

Q: Why not store everything in one table?

A:
Data duplication
Inconsistency
Hard updates

Q: Why index foreign keys?

A:
Faster JOINs
Faster lookups

Q: Why not index all columns?

A:
Slower inserts/updates
Wasted memory

9️⃣ Schema Design Thinking (Practice)

Design DB for Blog System

Entities:
Users
Posts
Comments

Suggested Schema

users(user_id PK, name, email UNIQUE)
posts(post_id PK, user_id FK, title, content)
comments(comment_id PK, post_id FK, user_id FK, text)

Index Suggestions

users(user_id)
posts(user_id)
comments(post_id)

🔟 Practice Problems (Think, Not Just Write)

Problem 1 — Indexing

Which columns should be indexed in:
orders(order_id, user_id, created_at, status)

Problem 2 — Constraints

Which constraints would you add for:
users table
orders table

Problem 3 — Verbal

Answer:
Why indexes speed up SELECT?
Why indexes slow down INSERT?
What happens if index is missing?

🔍 HINTS

Index = fast search, slow write
Constraint = data safety
Think usage patterns, not syntax

✅ Sample Answers

Problem 1 — Indexing

Index:
order_id (PK)
user_id (FK)
created_at (if queried often)

Problem 2 — Constraints

users:
PRIMARY KEY (user_id)
UNIQUE (email)
NOT NULL (name)
orders:
PRIMARY KEY (order_id)
FOREIGN KEY (user_id)

🧠 Reflection Questions

When does index hurt performance?
Why is primary key always indexed?
What’s worse: missing index or bad schema?
How would you explain index to a non-tech person?

⭐ Day 6 Golden Rule

Indexes optimize queries. Constraints protect data. Both are required for real systems.


 
Want to print your doc?
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.