SQL Server Internals
Twenty years of SQL Server incidents have a way of clarifying what actually matters. The ORM doesn't matter. The framework doesn't matter. What matters is what happens between the storage engine and your result set — because that's where the 3 AM phone calls come from.
Each topic below has a written explanation and at least one interactive drill. Read in order or jump to what's on fire.
Storage and I/O Fundamentals
SQL Server thinks in 8 KB pages, not rows. Pages live on spinning or solid-state storage where sequential reads are an order of magnitude cheaper than random. Everything the engine does — scans, seeks, prefetch — is a consequence of this single physical reality.
explore →Cost-Based Optimization
The optimizer doesn't look for the correct plan — every plan that returns the right rows is correct. It looks for the cheapest one, using cost estimates built on statistics that are sometimes embarrassingly wrong.
explore →Indexes, Statistics, and Cardinality Estimation
An index is a B+ tree. Statistics are histograms. Cardinality estimation is the optimizer guessing how many rows your predicate matches — and everything downstream in the plan depends on that guess being close enough.
explore →Execution Plans
How to read the operator tree, find where estimated and actual rows diverge, and write predicates that the index can actually consume. SARGable vs non-SARGable — the single most common reason an index exists but does not get used.
explore →Index Design
The three-star index: equality predicates can go in any order, but a range predicate must be last among the matching columns. OR predicates break the single-seek model and translate to UNION ALL. One algorithm, deterministic result — not an art form.
explore →