How TiDB Eliminates Billion‑Row Table Pain: Real‑World Lessons from 360 Cloud

Usage Background

360 cloud platform supports multiple databases; MySQL instances reached billions of rows, causing DDL delays and disk pressure.

Why TiDB

No disk capacity worries.

Native online DDL, no third‑party tool bugs.

Column add or primary key expansion in seconds.

COUNT(*) on 2 billion rows finishes in about a minute.

One‑click MySQL to TiDB migration.

Generally better performance than single‑node MySQL.

Cluster Architecture

TiDB cluster with DM, Pump, Drainer; supports both legacy MySQL workloads and new services.

DM Migration Experience

DM handles schema changes, but requires specific permissions (SELECT, UPDATE, ALTER, CREATE, DROP, INSERT, DELETE) and careful handling of relay logs and large tables.

PD Scheduling

Balance‑leader and balance‑region schedulers distribute load; parameters like high‑space‑ratio, region‑schedule‑limit, merge‑schedule‑limit can be tuned via pd‑ctl.

Performance Tuning

Adjust region merge thresholds, compaction jobs, and Raft store settings.

Enable Hibernate Region to reduce idle region heartbeats.

Optimize load‑data, batch insert/delete, and avoid hot‑spot keys.

Common Issues & Tips

Column limit (TiDB 512 vs MySQL 1024).

GC tables may appear empty but not an error.

Enum queries may not use indexes before TiDB 4.0.

Large DDL on 40 billion‑row tables may take days; tune tidb_ddl_reorg_* variables.

Monitor relay‑log cleanup and disk usage (keep usage < 50%).

Outlook

TiDB will be integrated into 360 HULK cloud platform, with ongoing upgrades and feature improvements.