Polar Index: Removing the Global Index Latch to Accelerate InnoDB B‑Tree SMO Operations

The previous article "InnoDB BTree latch optimization history" introduced the global index latch in InnoDB as a bottleneck that limits concurrent SMO (Structural Modification Operation) execution, especially under heavy write workloads like TPCC, where index lock contention becomes the dominant performance limiter.

Earlier explorations compared academic lock‑free structures such as blink‑tree, bw‑tree, and masstree, but MySQL's B‑Tree is tightly coupled with the transaction lock subsystem, requiring additional operations like modify_prev / search_prev and locking of non‑leaf nodes, involving undo logs and transaction modules.

PolarDB introduced the High‑Performance Polar Index, which in a real‑world online service delivered a 3× speedup and up to 11× improvement in TPCC benchmarks.

What is Polar Index and how is it implemented?

First, a brief recap of the simplified InnoDB SMO lock flow for a leaf‑page split:

Acquire SX lock on the global index latch.

Traverse from the root to level 2 without locking.

Lock the level 1 non‑leaf page with X lock.

Lock the leaf page (level 0) and its left/right siblings with X lock, perform the split.

Traverse again from the root to the leaf’s parent without locking.

Insert a pointer to the new page into the parent.

Release all locks, ending the SMO.

Two main bottlenecks appear:

The X locks on the leaf and its parent are held for the entire SMO, causing unnecessarily large lock granularity, especially problematic in cascading SMOs.

The global index‑>lock SX lock prevents multiple SMOs from running concurrently, even when they operate on disjoint pages.

How does Polar Index address these bottlenecks?

In InnoDB the global index latch is required to keep the B‑Tree traversal order strict and to guarantee atomicity of SMOs, which forces a bottom‑up locking pattern that can lead to deadlocks. Polar Index’s core idea is to split an SMO into two independent phases, allowing an intermediate state that is still valid.

Each node in Polar Index contains a link page pointer to its child page and a fence key that records the minimum key of the linked page.

During a right‑split:

Phase 1: Split the leaf page and create a link page between the original and the new leaf.

Phase 2: Add a pointer from the parent node to the newly created page.

Optional Phase 3: Remove the temporary link once the operation is fully committed.

If a crash occurs after Phase 1, recovery can detect the existing link page and safely complete Phase 2, preserving B‑Tree integrity.

Because the intermediate state is considered legal, the leaf‑to‑parent latch coupling is no longer needed, eliminating the global index latch.

After removing the index latch, Polar Index employs latch coupling: only the pages at the current B‑Tree level are locked, reducing lock granularity to a single layer.

Benefits:

Lock granularity is reduced: only the current level’s pages are X‑locked, and locks are released immediately after that level is modified, greatly improving read‑write concurrency. A high‑key (similar to Blink‑tree) on the split leaf directs readers to the new page when the key exceeds the high‑key.

The global index‑>lock is eliminated, allowing multiple SMOs to proceed in parallel. To support this, traversal is changed to lock‑coupling with at most two page locks, keeping the lock interval short for both normal reads/writes and SMOs.

Additional engineering challenges include handling overlapping pages between concurrent SMOs, avoiding deadlocks in left‑split/merge scenarios, and managing cascade deletions of left‑most records in non‑leaf pages.

Summary

InnoDB’s global index latch limits SMO concurrency, preventing performance scaling. Polar Index splits SMO into two phases, guarantees a valid intermediate state, removes the index latch, and ensures that at any moment only one B‑Tree level is locked, delivering dramatic performance improvements.

Reference Reading

Kvrocks: An Open‑Source Enterprise‑Grade Disk KV Store

Multi‑Master Paxos Implementation for Geo‑Distributed Active‑Active

Alibaba Large‑Scale Service Mesh Practice

How the Spring Festival Red‑Packet Service Handled Billion‑Level Traffic

Microservice Splitting Strategies

Original architecture practice articles are welcome via the public account’s “Contact Us” menu.