TiDB Overview: Architecture, Storage Model, and Execution Plan

TiDB is an open‑source distributed relational database that supports HTAP (Hybrid Transactional and Analytical Processing). It offers horizontal scalability, high availability, MySQL 5.7 compatibility and can be deployed on‑premises or in the cloud.

Key features include simultaneous OLTP/OLAP support, distributed architecture with financial‑grade HA, and seamless MySQL compatibility.

Architecture

TiDB consists of three main components:

TiDB Server – the stateless SQL layer that exposes the MySQL protocol, parses and optimizes queries, and forwards data requests to storage nodes.

Placement Driver (PD) – the metadata manager that stores cluster topology, assigns transaction IDs and schedules data placement using Raft.

Storage nodes – TiKV (key‑value store) and optional TiFlash (columnar store for OLAP).

TiKV stores data as ordered key‑value pairs. Data is divided into Regions (default 96 MB) identified by a left‑closed, right‑open key range [StartKey, EndKey). Regions are replicated (default three replicas) and managed via Raft.

TiKV uses RocksDB as its on‑disk engine, leveraging its high‑performance KV implementation.

Key‑Value Mapping

Each table has a global TableID and each row a RowID . The key format is:

tablePrefix{TableID}_recordPrefixSep{RowID}

Indexes also have a global IndexID . Primary/unique index keys are encoded as:

tablePrefix{TableID}_indexPrefixSep{IndexID}_indexedColumnsValue → RowID

Non‑unique index keys embed the RowID in the key and store null as the value:

tablePrefix{TableID}_indexPrefixSep{IndexID}_indexedColumnsValue_{RowID} → null

Example constants:

tablePrefix     = []byte{'t'}
recordPrefixSep = []byte{'r'}
indexPrefixSep  = []byte{'i'}

Example table and data:

CREATE TABLE User (
ID int,
Name varchar(20),
Role varchar(20),
Age int,
PRIMARY KEY (ID),
KEY idxAge (Age)
);

1, "TiDB", "SQL Layer", 10
2, "TiKV", "KV Engine", 20
3, "PD", "Manager", 30
4, "TiFLASH", "STORAGE", 30

Resulting KV pairs (TableID = 10, IndexID = 1):

t10_r1 → ["TiDB","SQL Layer",10]
t10_r2 → ["TiKV","KV Engine",20]
t10_r3 → ["PD","Manager",30]
t10_r4 → ["TiFLASH","STORAGE",30]

t10_i1_10_1 → null
t10_i1_20_2 → null
t10_i1_30_3 → null
t10_i1_30_4 → null

Execution Plan

TiDB’s execution plan consists of operators such as TableFullScan, TableRangeScan, IndexFullScan, IndexRangeScan, TableReader, IndexReader, IndexLookUp, IndexMerge, Limit, and TableRowIDScan. Operators are organized as a tree; Build operators (e.g., IndexFullScan) run before Probe operators (e.g., TableRowIDScan).

Tasks are divided into Cop tasks (executed in TiKV’s coprocessor) and Root tasks (executed in TiDB). Most SQL functions, LIMIT, and index scans can be pushed down to Cop tasks, while joins remain Root tasks.

Operator info fields (e.g., range , keep order , stats ) provide details about predicate push‑down, ordering requirements, and statistics usage.

Optimizer hints (e.g., /*+ HASH_JOIN(t1, t2) */ ) can force specific physical algorithms.

Range Queries

TiDB can use indexes when predicates are “sargable”. Equality or range predicates on indexed columns are pushable; functions like YEAR(date_column) < 1992 are not.

Combining predicates with AND (intersection) or OR (union) works for multi‑column indexes.

Conclusion

TiDB combines OLTP and OLAP capabilities in a cloud‑native, MySQL‑compatible distributed database. Its architecture, storage model, and execution engine provide a rich foundation for scalable, high‑availability workloads.