Database / TiDB Interview questions

TiDB is an open-source distributed SQL database from PingCAP. It speaks the MySQL protocol, scales out horizontally and keeps data strongly consistent through Raft replication, so you get a familiar MySQL interface without hand-managing shards.

Compute and storage are separate. Stateless TiDB servers parse and plan SQL, while TiKV (row store) and TiFlash (column store) hold the data. The PD cluster keeps metadata and hands out timestamps.

Because one system serves both transactional and analytical queries, it is also described as an HTAP database. Common uses are OLTP workloads that outgrew a single MySQL, real-time analytics on live data, and merging many MySQL shards into one cluster.

A TiDB cluster has four core components, each with a separate job.

TiFlash is optional. Around the core sit tools such as TiUP, TiCDC, TiDB Lightning, BR and TiDB Dashboard.

flowchart LR
A["MySQL client"] --> B["TiDB server"]
B --> C[TiKV]
B --> D[TiFlash]
B --> E[PD]
C --- E

TiKV is the distributed, transactional key-value store that holds the row data of a TiDB cluster. It is written in Rust and is also a CNCF graduated project.

Each TiKV node runs RocksDB instances to persist data on disk. Keys are split into Regions, and every Region is replicated (three copies by default) using the Raft protocol, which gives high availability and strong consistency.

TiKV also implements MVCC for snapshot reads and the Percolator-style transaction protocol. A coprocessor lets it run filters and aggregations next to the data, so less data travels to the TiDB server.

PD (Placement Driver) is the metadata and scheduling brain of the cluster. It does three main things.

1. Stores cluster metadata: which Region lives on which TiKV store and who the Region leader is.
2. Allocates timestamps: it is the TSO (timestamp oracle) that gives every transaction a globally increasing start and commit timestamp.
3. Schedules data: it balances Region leaders and replicas, and repairs replicas when a store goes down.

PD embeds etcd and runs as a Raft group, so production clusters use at least three PD nodes. Only the PD leader serves TSO requests.

TiFlash is the columnar storage engine of TiDB, built for analytical queries. It keeps a column-oriented copy of tables that you choose to replicate from TiKV.

The copy is fed through Raft as a learner replica. It receives logs asynchronously and does not vote, so TiFlash never slows down OLTP writes. Reads still return consistent data because TiFlash confirms with the Region leader that it has caught up before answering.

The optimizer decides per query whether TiKV or TiFlash is cheaper, and large scans, aggregations and joins can run in distributed MPP mode across TiFlash nodes.

HTAP stands for Hybrid Transactional and Analytical Processing. In TiDB it means the same cluster can serve OLTP queries and real-time analytics, without an ETL pipeline into a separate warehouse.

It works through two storage engines holding the same data: TiKV (rows) for transactions and TiFlash (columns) for analytics. Raft learner replication keeps TiFlash fresh, and the optimizer picks the engine per query, or even per table inside one query.

Workload isolation comes from running each engine on separate nodes, so heavy reports do not steal CPU from OLTP.

Largely yes. TiDB is compatible with the MySQL protocol and with most MySQL 5.7 and 8.0 syntax, so existing drivers, ORMs and tools such as Navicat, MySQL Workbench or the mysql CLI work unchanged. Connect on port 4000 instead of 3306.

Compatibility is not total. Stored procedures, triggers, events and some storage-engine specific features are not supported, and behaviour differs in places, for example auto-increment ordering and the default isolation implementation.

Check the running version with:

SELECT tidb_version();

Always test your application against TiDB before migrating, since the supported feature list changes between releases.

A Region is the basic unit of data distribution and replication in TiKV. It is a contiguous range of the sorted key space, for example all keys from t10_r1 to t10_r5000.

By default a Region is about 96 MiB and is split once it grows beyond roughly 144 MiB. Each Region is replicated three times and the copies form a Raft group with one leader that serves reads and writes.

PD moves Regions and their leaders between TiKV stores to balance load. Because data moves in small Region-sized pieces, scaling out needs no manual resharding.

The features interviewers expect you to name:

• Horizontal scalability: add TiDB or TiKV nodes online, no resharding.
• MySQL compatibility: same protocol and mostly the same SQL.
• Strong consistency and HA: Raft replicas with automatic failover and no data loss when a minority of replicas fail.
• Distributed ACID transactions across rows, tables and nodes.
• HTAP through TiKV and TiFlash.
• Cloud-native design: separated compute and storage, Kubernetes operator, managed TiDB Cloud.
• Open source under Apache 2.0.

TiUP is the package manager and cluster management tool for TiDB. It installs components, deploys clusters and runs day-two operations from one CLI.

Two modes are used most often. tiup playground starts a throwaway local cluster for learning, and tiup cluster manages real multi-host deployments from a YAML topology file.

tiup playground
tiup cluster deploy prod-tidb v8.5.0 topology.yaml --user tidb
tiup cluster start prod-tidb
tiup cluster display prod-tidb
tiup cluster scale-out prod-tidb scale.yaml
tiup cluster upgrade prod-tidb v8.5.1

It also handles rolling upgrades, scale-in, configuration changes and launching tools such as BR and Dumpling.

Knowing the default ports helps with firewall rules and troubleshooting.

All ports are configurable in the TiUP topology file. Open 4000 to application servers only, keep 2379, 2380 and 20160 restricted to cluster hosts, and expose 10080, 9090 and 3000 just to your monitoring and admin network.

TiDB Dashboard is the built-in web UI for monitoring and diagnosing a cluster. It ships inside PD, so you open it at http://<pd-host>:2379/dashboard with a TiDB SQL user.

Key pages include:

• Key Visualizer: heatmap of read and write traffic by key range, used to spot hotspots.
• SQL Statements and Slow Queries: top statements by latency and the slow query log.
• Top SQL: CPU consumption per SQL over time.
• Continuous Profiling, cluster diagnostics, and log search.

TiDB Cloud is PingCAP's fully managed Database-as-a-Service for TiDB, available on AWS and Google Cloud, with Azure support on some tiers. PingCAP runs provisioning, upgrades, backups and monitoring for you.

It has two main flavours. The serverless tier (now branded Starter or Essential, plan names have changed over time) autoscales and bills by usage, which suits small apps and development. Dedicated gives you an isolated cluster with chosen node sizes, VPC peering and TiFlash for production.

It is the quickest way to try TiDB without managing infrastructure. Check the console for the current plan names.

TiCDC (Change Data Capture) streams row-level changes from a TiDB cluster to other systems. It pulls changes from TiKV, orders them, and pushes them to a downstream sink through a changefeed.

Supported sinks include MySQL-compatible databases, Kafka, Pulsar, and cloud storage such as S3. Typical uses are disaster recovery with a standby cluster, feeding event streams to downstream services, and syncing to a data warehouse.

tiup cdc cli changefeed create   --server=http://127.0.0.1:8300   --sink-uri="mysql://root:pwd@10.0.0.5:3306/"   --changefeed-id="dr-sync"

TiDB Lightning is a high-speed data import tool for loading large datasets, such as Dumpling exports or Parquet files, into TiDB.

It has two modes:

• Physical import mode: encodes data into sorted key-value pairs and ingests SST files straight into TiKV. It is the fastest option, but the target tables should be empty and are not available for writes during the import.
• Logical import mode: executes INSERT statements. It is slower, but the cluster stays online and tables can be non-empty.

From v7.2 the SQL statement IMPORT INTO offers a simpler way to do similar imports without a separate tool.

Dumpling is a logical export tool that writes data from TiDB or MySQL into SQL or CSV files. It is the TiDB counterpart of mysqldump and mydumper, but multi-threaded and able to split big tables into chunks.

It takes a consistent snapshot using TiDB's snapshot reads, so the export does not need to lock tables. Output can go to local disk or S3-compatible storage.

tiup dumpling -h 127.0.0.1 -P 4000 -u root   -t 8 -F 256MiB -o /data/dump

Dumpling pairs naturally with Lightning for import and with DM for MySQL migrations.

TiDB Data Migration (DM) migrates and continuously replicates data from MySQL-compatible databases (MySQL, MariaDB, Aurora) into TiDB.

A DM task usually runs three phases: full export of existing data, import into TiDB, and incremental replication by reading the upstream binlog. This lets you cut over with little downtime.

Its standout feature is shard merging: tables from many upstream MySQL instances or schemas can be merged into one TiDB table, with DDL coordination across shards. It is operated with dmctl, backed by dm-master and dm-worker nodes.

TiDB covers most everyday MySQL SQL, but some features are missing or limited:

• Stored procedures, triggers and events
• User-defined functions
• FULLTEXT and SPATIAL indexes
• XA transactions and some storage-engine specific syntax such as CREATE TABLE ... ENGINE= behaviour (the clause is accepted but ignored)
• Foreign keys, which arrived as experimental in v6.6 and have been maturing since

The list shrinks with every release, so confirm against the compatibility page for your exact version before a migration.

Use any MySQL client or driver and point it at a TiDB server on port 4000.

mysql -h 10.0.0.11 -P 4000 -u root -p

For Java the JDBC URL looks like jdbc:mysql://10.0.0.11:4000/shop. Python, Go, Node.js and ORMs such as Hibernate or SQLAlchemy work the same way.

Because TiDB servers are stateless, production setups put a load balancer such as HAProxy, LVS or TiProxy in front of several of them. Clients connect to the balancer's address, and a failed TiDB node simply drops out of rotation. Enable TLS for anything leaving a private network.

TiDB supports Read Committed and Repeatable Read. The default is Repeatable Read, but TiDB implements it as Snapshot Isolation (SI): each transaction reads a snapshot taken at its start timestamp.

Read Committed is available only with pessimistic transactions. SERIALIZABLE is not supported, so use SELECT ... FOR UPDATE when you need to guard against write skew.

TiDB maps relational data to ordered key-value pairs, so TiKV only needs to store keys and values.

The rowID is the integer primary key when the table uses a clustered integer key, otherwise TiDB generates a hidden _tidb_rowid.

Keys are sorted, so rows of one table sit side by side and range scans stay sequential. The whole key space is then cut into Regions and spread across stores.

TiDB scales each layer on its own.

Compute: add more stateless TiDB servers and put them behind the load balancer. Nothing needs to be rebalanced.

Storage: add TiKV nodes. PD notices the new stores and moves Regions and Region leaders onto them in the background until the load is even. Growing Regions split automatically, so data distribution follows size without a resharding project.

Analytics: add TiFlash nodes to grow columnar capacity separately from OLTP.

The result is that capacity and throughput grow roughly linearly as long as the workload avoids a single hot key range.

Each Region is its own Raft group with one leader and usually two followers. All reads and writes for the Region go to the leader.

1. The leader appends the write as a log entry.
2. It sends the entry to followers.
3. Once a majority (2 of 3) has persisted it, the entry is committed.
4. The leader applies it to RocksDB and answers the client.

If the leader dies, followers stop receiving heartbeats and hold an election, so another replica takes over. A group of three survives one failed replica, a group of five survives two.

sequenceDiagram
participant C as Client
participant L as Leader
participant F1 as Follower 1
participant F2 as Follower 2
C->>L: write
L->>F1: append log
L->>F2: append log
F1-->>L: ack
L-->>C: committed after majority

They share a protocol but are built very differently.

Pick MySQL for small to mid data on one box. Pick TiDB when data or write throughput outgrows one machine.

The difference is when conflicts are detected.

Pessimistic mode has been the default since v3.0.8 and matches MySQL expectations. You can choose per transaction:

BEGIN PESSIMISTIC;
BEGIN OPTIMISTIC;

An optimistic failure surfaces as error 9007 (write conflict), so the application must be ready to retry.

TiDB uses a Percolator-style two-phase commit (2PC) on top of TiKV, with MVCC and timestamps from PD.

1. Get start_ts from PD. Reads use it as the snapshot.
2. Prewrite: pick one written key as the primary, then lock every key in the transaction, pointing the locks at the primary.
3. Get commit_ts from PD.
4. Commit: commit the primary key. This is the real commit point.
5. Commit the secondary keys asynchronously.

If the client dies midway, another reader that meets a leftover lock checks the primary key's state and either rolls the lock forward or back. No central transaction coordinator is needed.

sequenceDiagram
participant T as TiDB
participant P as PD
participant K as TiKV
T->>P: get start_ts
T->>K: prewrite primary + secondaries
T->>P: get commit_ts
T->>K: commit primary
K-->>T: success
T-)K: commit secondaries async

TSO is the Timestamp Oracle, a service inside the PD leader that issues globally unique, strictly increasing timestamps.

A timestamp is a 64-bit value: the high part is a physical time in milliseconds and the low 18 bits are a logical counter, so one millisecond can serve up to 262,144 timestamps.

Every transaction asks TSO for a start_ts (its snapshot) and a commit_ts. These ordered numbers are how MVCC decides which version of a row a transaction can see. TiDB batches requests to PD, but if PD is far away in network terms, the round trip adds latency to every transaction.

Both generate primary key values, but they behave differently under distributed load.

CREATE TABLE orders (
  id BIGINT PRIMARY KEY AUTO_RANDOM(5),
  amount DECIMAL(10,2)
);

If you need MySQL-like monotonic IDs, use AUTO_ID_CACHE 1 (v6.4+), at the cost of throughput.

With a clustered index the primary key is the row key itself, so the row is stored directly under the primary key value. A primary key lookup needs one read from TiKV.

With a non-clustered primary key, TiDB stores the row under a hidden _tidb_rowid and keeps the primary key as a separate unique index. A lookup then needs an index read followed by a table read (two steps).

CREATE TABLE t (
  id BIGINT PRIMARY KEY CLUSTERED,
  v  INT
);

Clustered is faster for point lookups and range scans on the key. The trade-off is that monotonic keys write to one place. Use AUTO_RANDOM, or a non-clustered key with SHARD_ROW_ID_BITS, to spread inserts. The default depends on version and tidb_enable_clustered_index.

A statement travels through the stateless TiDB server, then fans out to storage.

1. The client sends SQL over the MySQL protocol and the TiDB server parses it into an AST.
2. The optimizer builds a logical plan and applies rule-based rewrites such as predicate pushdown.
3. The cost-based optimizer, using statistics, picks a physical plan and decides whether to read TiKV or TiFlash.
4. The executor asks PD for a timestamp if needed, finds Regions through its Region cache, and sends coprocessor requests to TiKV or TiFlash.
5. Storage nodes filter and aggregate locally. TiDB merges the partial results and returns the final result set.

flowchart LR
A[Client] --> B[Parse]
B --> C["Logical plan"]
C --> D["Cost-based physical plan"]
D --> E[Executor]
E --> F["TiKV / TiFlash coprocessor"]
F --> E
E --> A

Run EXPLAIN for the plan or EXPLAIN ANALYZE to execute it and see real numbers.

EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 42;

Key columns:

• id: operator names. Read the tree bottom-up, children feed their parent.
• estRows / actRows: estimated versus actual rows. A big gap points to stale statistics.
• task: root runs on TiDB, cop[tikv] and cop[tiflash] are pushed down.
• access object and operator info: the table, index and ranges used.

Red flags are TableFullScan on a big table, no pushdown for selective filters, and a large IndexLookUp double read.

TiDB keeps per-table statistics: row counts, column histograms, Count-Min Sketch and TopN values, and distinct counts. The optimizer reads them to estimate row counts and choose indexes and join orders.

You collect them manually with:

ANALYZE TABLE orders;

Auto analyze runs in the background when the ratio of modified rows crosses tidb_auto_analyze_ratio (0.5 by default), inside the configured time window. Check health with SHOW STATS_HEALTHY and SHOW STATS_META.

Run a manual ANALYZE after bulk loads or large deletes, since auto analyze may lag behind.

Add a TiFlash replica when queries scan or aggregate lots of rows and a row store is the wrong shape for them.

• Dashboards and reports over live data
• Large GROUP BY, window functions and multi-table joins
• Wide tables where queries touch only a few columns
• Mixed workloads where analytics must not slow down OLTP

Skip it for pure point lookups and small transactional tables, because TiKV already serves those well and the replica only adds storage cost.

The optimizer chooses between engines by cost, and you can force one with a hint:

SELECT /*+ READ_FROM_STORAGE(TIFLASH[o]) */ SUM(amount) FROM orders o;

You need at least one TiFlash node in the cluster, then run:

ALTER TABLE orders SET TIFLASH REPLICA 1;

The number is the replica count, and it cannot exceed the number of TiFlash nodes. Check progress with:

SELECT TABLE_NAME, REPLICA_COUNT, AVAILABLE, PROGRESS
FROM information_schema.tiflash_replica
WHERE TABLE_SCHEMA = 'shop';

Reads use TiFlash once AVAILABLE is 1. To remove it, set the count to 0. You can also apply it to a whole database with ALTER DATABASE shop SET TIFLASH REPLICA 1.

Both let you read from replicas other than the leader, but for different goals.

SELECT * FROM orders AS OF TIMESTAMP NOW() - INTERVAL 5 SECOND;

Stale Read suits multi-region deployments where a few seconds of lag is fine. Follower Read is a better fit when a hot Region leader is saturated but answers must stay fresh.

TiDB changes schema without blocking reads or writes, using the state-machine approach from Google's F1 paper.

A schema object moves through intermediate states, for example for a new index:

1. none: index does not exist.
2. delete only: deletes maintain it, nothing reads or inserts.
3. write only: inserts and deletes maintain it, reads still ignore it.
4. write reorganization: existing rows are backfilled.
5. public: queries can use it.

Only two adjacent schema versions can be active across servers at once, so mixed versions never corrupt data. One TiDB server is the DDL owner and runs queued jobs. Follow progress with ADMIN SHOW DDL JOBS. Since v6.3, tidb_ddl_enable_fast_reorg speeds up ADD INDEX backfill.

Placement Rules in SQL let you control where replicas and leaders of your data are stored, using plain SQL instead of editing PD configuration.

It builds on store labels (region, zone, host, disk type). You create a policy and attach it to a table, partition or database:

CREATE PLACEMENT POLICY eu_only
  PRIMARY_REGION="eu-west-1"
  REGIONS="eu-west-1,eu-central-1"
  FOLLOWERS=2;

ALTER TABLE customers PLACEMENT POLICY = eu_only;

Typical uses are keeping data inside a legal region, putting hot partitions on fast SSD stores and old ones on cheaper disks, and isolating a critical table onto dedicated nodes. The feature became GA in v6.0.

The main tool is BR (Backup and Restore), which works at the storage layer and is far faster than logical dumps for large clusters.

• Snapshot backup: a full backup at one timestamp.
• Log backup: continuous capture of changes, which enables point-in-time recovery (PITR) from v6.2.

tiup br backup full --pd 10.0.0.1:2379   --storage "s3://bucket/full-2026-11-11"

tiup br log start --task-name=pitr --pd 10.0.0.1:2379   --storage "s3://bucket/log"

tiup br restore point --pd 10.0.0.1:2379   --full-backup-storage "s3://bucket/full-2026-11-11"   --storage "s3://bucket/log"   --restored-ts "2026-11-11 10:30:00+0000"

Storage targets include S3, GCS, Azure Blob and NFS. For small data sets, Dumpling logical exports also work.

They solve different parts of data movement.

A common migration chain is Dumpling to Lightning for the initial load, then DM or TiCDC for incremental sync. BR is for TiDB-to-TiDB protection, not for loading MySQL dumps.

Sharded MySQL scales, but the complexity moves into your application and operations. TiDB moves it into the database.

The trade-offs: TiDB commits take extra network round trips, so single-row latency is higher than local MySQL, and it needs at least three storage nodes. If your data fits one MySQL comfortably, the simpler option wins.

A hotspot is when most reads or writes hit one Region, so one TiKV node saturates while others idle.

Common causes:

• Monotonic keys, such as AUTO_INCREMENT primary keys or timestamp-prefixed indexes
• A small, very popular table living in a single Region
• Sequential bulk inserts

Fixes:

1. Use AUTO_RANDOM for the primary key.
2. For non-clustered tables use SHARD_ROW_ID_BITS with PRE_SPLIT_REGIONS.
3. Add a hash or bucket prefix to monotonic index keys.
4. Use Follower Read for hot read Regions, and let load-based split divide busy Regions.

CREATE TABLE logs (
  id BIGINT AUTO_RANDOM PRIMARY KEY, msg TEXT
);
-- or
CREATE TABLE t2 (a INT, b INT)
  SHARD_ROW_ID_BITS=4 PRE_SPLIT_REGIONS=3;

Detect hotspots with the Key Visualizer heatmap in TiDB Dashboard.

Work from finding the query to understanding its plan.

1. Find it: open Slow Queries in TiDB Dashboard or query information_schema.slow_query. The threshold is tidb_slow_log_threshold (300 ms default). statements_summary and Top SQL show the heaviest statements overall.
2. Inspect the plan: run EXPLAIN ANALYZE and compare estRows to actRows.
3. Check statistics: run ANALYZE TABLE if they are stale.
4. Look at time breakdown: parse, compile, coprocessor wait, lock wait, or TiKV scan time in the slow log fields.
5. Fix: add a covering index, rewrite the query, use an optimizer hint or a SQL binding to pin a good plan.

SELECT query_time, query FROM information_schema.slow_query
ORDER BY query_time DESC LIMIT 5;

If a plan keeps regressing after upgrades, Plan Replayer captures the environment for offline analysis.

MVCC keeps old versions of rows so transactions can read consistent snapshots. GC removes versions that no transaction can need anymore.

The elected GC leader (one TiDB server) calculates a safe point equal to current time minus tidb_gc_life_time (10 minutes by default). Then it:

1. Resolves leftover locks older than the safe point.
2. Deletes dropped table and index ranges.
3. Lets TiKV drop old versions during compaction.

A transaction or snapshot read older than the safe point fails with a "GC life time is shorter than transaction duration" error. Services such as BR and TiCDC register their own service safe points, which hold GC back and can cause growth in storage if left running. Raise tidb_gc_life_time only when you really need long snapshot reads.

The cluster keeps serving as long as each affected Region still has a majority of replicas.

1. Raft leaders on the failed node stop sending heartbeats. Followers of those Regions hold an election and a new leader takes over, usually within seconds.
2. TiDB servers get a region error, refresh their Region cache from PD and retry on the new leader.
3. PD marks the store Disconnected. It waits max-store-down-time (30 minutes by default) in case the node returns.
4. After that the store is Down and PD recreates the missing replicas on other stores by copying from surviving replicas.

If a Region loses its majority (for example two of three replicas), it becomes unavailable until replicas return, or an operator performs unsafe recovery, which can risk data loss.

PD runs on embedded etcd as a Raft group, so the remaining PD members elect a new leader, typically within a few seconds.

The new leader reloads cluster metadata and, importantly, restarts the TSO from a safe value. PD persists a TSO upper bound to etcd ahead of time, so the new leader can start above every timestamp the old one could have issued. Timestamps therefore never go backwards.

During the election, requests that need a timestamp wait, so new transactions pause briefly. TiDB and TiKV cache Region routing, so work that does not need PD can continue for a short time. Once the new leader is up, everything resumes.

If PD loses its majority (two of three nodes), the cluster cannot allocate timestamps or schedule, and transactions stop until a majority returns.

Pick the method by size, then tune writes so they spread across the cluster.

• Very large initial loads: TiDB Lightning in physical import mode or the IMPORT INTO statement. They write sorted SST files directly to TiKV.
• Ongoing inserts: batch multi-row INSERT statements (a few hundred rows each), run on many connections in parallel, and keep transactions well below the size limit.
• Avoid hotspots: use AUTO_RANDOM or SHARD_ROW_ID_BITS with pre-split Regions so inserts hit many Regions at once.
• Big deletes or updates: use non-transactional DML (BATCH ON id LIMIT 5000 DELETE ...) to split work into small chunks.

After loading, run ANALYZE TABLE so the optimizer sees real row counts.

Standard 2PC costs two sequential rounds: prewrite, then commit. That extra round adds noticeable latency, especially across zones.

Async commit lets the client report success once prewrite has succeeded. The primary lock stores the list of secondary keys, so any reader can still determine the outcome even if the commit step has not finished. The final commit phase runs in the background.

1PC applies to transactions that touch keys in only one Region. TiKV can write the data and commit it in a single Raft write, skipping the second phase altogether.

Variables: tidb_enable_async_commit and tidb_enable_1pc. The trade-off is that they give causal consistency, not external consistency (linearizability), between transactions. Applications that need strict ordering across independent clients should check this before enabling them.

MPP (massively parallel processing) lets several TiFlash nodes run one query together, exchanging data between them instead of sending everything to the TiDB server.

1. The TiDB optimizer picks MPP when it is cheaper and splits the plan into fragments at exchange points.
2. The TiDB node acts as coordinator and dispatches fragments as tasks to TiFlash nodes.
3. Each TiFlash node scans its local column data and runs its fragment in a vectorized pipeline.
4. Exchange operators move rows between nodes: broadcast a small table to everyone, shuffle by hash key for big joins and aggregations, or pass results to the final stage.
5. The last fragment sends results back to TiDB.

flowchart LR
A["TiDB coordinator"] --> B["TiFlash node 1"]
A --> C["TiFlash node 2"]
B <-->|shuffle / broadcast| C
B --> D["Final fragment"]
C --> D
D --> A

Plans show mpp[tiflash] and ExchangeSender / ExchangeReceiver operators. Control it with tidb_allow_mpp and tidb_enforce_mpp.

Start by identifying which transaction mode and error you see.

• Error 9007 (write conflict): seen in optimistic mode at commit. Retry the transaction in the application, shorten it, or switch hot paths to pessimistic mode.
• Error 1205 (lock wait timeout): a pessimistic transaction waited too long. Find the blocker in information_schema.data_lock_waits and look at tidb_trx for long runners.
• Error 1213 (deadlock): TiDB detects cycles and aborts one victim. Review information_schema.deadlocks to see which statements collided.

Prevention:

1. Touch rows in a consistent order in every code path.
2. Keep transactions short and avoid user think-time inside them.
3. Use SELECT ... FOR UPDATE NOWAIT when you prefer failing fast over waiting.
4. Always add retry logic with backoff for 9007 and 1213.

With TiUP, scaling out is online and needs no downtime.

1. Write a small topology file listing only the new nodes (for example one more tikv_servers host).
2. Run the scale-out command.
3. Verify the new nodes are Up.
4. For TiDB servers, add them to the load balancer.

tiup cluster scale-out prod-tidb scale-out.yaml
tiup cluster display prod-tidb

After a new TiKV starts, PD gradually moves Regions and leaders to it, which you can watch in Grafana. To scale in, run tiup cluster scale-in prod-tidb -N 10.0.0.9:20160. A TiKV node goes Offline while Regions migrate away, then Tombstone, and you remove it with tiup cluster prune. Do not shrink below three TiKV nodes with three replicas.

On Kubernetes, change the replica count of the component in the TidbCluster resource and TiDB Operator does the rest.