Wednesday, May 27, 2026 · 9:41 AM
ok can you explain denormalization and SQL tuning like i actually need to build it
SQL tuning is about matching queries to data layout so the database reads less, sorts less, locks less, and guesses less
mental picture: keep the VIP list at the door instead of calling headquarters for every person in line
good, now do the real thing
not the fake diagram version
EXPLAIN plans show whether a query scans, seeks, joins, sorts, or uses an index
indexes should match frequent filters, joins, ordering, and cardinality, not every column someone likes
so the first move is making the invisible numbers visible
exactly
normalization reduces duplication and update bugs, but some reads need precomputed or duplicated data
what changes when this gets real traffic?
denormalization stores derived or repeated values to avoid expensive joins at read time
materialized views, counters, rollups, and search indexes are ways to move work earlier
wait, i thought the better answer was just adding the serious-sounding tool
that is the trap
denormalization is not dirty by default. uncontrolled denormalization is dirty
ok so what bill shows up later?
normalized writes are cleaner
denormalized reads can be much faster
derived data needs invalidation, backfills, and repair paths
where do people usually mess this up?
adding indexes blindly until writes slow down and the planner still avoids them
if i were designing this tomorrow, what should i write down first?
the read path
the write path
the thing that is allowed to be stale
the thing that absolutely is not
that is annoyingly practical
yeah. most system design is boring on purpose
measure the query, add the smallest useful index or precompute, and document how stale derived data can get
got it
less architecture cosplay, more pressure map
perfect
draw the pressure, then choose the machinery
Read Wed, May 27 · 9:58 AM