Feature List
Feature |
Sub-feature |
Feature Description |
Constraint |
Application Scenario |
Performance Metric |
Supported on VMs |
Remarks |
Feature Guide |
|---|---|---|---|---|---|---|---|---|
System Collaborative Optimization |
The SSD atomic write feature eliminates the doublewrite redundancy to improve database performance. |
|
OLTP write scenarios |
The performance is expected to improve by 15% in write-intensive scenarios. |
No |
This feature depends on the SSD hardware feature and is not suitable for virtualization scenarios. |
||
This feature provides continuous optimization for multi-modal objects (source code, assembly code, and binary) in more lifecycle phases (compile time, link time, and post-link time), to generate target programs with better performance. |
|
OLTP read and write scenarios |
This feature can improve the overall database performance in TPC-C tests by 10% when all CPUs of a server are used and that in sysbench tests by 30% (based on optimal results) in VMs (8 vCPUs, 32 GB memory specifications). |
Yes |
This software feature can be used on both VMs and physical machines. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
|||
Network Multipathing and Domain-based Scheduling Optimization |
This feature identifies the traffic characteristics of specific service processes and implements the affinity between service process network requests and network interrupts. |
|
OLTP read and write scenarios |
In the scenario where a MySQL container occupies half of the resources of a machine (8 vCPUs and 32 GB memory), the overall (optimal) performance is improved by 10% in sysbench tests. For a Redis container using 2 vCPUs and 10 GB memory, the comprehensive performance in redis-benchmark is improved by 80% in the IPVLAN+bond4 networking. |
No |
This feature depends on the NIC driver interface, which is not supported by virtual NICs. |
||
This feature introduces the shadow FD mechanism and cross-thread asynchronous communication mechanism. It accelerates the network protocol stack to improve database performance. |
|
OLTP read and write scenarios |
The TPC-C comprehensive performance is expected to improve by 10%. |
Yes |
This software feature can be used on both VMs and physical machines. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
|||
Without modifying application-side TCP usage, this feature establishes a fast-forwarding context for connections matching a specified port or listening process, and selects a shorter redirection path in the subsequent data path. |
|
OLTP read and write scenarios |
In scenarios with 16 MySQL instances on an 8-vCPU, 32-GB configuration, the best-case overall sysbench performance improves by approximately 2%. In scenarios with 4 Redis instances on a 2-vCPU, 10-GB configuration, peak redis-benchmark performance improves by 18% for GET and 34% for SET. |
Yes |
This software feature can be used on both VMs and physical machines. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
|||
MySQL Acceleration Kit — Basic Computation Optimization |
Kunpeng CRC32 hardware instructions are used to replace the software implementation of the CRC32 algorithm, thereby improving system performance. |
|
OLTP write scenarios |
The MySQL performance is expected to improve by 5% in sysbench write scenarios. The performance of RocksDB 6.1.2 is expected to improve by 5%. |
Yes |
This feature depends on the CRC32 hardware instruction feature and is not suitable for virtualization scenarios. |
||
In high-concurrency MySQL OLTP applications, the default thread scheduling of the system causes frequent cross-NUMA access of threads. In this case, the CPU overhead increases and the performance deteriorates. Therefore, the foreground threads need to be dynamically bound to fixed NUMA CPUs to reduce cross-NUMA access and ensure that the CPU access load is balanced. Background threads need to be statically bound to fixed NUMA CPUs to reduce cross-NUMA access and improve background thread efficiency. |
|
OLTP read and write scenarios |
The performance is improved by 10% in OLTP scenarios. |
Yes |
This software feature can be used on both VMs and physical machines. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
|||
In utf8/utf8mb4 character set processing, SIMD-based parallel processing is implemented for ASCII characters to improve the processing throughput. |
|
OLTP read scenarios |
The sysbench read-only tests show that the performance of Percona-Server 5.7.44-53 running on a container with 8 vCPU and 16 GB memory can be improved by about 10%. |
Yes |
This feature can be used on VMs. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
SIMD-based MySQL Character Set Processing Optimization Feature Guide |
||
This feature replaces field-by-field traversal-based matching with whole-record comparison using memcmp, improving comparison efficiency. |
|
OLTP read scenarios |
The sysbench read-only tests show that the performance of Percona-Server 5.7.44-53 running on a container with 8 vCPU and 16 GB memory can be improved by about 2%. |
Yes |
This feature can be used on VMs. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
|||
The new Kunpeng 920 processor model supports unaligned memory access. The unaligned memory access optimization policies implemented on the x86 architecture are migrated to the Arm architecture. |
|
OLTP read scenarios |
The sysbench read-only tests show that the performance of Percona-Server 5.7.44-53 running on a container with 8 vCPU and 16 GB memory can be improved by about 2%. |
Yes |
This feature can be used on VMs. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
|||
This feature introduces LSE hardware-based acceleration to alleviate performance deterioration under high concurrency and improve the overall performance and system stability of MySQL on Kunpeng servers. |
|
OLTP read and write scenarios |
The sysbench tests with 256 concurrent threads show that the overall performance of Percona-Server 5.7.44-53 running on a container with 8 vCPUs and 16 GB memory can be improved by 5%. |
Yes |
This feature depends on LSE hardware-based acceleration and is not suitable for virtualization scenarios. |
|||
This feature allows the row format check to be performed before rec_get_offsets calls, and passes the result as a parameter to the rec_get_offsets_with_comp function. This reduces repeated queries within rec_get_offsets. |
|
OLTP read and write scenarios |
The sysbench tests show that the overall performance of Percona-Server 5.7.44-53 running on a container with 8 vCPU and 16 GB memory can be improved by about 2%. |
Yes |
This feature can be used on VMs. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
|||
This feature uses the Kunpeng hardware acceleration module to implement compression and decompression algorithms and works with a lossless userspace driver framework to improve query performance. |
OLAP |
The OLAP query performance can be improved by 10% in heavy I/O scenarios where only one request is processed at a time. |
Yes |
This feature can be used on VMs. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
||||
MySQL KAEZstd page compression and decompression optimization |
The feature uses the Kunpeng hardware acceleration module to accelerate the zstd-related compression and decompression algorithms, improving the performance of transparent page compression. |
|
Read scenarios |
Around half of the drive space can be saved; the TPS in sysbench tests drops by no more than 15% with a container configuration of 8 vCPUs and 32 GB memory. |
Yes |
This feature can be used on VMs. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
MySQL KAEZstd Page Compression and Decompression Optimization Feature Guide |
|
Optimized SQL statements with the same syntax reuse an execution plan in a session to reduce the optimizer overhead and improve the system query performance. |
|
OLTP read scenarios |
The sysbench read-only tests show that the feature can improve the performance of Percona-Server 8.0.43-34 running on a container with 8 vCPU and 16 GB memory by 10%. |
Yes |
This feature can be used on VMs. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
|||
MySQL Acceleration Kit — Binlog Acceleration Optimization |
The size of binlog files when being created is pre-allocated as max_binlog_size. This prevents metadata operations caused by dynamic file size growth during writes, thereby reducing I/O overhead and improving system performance. |
|
OLTP write scenarios |
The sysbench write-only tests show that the feature can improve the performance of Percona-Server 5.7.44-53 running on a container with 8 vCPU and 16 GB memory by 2%. |
Yes |
This feature can be used on VMs. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
||
Locks are split so that followers in different phases wait for different locks, reducing the possibility of false wakeups between different groups. This reduces the system overhead associated with pthread_cond_wait/pthread_cond_broadcast calls and alleviates lock conflicts. |
|
OLTP write scenarios |
The sysbench write-only tests show that the feature can improve the performance of Percona-Server 5.7.44-53 running on a container with 8 vCPU and 16 GB memory by 5%. |
Yes |
This feature can be used on VMs. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
|||
The std::map used by m_writeset_history is replaced with the hash map data structure to reduce the time complexity of insertion and search to O(1), improving efficiency. |
|
OLTP write scenarios |
The sysbench write-only tests show that the feature can improve the performance of Percona-Server 5.7.44-53 running on a container with 8 vCPU and 16 GB memory by 5%. |
Yes |
This feature can be used on VMs. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
MySQL Binlog writeset_history Data Structure Optimization Feature Guide |
||
MySQL Acceleration Kit — Lock and Atomic Variable Optimization |
In MySQL OLTP applications, a large number of DML statements (INSERT, UPDATE, and DELETE) are concurrently executed on the key data structures in the lock_sys->mutex global lock, causing severe lock contention and performance deterioration. The original lock is replaced with fine-grained hash bucket locks to prevent lock conflicts and improve concurrency. |
|
Read and write scenarios |
The TPC-C comprehensive performance is expected to improve by 5%. |
Yes |
Though this software feature can be used on both VMs and physical machines, it is mainly designed to alleviate lock contention when many DML statements are concurrently executed in OLTP scenarios. This rarely happens on VMs. Therefore, the actual performance improvement result is subject to the VM specifications. |
||
In MySQL OLTP applications, a large number of DML statements (INSERT, UPDATE, and DELETE) are concurrently executed on key data structures in the trx_sys global structure, causing resource competition and synchronization bottlenecks in the critical section. After the reconstruction, the lock-free hash table is used to maintain transaction units, preventing lock conflicts and improving concurrency. |
|
Write scenarios |
The performance is improved by 20% in sysbench write scenarios. |
Yes |
Though this software feature can be used on both VMs and physical machines, it is mainly designed to alleviate lock contention when many DML statements are concurrently executed in OLTP scenarios. This rarely happens on VMs. Therefore, the actual performance improvement result is subject to the VM specifications. |
|||
In read/write mixed scenarios, the MVCC frequently creates, closes, and reuses ReadView. This feature adds a version tracking mechanism to ReadView. When the transaction system status that affects the view content changes, the version information is updated synchronously. In this way, when ReadView is opened again, the system can determine whether the existing view is still valid based on the version. If the status corresponding to the view does not change, the existing view is directly reused, and no additional removal, rebuilding, or locking operation is required. |
|
Write scenarios |
The performance is improved by 5% in sysbench high-concurrency write scenarios. |
Yes |
This software feature can be used on both VMs and physical machines. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
|||
In MySQL OLTP scenarios with high-concurrency read/write operations, the table lock queue check in the InnoDB transaction system is likely to become a hotspot, causing high overhead of linked list scanning. This feature adds a more direct status check mechanism to the table lock queue, so that the system can first determine whether there are any table lock types in the queue that conflict with the intent lock. For scenarios where LOCK_S or LOCK_X does not exist, unnecessary queue traversal can be skipped, allowing the compatibility check to be completed directly. |
|
Write scenarios |
The performance is improved by 5% in sysbench high-concurrency write scenarios. |
Yes |
This software feature can be used on both VMs and physical machines. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
|||
MySQL Acceleration Kit — Pluggable Thread Pool |
In high-concurrency MySQL OLTP applications, there are many threads, and the CPU is consumed by resource contention and frequent switchovers. By enabling the thread pool, all tasks are queued for execution based on the system execution capability. The number of tasks processed by each CPU at a time is limited (2 to 5 for the best), which is to ensure stable service processing capabilities. |
|
Read and write scenarios |
In the OLTP TPC-C scenario, before enabling the thread pool, the MySQL performance of running 10,000 concurrent tasks is only about 10% of the optimal. After the thread pool is enabled, the performance is maintained at 85%. |
Yes |
This software feature can be used on both VMs and physical machines. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
||
MySQL Acceleration Kit — AP Enhancement |
This feature adopts a parallel processing mechanism. Each operator contains multiple worker threads, which significantly shortens the execution time of SQL statements. The columnstore structure improves data processing efficiency, and a secondary execution engine is provided as a plugin which is pluggable and can be dynamically loaded. |
|
OLAP |
The OLAP query performance is improved by more than three times. |
Yes |
This software feature can be used on both VMs and physical machines. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
MySQL Pluggable Online Vectorized Analysis Engine Feature Guide |
|
Only one thread can be scheduled for a single SQL query in the MySQL database, and the multi-core CPU cannot be used. The performance of a single query is poor and cannot meet the performance requirements in query scenarios. To address this, parallel query is used to improve the query performance. |
|
OLAP |
The query performance is more than doubled. (The performance improvement result is related to the degree of parallelism.) |
Yes |
This software feature can be used on both VMs and physical machines. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
|||
Redis Acceleration Kit |
This feature enhances performance by offloading network I/O operations to KRAIO for asynchronous batch processing. This reduces system calls and context switching, enabling non-blocking Redis operations. |
|
Read and write scenarios |
In the Docker+bond4+IPVLAN networking with 2 vCPUs and 10 GB memory, the redis-benchmark performance is 20% higher than that of the open-source Redis. |
Yes |
This feature can be used on VMs. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
||
This feature uses technologies such as eBPF and shared memory to reduce the overhead of TCP packet encapsulation and decapsulation and data copying, thereby improving the Redis performance in local communication scenarios. |
|
Read and write scenarios |
Under a configuration of 2 vCPUs and 10 GB memory in local network communication scenarios, the Redis performance is improved by 5% to 50% in redis-benchmark testing. |
Yes |
This feature can be used on VMs. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
|||
In Redis 7.0.15, ZRANGE requires floating-point calculation. This feature switches Redis 7.0.15's floating-point printing algorithm from glibc's dragon4 to grisu2, replacing bignum arithmetic operations with ordinary division and table lookup for improved performance. |
|
ZRANGE scenarios (Redis sorted set read command) |
The performance for ZRANGE in a single-instance NUMA-pinned physical environment is improved by more than 100%. |
Yes |
This feature can be used on VMs. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
|||
With the Arm-based Top Byte Ignore (TBI) feature enabled, the CPU ignores the most significant byte (bits[63:56]) of a 64-bit virtual address during address translation, and uses only the lower bits for addressing. This allows the upper eight bits of a pointer to be used by user software for storing additional information without affecting the actual memory access. |
|
RPUSH scenarios (Redis list write command) |
The RPUSH throughput is improved by 5% in a 2-core 2-thread (2C2T) container. |
Yes |
This feature can be used on VMs. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
|||
RocksDB Acceleration Kit |
This feature introduces the CRC32 hardware implementation and SVE2 assembly implementation. |
|
Read and write scenarios |
With a container configuration of 16 vCPUs, the performance on YCSB workloads A and C is improved by 5% on average. |
Yes |
This feature can be used on VMs. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
||
The accuracy of the Bloom filter is improved so that it can more accurately identify hot data. |
|
Read and write scenarios |
Yes |
This feature can be used on VMs. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
||||
The page size of the openEuler OS kernel is changed to 64 KB. |
|
Read and write scenarios |
With a container configuration of 16 vCPUs, the performance on YCSB workloads A and C is improved by 5% on average. |
Yes |
This feature can be used on VMs. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
|||
This feature strategically binds NIC queue interrupts to CPUs across different NUMA nodes. By analyzing traffic patterns of specific service processes, it ensures that network traffic of each process is preferentially handled by NIC queues on its local NUMA node, thereby establishing affinity between service processes and their network interrupts. |
|
Read and write scenarios |
Two instances are allocated to each NUMA node on a server with half CPUs being used. A total of eight instances are allocated, and each instance is bound to 16 vCPUs. In YCSB workload A and workload C scenarios, the average QPS increases by 5% and the average latency decreases by 10%. |
No |
This feature depends on the NIC driver interface, which is not supported by virtual NICs. |
|||
This feature leverages SVE2's parallel computation capabilities to process hash probe positions in batches instead of generating and checking them one by one. This reduces redundant computation and data accesses, and lowers the CPU overhead of a single filter lookup. |
|
Read and write scenarios |
Combined with the CRC32 instruction optimization feature, this feature improves the average stress test performance on YCSB workloads A to F by 10% under a 16-vCPU configuration. |
Yes |
This feature can be used on VMs. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
|||
This feature issues cache prefetch instructions before the data is actually used, overlapping memory accesses with computation phases such as key comparison and restart-point binary search, thereby reducing stalls caused by cache misses. |
|
Read and write scenarios |
Yes |
This feature can be used on VMs. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
||||
This feature maintains stable prefix rules across different SST files and determines at query time whether the current configuration can safely use HashSearch. When the configuration matches, it narrows the candidate data block range; when it does not, it automatically falls back to regular binary search, avoiding missed lookups caused by incorrectly narrowing the range. |
|
Read and write scenarios |
Yes |
This feature can be used on VMs. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
||||
The traditional LSM-Tree design mainly targets high-throughput write operations, but suffers from low read efficiency, especially for range queries. This feature introduces a new strategy that dynamically adjusts the capacity ratio between adjacent levels to increase the capacity of deeper levels, thereby reducing the number of I/O operations required by queries. |
|
Read and write scenarios |
Yes |
This feature can be used on VMs. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
RocksDB 6.26.1 Dynamic Level Capacity Optimization Feature Guide |
|||
Milvus Acceleration Kit |
The KScaNN algorithm in the Kunpeng recall algorithm library is supported to improve the query efficiency of vector retrieval algorithms. |
Read scenarios |
When the recall rate of the KScaNN algorithms is higher than 0.95, the QPS performance is 30% higher than that of the ScaNN algorithm. |
Yes |
This feature can be used on VMs. This software feature can be used on both VMs and physical machines. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
|||
The KBest algorithm in the Kunpeng recall algorithm library is supported to improve the query efficiency of graph algorithms. |
Read scenarios |
When the recall rate of the KBest algorithms is higher than 0.99, the QPS performance is 30% higher than that of the HNSW algorithm. |
Yes |
This feature can be used on VMs. This software feature can be used on both VMs and physical machines. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |
||||
This feature applies vector instructions and prefetch operations to improve the similarity query performance. |
Read scenarios |
When the recall rate of the HNSW algorithm reaches 0.99 and that of the ScaNN algorithm reaches 0.95, the QPS performance on the GIST dataset can be improved by 20%. |
Yes |
This feature can be used on VMs. The performance metrics are related to the test environment specifications so that the actual performance improvement result is subject to the VM specifications. |