Write-heavy, high-concurrency workloads on PolarDB for MySQL can hit throughput ceilings caused by InnoDB's B-tree index locking behavior. B-tree concurrency control optimization removes the index-level serialization bottleneck, letting all operations run in parallel with lock contention contained at the page level.
How it works
InnoDB organizes table data in a clustered index and uses B-tree index structures for both primary and secondary indexes. Each physical page (B-tree node) has a read/write lock. When a thread performs a structure modification operation (SMO) — an operation that changes multiple physical pages at once, such as a node split or merge — InnoDB must hold locks across all affected nodes to prevent inconsistency.
This locking behavior creates two bottlenecks under high concurrency:
Single SMO at a time: Only one SMO can run at a time. The index lock serializes all structural changes, which limits throughput.
Wide lock scope: To avoid deadlocks, optimistic operations hold shared (S) locks on every node along the traversal path, and pessimistic operations hold exclusive (X) locks on every node that may change. More concurrent threads means more lock contention, concentrated on the busiest nodes.
PolarDB for MySQL addresses both bottlenecks:
Concurrent SMOs: All operations can access the B-tree index simultaneously. Thread conflicts are contained at the page level rather than the index level.
Latch coupling: All operations use latch coupling to hold only one page lock at a time, reducing both the number of locks held and the duration of contention.
Prerequisites
Before enabling this optimization, confirm that your cluster meets all of the following conditions:
Edition: Enterprise Edition or Standard Edition
Engine version: MySQL 8.0.1 (revision 8.0.1.1.28 or later) or MySQL 8.0.2 (revision 8.0.2.2.17 or later)
Adaptive hash index:
innodb_adaptive_hash_indexmust be set to OFFIndex type: Only B-tree primary and secondary indexes are supported. Full-text indexes and spatial indexes are not supported.
To check your engine version, see Query an engine version.
Enable B-tree concurrency control optimization
Enabling or disabling this optimization automatically restarts the cluster. Services may be interrupted for up to one minute. The recovery time varies based on data volume and number of tables. Perform this change during off-peak hours and make sure your application reconnects to the database automatically.
Log on to the PolarDB console.
Set
loose_innodb_polar_blink_treeto ON. For instructions on setting parameter values, see Specify cluster and node parameters.
The following table describes the parameter:
| Parameter | Level | Description |
|---|---|---|
loose_innodb_polar_blink_tree | Global | Enables or disables B-tree concurrency control optimization. Valid values: OFF (default) and ON. |
Performance considerations
The benefit depends on your concurrency level and workload pattern:
Write-heavy, high-concurrency workloads (many threads competing on the same indexes) see the largest gains.
Moderate-concurrency or read-heavy workloads see a smaller benefit, since the index-level lock is rarely the limiting factor.
Based on TPC-C benchmarks at 1,000 warehouses:
Without optimization: Peak performance at 128 concurrent threads.
With optimization: Peak performance at 256 concurrent threads — a 140% improvement in read and write throughput compared to the unoptimized baseline.
