多層分頁表（multilevel page table）
想像你得替一棟有十億個可能房號、但實際只存在幾千間房的大樓維護目錄。寫出十億列——其中絕大多數寫著「空」——是荒謬的。你改成保留一份精簡的頂層「街區」索引，只有對那些含有真實房間的街區，才費心建立詳細的子目錄。多層分頁表（multilevel page table）對轉換來說正是這種巢狀、只在需要處才建的結構。
具體來說，虛擬分頁號被切成數個欄位，每一層一個。第一個欄位索引一張頂層表，其項目指向一張第二層表；下一個欄位索引那張表；如此類推，直到最後一層給出實體頁框。關鍵是：子表只為位址空間中真正用到的區域而建立——一段沒用到的分支，在上一層只是一個空項目，而不是一整張全是空的大表。於是一個 64 位元位址空間（其平坦分頁表會大到天文數字）能被緊湊地表示，因為它絕大部分從不被對應。真實機器使用三層、四層或五層。
為何重要：多層分頁表是虛擬記憶體得以擴展到龐大位址空間、而不必把全部 RAM 都花在分頁表本身的辦法——它以空間換時間。誠實的代價正是那份時間：一次 TLB 未命中現在需要一次分頁表走訪，每一層碰一次記憶體（四層意味著轉換一個位址最多多四次記憶體存取）。這正是為何 TLB 如此重要，也是為何某些系統會快取中間走訪步驟、或使用較大分頁來縮短走訪。稀疏的位址空間是好處；TLB 未命中時的深層走訪是代價。
一個兩層方案把 32 位元的虛擬分頁號（在 4 KiB 分頁下）切成 10 位元的頂層索引與 10 位元的第二層索引。一個只用到幾頁的行程，只需要頂層表加上實際涵蓋其使用區域的那一兩張第二層表。
只有涵蓋使用區域的子表存在；那片空曠的廣大幾乎不花成本。
層數是空間與時間的取捨：更多層能緊湊地處理龐大稀疏的空間，卻在 TLB 未命中時拉長走訪。反轉分頁表採取相反路線——每個實體頁框一項——以另一種方式約束表的大小。