Compare tree structure, level cost, and range-scan growth to see what controls index performance.
Parameters
Rows N
rows
Rows in the table or index.
Fanout f
-
Child pointers per index page.
Page read
ms
Representative page read time.
Selectivity
%
Fraction of rows matched by the predicate.
While paused, move the sliders to update the result instantly.
B-tree lookup cost animation
Results
—
Rows N
—
Fanout f
—
Tree height (levels)
—
Index lookup I/O
—
Full scan I/O
Model and equations
$$h=\lceil\log_f N\rceil$$
B-tree height scales logarithmically with row count N and fanout f. Point lookup is height dominated, while range scans also depend on matched rows and page locality.
How to read it
The tree view shows height falling as fanout increases.
The cost plot links page-read time directly to latency.
The range plot shows leaf scanning dominating at higher selectivity.
Learn Database Index Btree Cost by dialogue
🙋
When reading Database Index Btree Cost, where should I look first? Moving Rows N changes both the plots and the result cards.
🎓
Start with B-tree height, but do not treat the number as the whole answer. Use B-tree level sketch to confirm the assumed state, then read Point lookup cost for the distribution or trend. The tree view shows height falling as fanout increases.
🙋
I can see why Rows N changes B-tree height. How should I judge the influence of Fanout f?
🎓
Move Fanout f in small steps and watch Point lookup cost. That reveals which term is controlling the result. B-tree height scales logarithmically with row count N and fanout f. Point lookup is height dominated, while range scans also depend on matched rows and page locality. A single operating point is not enough; sweep the realistic scatter range.
🙋
What is Range scan cost for? It feels like the ordinary curve already tells the story.
🎓
Range scan cost is for finding boundaries where the condition becomes risky or margin collapses quickly. The cost plot links page-read time directly to latency. In Early database-index sizing, the important question is often what happens after a small change, not only the nominal value.
🙋
So if B-tree height is within the target, can I accept the condition?
🎓
Treat this as a first-pass review. It helps with Comparing storage or cache assumptions and Separating point-query and range-query bottlenecks, but final decisions still need standards, measured data, detailed analysis, and vendor limits. The range plot shows leaf scanning dominating at higher selectivity.
Practical use
Early database-index sizing.
Comparing storage or cache assumptions.
Separating point-query and range-query bottlenecks.
FAQ
Start with B-tree height and Point lookup cost. Then use B-tree level sketch to confirm the assumed state and Point lookup cost to read distribution or bias. The tree view shows height falling as fanout increases
Move Rows N alone, then move Fanout f by a comparable amount and compare the change in B-tree height. Range scan cost shows combinations where margin or performance changes quickly.
Use it for Early database-index sizing. Instead of trusting a single point, widen the input range and check whether B-tree height keeps enough margin before moving to detailed analysis.
B-tree height scales logarithmically with row count N and fanout f. Point lookup is height dominated, while range scans also depend on matched rows and page locality. Final decisions still require standards, measured data, detailed analysis, and vendor limits.
How to Use
Enter total row count (e.g., 10,000,000 rows in a customer table) in the rows field
Set fanout—typical B-tree fanout ranges from 100–500 depending on key size and page size; use 128 for 8KB pages with 8-byte keys
Input page-read latency in milliseconds (typically 0.1–1 ms for SSD, 5–10 ms for HDD)
Set selectivity as a decimal (0.01 = 1% of rows matched by range predicate)
Simulator computes tree height using log(fanout, rowcount), point-lookup I/O cost, matched-row count, and range-scan cost including leaf-page traversal
Worked Example
Customer orders table: 50,000,000 rows, B-tree on order_date column, fanout=256, SSD read=0.5 ms, range selectivity=0.05 (5% of rows). Tree height = log₂₅₆(50M) ≈ 3.5 levels. Point lookup: 4 page reads × 0.5 ms = 2 ms. Matched rows: 50M × 0.05 = 2,500,000. Range-scan cost: 4 index pages + estimated 19,531 leaf pages (2.5M ÷ 128 fanout) × 0.5 ms ≈ 9,768 ms for full leaf traversal.
Practical Notes
Fanout drops significantly with composite keys or variable-length strings—retest after schema changes to index width
SSD fanout typically uses 0.1–0.3 ms read time; spinning disk 5–8 ms; adjust based on your storage tier and RAID configuration
Selectivity under 0.001 (0.1%) favors point lookups; above 0.1 (10%), full table scan or parallel range scan may outperform B-tree traversal
Tree height above 5 signals need for index clustering or partitioning on high-cardinality columns with millions of rows