PolarDB-X Standard Edition replaces the InnoDB transaction system with Lizard, a custom engine built on a System Commit Number (SCN) model. Where InnoDB tracks visibility using an active transaction ID array shared across all readers, Lizard assigns each transaction vision a single SCN. This eliminates global structure contention, reduces snapshot propagation cost, and natively supports FlashBack queries against historical committed versions.
Limits
The database engine must be compatible with MySQL 8.0.
How it works
Relational databases use Multi-Version Concurrency Control (MVCC) to determine data visibility based on committed versions. Lizard implements MVCC through two core constructs:
SCN (System Commit Number): A number assigned at commit time that defines the order of transaction commits.
Transaction slot: A durable storage unit that retains the SCN for a committed transaction. Each modified row stores the UBA of its transaction slot rather than the SCN directly.
Write transactions
When a transaction starts, the system allocates a transaction slot and records its address as the UBA.
For each modified row, the system writes
(SCN=NULL, UBA)into the row record.At commit time, the system assigns an SCN, writes it into the transaction slot, marks the transaction as complete, and returns the commit result to the client.
Read transactions
When a query starts, the system creates a transaction vision by reading the current SCN from the SCN generator.
For each row examined, the system looks up the transaction slot via the UBA to retrieve the transaction's commit status and SCN.
The system compares the row's SCN against the vision SCN to determine whether the row version is visible.
SCN-based transaction performance
Compared with the InnoDB transaction system, the Lizard SCN model offers three advantages:
| Advantage | Detail |
|---|---|
| No global structure dependency | Visibility checks do not access a shared active transaction ID array, which significantly reduces read/write conflicts under concurrent load. |
| Compact transaction vision | A transaction vision holds a single SCN instead of an active transaction ID array, making snapshot propagation cheaper. |
| FlashBack queries | The SCN model natively supports custom FlashBack queries against historical committed versions. |
Trade-off: At commit time, only the transaction slot is updated. The SCN in each modified row record remains NULL until a cleanout occurs. Every visibility check must therefore follow the UBA to the transaction slot—an extra lookup per row.
Lizard addresses this overhead with two cleanout mechanisms.
Commit cleanout
During a write transaction, Lizard tracks a subset of the modified rows. After committing, it backfills the committed SCN into those rows. To keep commit latency low, the number of rows backfilled is capped based on the current number of records and the load capacity of the system.
Delayed cleanout
When a query reads a row whose SCN is still NULL, Lizard resolves the SCN by consulting the transaction slot via the UBA. If the transaction is already committed, Lizard writes the SCN back into the row record as a side effect. Subsequent reads of the same row skip the UBA lookup entirely.
Transaction slot reuse
Transaction slots cannot grow indefinitely. Lizard recycles them through a free list: slots are returned to the free list and new transactions draw from the free list first.
To avoid the overhead of traversing multiple data pages to find a free slot, Lizard maintains a cache table of transaction slot pages. Slot allocation reads directly from this cache, reducing the I/O cost of slot recycling.
Performance
Cleanout overhead applies only during read queries, not during hotspot contention. The following benchmark results compare the SCN transaction system against traditional InnoDB:
| System | QPS | TPS | 95th percentile latency (ms) |
|---|---|---|---|
| Lizard | 636,086.81 | 31,804.34 | 16.07 |
| MySQL 8.0.32 | 487,578.78 | 24,378.94 | 34.33 |
| MySQL 8.0.18 | 311,399.84 | 15,577.15 | 41.23 |
Test environment: Intel 8269CY 104C, 16 million rows, 512 concurrent read-write threads.
Compared to MySQL 8.0.32, Lizard delivers a 30% improvement in throughput and a 53% reduction in p95 latency.