TiDB

TiDB is a distributed SQL database whose SQL layer, transactional storage, and analytical storage have different jobs. Evaluate it when relational workloads need a distributed architecture and the team can justify the operational and application tradeoffs. Begin with representative transactions and query plans, not an assumption that MySQL protocol support makes every workload portable.

The important question is where your present bottleneck lives. Adding SQL-serving capacity may help a compute-bound request path; it does not automatically remove a hot record, a broad scan, or a transaction that serializes many callers.

TL;DR

Quick Example

Run this SQL only in a disposable test schema on an authorized TiDB instance, with no pre-existing tekstache_tidb_demo table. It creates two fictional inventory rows, rolls back a proposed move, then commits a move. Quantities should end at 7 and 3, with a total of 10. It is not a complete inventory service or production migration.

The SQL uses portable statements, so it shows the accounting and rollback logic but not TiDB's syntax, isolation, distribution, locking, retry behavior, or performance. Run it against TiDB before using the results as migration evidence.

The fixture omits concurrent inventory protection. A real service must handle insufficient stock, failed updates, competing transactions, and retries without repeating external effects. A conserved total alone cannot prove that either row remains valid under concurrency.

Core Concepts

SQL and storage scale along different boundaries

In the TiDB architecture, TiDB servers provide a stateless SQL layer, TiKV stores transactional data in replicated key ranges, and PD manages cluster metadata and scheduling responsibilities. A query can involve work across components. Diagnose SQL execution, storage requests, coordination, and network conditions separately before changing node counts.

Analytical access has a different shape

TiFlash stores data in a columnar layout intended for analytical work. That provides another access path for suitable scans and aggregations. For a proposed evaluation, measure transaction latency while analytical queries and data refresh run together. An isolated fast report does not show the effect of its production concurrency or the application's data-freshness requirement.

Compatibility is an inventory, not a slogan

TiDB supports the MySQL protocol and many familiar features, but the compatibility reference lists differences and unsupported features. It also distinguishes native replication from MySQL-compatible client access. A client successfully opening a connection does not validate stored routines, replication tooling, generated SQL, collations, or operational scripts.

Match the Workload to the Architecture

This is an editorial framework, not a benchmark. Compare the same dataset, query mix, concurrency, skew, durability objectives, and deployment responsibilities. Include time spent understanding plans, handling failures, and maintaining the topology. A distributed system can solve a real scaling problem while adding complexity that a small application does not need.

For a useful counterexample, imagine many callers updating one shared counter. More SQL endpoints do not make the logical conflict disappear. Change the data or operation design only if the business invariant allows it; do not weaken correctness merely to improve a throughput chart.

Schema Changes Need Their Own Pilot

Supported TiDB DDL changes are online, with documented restrictions and behavior that differs from MySQL. The compatibility guide covers unsupported type changes and DDL algorithm syntax differences. “Online” should be read as a supported execution mechanism, not a promise of zero resource cost or zero latency impact.

For a proposed index change, capture the current plan and baseline workload first. Rehearse the exact change on representative data, observe job progress and resource use, and verify application behavior during and after it. Check the installed TiDB version's specific DDL documentation before choosing cancellation or recovery actions; these are operations with their own conditions.

Application rollout needs a compatible sequence as well. An added nullable column may be easier to introduce than an immediate required field used by every old writer. Plan the write transition, backfill, validation, and eventual enforcement deliberately. Review the business repair policy for existing invalid data rather than substituting invented defaults.

Operations and Recovery Close the Evaluation

Monitor a complete path: client errors and latency, SQL plans and slow operations, TiKV pressure and hotspots, coordination health, replication, and disk/network capacity. Set useful alerts around the application's objective. A healthy process list can coexist with a request path that cannot complete its transaction budget.

TiDB's Backup and Restore overview distinguishes backup/recovery tooling and documents version and restore prerequisites. Select compatible tools for the actual cluster version; do not bypass compatibility checks to make a restore rehearsal proceed. Replication can propagate a mistaken write, so it does not substitute for a recovery point before that mistake.

In an isolated drill, restore the chosen backup and required logs into a suitable destination. Verify representative records, application invariants, permissions, and usable query behavior. Measure time and data loss against the agreed objectives. Keep outbound jobs and external side effects disabled until the restored environment is intentionally connected.

Document who can operate the cluster and where the required credentials, backups, configuration, and runbooks remain accessible during failure. Recovery instructions that depend entirely on the failed system are difficult to use when needed most.

Best Practices

Inventory compatibility before moving data

Capture driver versions, generated SQL, schema types, routines, replication integrations, and administrative scripts. Classify each as exercised, unsupported, or still pending. A successful demo table should not turn an untested dependency into an implied pass.

Test skew and contention deliberately

Use a distribution that resembles the busiest customers, keys, and transaction sizes. Uniform synthetic traffic can hide the hot path that determines production behavior. Observe tail latency and failures alongside aggregate throughput.

Keep retries tied to operation identity

Application retry policies must account for transaction outcomes and external effects. Test connection loss and ambiguous outcomes with the target client. Repeating a payment or notification after an uncertain transaction result is a different failure from retrying a read.

Rehearse a reversible migration

Plan initial copy, ongoing change capture where appropriate, validation, cutover, and the point after which reversal needs special handling. Verify row-level or business-level consistency and application behavior before moving real traffic. Define the next action if the pilot fails its acceptance criteria.

Common Mistakes

Bad: Treat MySQL protocol compatibility as complete MySQL behavior.

Correct: Exercise the application's specific features, drivers, tooling, and operational paths.

Bad: Add SQL servers to fix a single contended record.

Correct: Diagnose the limiting boundary and validate a design that preserves the required invariant.

Bad: Count replicated data as an independently restorable backup.

Correct: Maintain suitable recovery artifacts and demonstrate an isolated restore.

FAQ

Is TiDB a sharding layer in front of unchanged MySQL servers?

The documented architecture has its own SQL and distributed storage components. Familiar protocol access does not mean the storage, plans, or operational model are identical to a MySQL deployment.

Does TiFlash make every query faster?

Evaluate the query and workload mix. Columnar storage is relevant to suitable analytical work; transaction behavior, plan selection, resource competition, and freshness still need testing.

Can online DDL affect a busy application?

Treat the exact change as work to rehearse under load. Monitor progress, errors, resource use, and client latency rather than inferring negligible impact from the word online.

What did the local SQL execution prove?

Only the teaching fixture's arithmetic and ordinary SQLite transaction outcomes. TiDB execution, distributed consistency, concurrency, query plans, failure recovery, and operational suitability remain unverified.

Related Topics

References