Overview of Tencent's TXSQL: Custom MySQL Kernel Enhancements, Performance Optimizations, and Feature Additions

Introduction

TXSQL is the customized MySQL kernel used in Tencent Cloud's largest MySQL service, CDB, offering full‑stack operational solutions such as backup, monitoring, and rapid scaling, while delivering higher performance and stability than the upstream Oracle MySQL Enterprise edition.

What is TXSQL and Why It Exists?

TXSQL is a deep‑fork of the MySQL source code created by the TEG Infrastructure CDB team to meet both internal Tencent business needs and external cloud customers ranging from a few gigabytes to hundreds of terabytes, focusing on performance, functional extensions, resource management, diagnostics, bug fixing, and data security.

Key Work Items

Database performance tuning

Kernel deep modifications for workload stability

Implementation of business‑required features

Resource‑management support

Diagnostic tools for DBAs

Kernel bug identification and fixes

Ensuring data security

What TXSQL Has Done

Version Selection

TXSQL 5.6 is based on MySQL 5.6.28 because it was the most stable 5.6 release at the time, widely adopted by users, and avoided serious bugs present in early 5.7 releases.

Performance Improvements

Read‑view optimization : Maintains a global ordered transaction‑ID set and a per‑transaction cached read‑view to reduce mutex contention, removes the redundant ro_trx_list from 5.6, and adjusts the read‑view array size dynamically.

Redo‑log group commit : Collects the largest redo LSN from all engines and forces smaller redo logs to flush early, reducing log_sys‑>mutex contention during commit.

Redo‑log double buffering : Introduces a second buffer and a w_mutex so that flushing can release log_sys‑>mutex , improving concurrency.

Adaptive hash index (AHI) lock splitting : Implements a global ordered transaction ID set and a separate index‑lock protocol (WL#6326) similar to MySQL 5.7, providing faster leaf‑node lookup while allowing the index to be disabled when it harms performance.

int cdb_lock(string key, int type, uint64_t wait_timeout, uint64_t timeout);

The API supports shared (read) and exclusive (write) locks, automatic timeout release, and is independent of the client connection.

Feature Additions

Multiple operation modes : Read‑only, read‑write, and unavailable modes to meet different service scenarios, including cross‑region disaster‑recovery requirements.

ALTER TABLE … NOWAIT : Introduces Oracle‑style timeout for DDL to avoid long‑running lock contention.

Lock system extensions : Provides a lease‑based distributed lock (cdb_lock / cdb_unlock) that survives connection loss, enabling distributed transactions.

Strong Synchronization Based on Semi‑Sync

Improvements include an ACK thread for parallel send/receive, replacing select with poll to avoid FD limits, and a hold‑until‑ACK mechanism that turns semi‑sync into strong sync.

Stability Improvements and Testing

Addresses memory‑allocator jitter, thread‑contention, buffer‑pool flushing bottlenecks, and various kernel bugs (redo‑log deadlock, charset issues, normal shutdown). Each patch is accompanied by test cases, coverage checks, regression, performance, and stress testing before gray‑release.

Financial Business Support

Implements strong consistency for financial workloads by preventing kills during ACK wait, adding lease‑based HA, cross‑region lock leasing, and splitting Lock_log to reduce deadlocks.

Version Performance

Three released versions (TXSQL_20160730, TXSQL_20160902, TXSQL_20161130) show progressive bug fixes and performance gains. Benchmarks against MySQL 5.6.28, 5.6.35, and 5.7.17 using sysbench (select.lua, update_index.lua, oltp.lua) demonstrate higher throughput and stability.

About TXSQL 5.7

Support for MySQL 5.7 is planned, including index‑lock splitting, Group Replication strong sync, JSON data type, virtual columns, query rewrite, sys schema monitoring, and other 5.7 features.

Future Development Direction

TXSQL will continue to add business‑driven features (audit, firewall), further performance tuning (hot‑spot updates, multi‑statement commits), improve kernel resilience to bad SQL and index anomalies, strengthen open‑source collaboration, and enhance operational tooling.

Recruitment Notice

The article concludes with an invitation for developers interested in database kernel development to apply via [email protected].