LRU has a well-known weakness: it treats recency as a proxy for value. A page touched once by a scan looks just as valuable as a page touched every 50ms by your hottest query. LRU can't tell them apart, so a single sequential scan can flush your working set. LFU overcorrects the other way — old-but-frequent pages linger forever even after the workload shifts.

LIRS (Low Inter-reference Recency Set) takes a different measurement entirely. Instead of asking "when was this page last touched?", it asks: how many distinct other pages were touched between this page's last two accesses? That distance is called IRR (Inter-Reference Recency). Low IRR means the page is genuinely hot — it gets reused before much else churns through. High IRR means it's cold, even if it was touched recently.

The cache is split into two logical sets:

• LIR set (~99% of capacity): pages with low IRR — the confirmed hot set. Never evicted until demoted.
• HIR set (~1% of capacity): pages on probation. Resident HIR pages can be evicted immediately; non-resident HIR pages keep only their metadata so we can measure IRR if they come back.

When a HIR page is accessed again and its measured IRR beats the worst LIR page, it gets promoted to LIR and the demoted LIR page becomes HIR. That's the key trick: pages earn LIR status by proving low reuse distance, not by being recent.

Concrete example. A reporting service caches 1000 pages. Every second, 50 hot pages are hit repeatedly. Then a nightly job scans 10,000 unique pages once. Under LRU, the scan evicts all 50 hot pages — the next second's traffic hits disk 50 times. Under LIRS, each scanned page enters as HIR with high IRR (nothing before, nothing after). Since scanned pages never prove low IRR, they cycle through the small HIR slice and never displace the LIR set. Hot pages stay resident. MySQL's InnoDB buffer pool uses a variant of this idea (midpoint LRU) precisely to survive scans.

Rule of thumb: allocate ~1% of cache capacity to resident HIR and keep non-resident HIR metadata for roughly 2× your LIR size. That metadata is small (just a page ID and a timestamp) but essential — without it, you can't measure IRR when a cold page returns.

The cost: LIRS needs a "stack" (LRU-ordered list of both LIR and HIR entries, including non-resident) plus a HIR queue. More bookkeeping than CLOCK, roughly comparable to ARC. Use LIRS when scan-resistance matters and your workload has a clear hot set worth protecting.