TiDB Overview: Architecture, Deployment, Advantages, and Practical Tips

When a MySQL table reaches billions of rows, performance degrades and schema changes take many hours; the usual solution is sharding, which requires application changes. TiDB is a distributed NewSQL database compatible with most MySQL protocols, allowing migration without code modifications while delivering high performance.

TiDB is an open‑source distributed HTAP database that combines RDBMS and NoSQL features, supports unlimited horizontal scaling, strong consistency, and high availability, targeting both OLTP and OLAP workloads.

Overall Architecture

TiDB clusters consist of three core components: TiDB Server (stateless SQL processing), Placement Driver (PD) for metadata, scheduling, and ID allocation, and TiKV Server (distributed transactional key‑value store). TiSpark provides Spark‑SQL integration for complex OLAP queries.

Environment Deployment

Recommended Linux: CentOS 7.3+ (or other mainstream distributions). Use SSDs (PCIe preferred). A production cluster needs at least five machines: 2 TiDB nodes, 3 TiKV nodes; PD can share servers with TiDB.

TiDB Advantages

1. Unlimited horizontal elasticity – add machines to scale without changing application code.

2. Fault‑tolerant multi‑region deployment – Raft‑based replication ensures 100% strong consistency and automatic failover.

3. Distributed ACID transactions – works across nodes without extra middleware.

4. High MySQL compatibility – existing tools and clients work out of the box, enabling zero‑cost migration.

5. Superior performance on large tables – faster index creation and column modifications compared to MySQL.

Practical Tips

1. Avoid auto‑increment primary keys; use meaningful unique columns or distributed ID generators to prevent hotspot regions.

2. Table schema changes are limited – avoid frequent modifications, multiple index creations, or dropping primary keys.

3. Be aware of version‑specific issues (e.g., TiDB 3.0 allowed duplicate primary keys and unlimited index length; upgraded to 3.1 to fix).

4. Prevent write hotspots by pre‑splitting regions. For integer PKs:

SPLIT TABLE file_HOTSPOT BETWEEN (0) AND (9223372036854775807) REGIONS 128;

For non‑int PKs or tables without PK, enable row‑id sharding:

create table t (a int, b int, index idx1(a)) shard_row_id_bits = 4 pre_split_regions = 3;

5. Record size limits: single KV entry ≤ 6 MB, total entries ≤ 300 k, total size ≤ 100 MB, max 5 000 statements per transaction.

6. Replication factor should be ≥ 3 for disaster recovery; backups require a fresh cluster for restoration.

7. Index length limit is 3072 bytes (768 characters for utf8mb4); use MD5 hashes for very long columns.

8. Grafana can be used to monitor TiDB metrics by adding a TiDB data source and visualizing dashboards.

Conclusion

TiDB offers a robust, MySQL‑compatible alternative to sharding, providing elastic scaling, strong consistency, and rich tooling, but requires a sizable, high‑performance infrastructure (minimum five machines) and careful attention to deployment and operational details.