Interview kitsBlog

Your dream job? Lets Git IT.
Interactive technical interview preparation platform designed for modern developers.

XGitHub

Platform

  • Categories

Resources

  • Blog
  • About the app
  • FAQ
  • Feedback

Legal

  • Privacy Policy
  • Terms of Service

© 2026 LetsGit.IT. All rights reserved.

LetsGit.IT/Categories/Databases
Databasesmedium

Why can the optimizer choose a bad query plan and how do statistics help?

Tags
#optimizer#statistics#cardinality#performance
Back to categoryPractice quiz

Answer

The optimizer picks a plan based on estimated row counts (cardinality). If estimates are wrong (stale stats, skewed data, correlated columns), it can choose the wrong join order or algorithm. Updating statistics (e.g., ANALYZE) and using appropriate indexes helps the optimizer estimate better.

Advanced answer

Deep dive

Expanding on the short answer — what usually matters in practice:

  • Context (tags): optimizer, statistics, cardinality, performance
  • Data model and access patterns: dominant queries (read/write ratio, sorting, pagination).
  • Indexes: when they help vs hurt (write amplification, memory).
  • Consistency & transactions: what’s guaranteed and what can bite you.
  • Explain the "why", not just the "what" (intuition + consequences).
  • Trade-offs: what you gain/lose (time, memory, complexity, risk).
  • Edge cases: empty inputs, large inputs, invalid inputs, concurrency.

Examples

A tiny example (query shape):

-- Example: index + query shape
SELECT *
FROM users
WHERE email = '[email protected]'
LIMIT 1;

Common pitfalls

  • Too generic: no concrete trade-offs or examples.
  • Mixing average-case and worst-case (e.g., complexity).
  • Ignoring constraints: memory, concurrency, network/disk costs.

Interview follow-ups

  • When would you choose an alternative and why?
  • What production issues show up and how do you diagnose them?
  • How would you test edge cases?

Related questions

Databases
Denormalization: when might you do it and what’s the trade‑off?
#database#denormalization#performance
Databases
What is a covering index (index‑only scan) and why can it be faster?
#database#indexes#covering-index
Databases
Index selectivity: what is it and why does it matter?
#indexes#selectivity#performance
Databases
What is write amplification and why do many indexes make writes slower?
#performance#indexes#write-amplification
Databases
What is a materialized view and when would you use it?
#views#materialized-view#performance
Databases
Why is `SELECT *` risky in production queries?
#sql#best-practices#performance