Verteilte Datenbank TiDB: Tuning- und Praxisleitfaden

数据库

Warum TiDB im Jahr 2026 wählen?

TiDB hat sich als verteilte HTAP (Hybrid Transactional and Analytical Processing)-Datenbank der nächsten Generation zur Go-to-Lösung für Unternehmensdatenbank-Upgrades im Jahr 2026 entwickelt. Sie löst perfekt den Single-Machine-Flaschenhals und die Sharding-Komplexität von herkömmlichem MySQL.

Kernvorteile von TiDB

Dimension TiDB MySQL-Sharding CockroachDB Amazon Aurora
Skalierung Transparent horizontal Sharding auf Anwendungsebene Horizontal Vertikal + Leseskalierung
MySQL-Kompatibilität Sehr hoch (95%+) Natives MySQL Mittel Hoch
HTAP Native Unterstützung Zusätzliche Komponenten erforderlich Nicht unterstützt Begrenzt
Betriebskomplexität Mittel (TiUP) Hoch Mittel Niedrig (verwaltet)
Starke Konsistenz Raft-Protokoll Nativ Raft-Protokoll Begrenzt
Open Source Vollständig quelloffen - Quelloffen Closed Source

Wichtige TiDB-Meilensteine im Jahr 2026

  1. TiDB 8.x stabil: Über 40% Leistungsverbesserung, unterstützt größere Datenmengen
  2. TiFlash MPP-Erweiterungen: Deutlich verbesserte Echtzeitanalyse, mehr Fensterfunktionen
  3. Serverless TiDB: Cloud-natives Pay-as-you-go-Modell, niedrigere Einstiegshürde
  4. Ressourcenkontrolle: CPU/IO-Isolierung für Multi-Tenant-Szenarien
  5. Global Sort: Reduziert drastisch den Overhead bei groß angelegten Datenimporten

TiDB-Architekturübersicht

TiDB verwendet eine Compute-Speicher-Trennungsarchitektur mit vier Kernkomponenten:

Komponentenverantwortlichkeiten

┌─────────────────────────────────────────────────────┐
│                    Client (MySQL Protocol)           │
└──────────────┬──────────────────────────────────────┘
               │
┌──────────────▼──────────────────────────────────────┐
│              TiDB Server (SQL Layer)                 │
│  ┌─────────┐ ┌──────────┐ ┌───────────────┐        │
│  │ Parser  │ │ Optimizer│ │ Executor      │        │
│  └─────────┘ └──────────┘ └───────────────┘        │
└──────────────┬──────────────────────────────────────┘
               │
┌──────────────▼──────────────────────────────────────┐
│           PD (Placement Driver)                      │
│  ┌──────────┐ ┌──────────┐ ┌──────────────┐        │
│  │ Scheduler│ │ Meta     │ │ TSO Clock    │        │
│  └──────────┘ └──────────┘ └──────────────┘        │
└──────────────┬──────────────────────────────────────┘
               │
┌──────────────▼──────────────────────────────────────┐
│    TiKV (Row Store)          TiFlash (Column Store)  │
│  ┌─────────┐               ┌──────────────┐        │
│  │ Raft    │               │ DeltaTree    │        │
│  │ RocksDB │               │ ClickHouse   │        │
│  └─────────┘               └──────────────┘        │
└─────────────────────────────────────────────────────┘
  • TiDB Server: Zustandslose SQL-Compute-Schicht, verarbeitet SQL-Parsing, -Optimierung und -Ausführung
  • PD (Placement Driver): Cluster-Gehirn, verwaltet Scheduling, Metadaten und globale Zeitstempel
  • TiKV: Zeilenbasiertes Speichermodul basierend auf RocksDB + Raft, verarbeitet transaktionale Lese-/Schreibvorgänge
  • TiFlash: Spaltenbasiertes Speichermodul basierend auf ClickHouse-Technologie, verarbeitet Echtzeitanalyse

Datenflussmechanismus

  1. Schreibpfad: Client → TiDB → PD (TSO abrufen) → TiKV (Raft-Schreibvorgang) → TiFlash (asynchrone Synchronisation)
  2. Lesepfad (OLTP): Client → TiDB → TiKV (Point-/Range-Scan)
  3. Lesepfad (OLAP): Client → TiDB → TiFlash (MPP-Parallelverarbeitung)

💡 Verwenden Sie das Tool SQL-Formatierer, um TiDB-SQL-Abfragen zu verschönern und die Ausführungsplananalyse zu erleichtern.

TiDB mit TiUP bereitstellen

TiUP ist das offizielle Cluster-Management-Tool von TiDB und unterstützt Ein-Klick-Bereitstellung, Skalierung und Upgrades.

Umgebungseinrichtung

# TiUP installieren
curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
source ~/.bash_profile

# Installation überprüfen
tiup --version

Minimale Testcluster-Bereitstellung

# topo.yaml - Minimale Topologie-Konfiguration
global:
  user: "tidb"
  ssh_port: 22
  deploy_dir: "/tidb-deploy"
  data_dir: "/tidb-data"

monitored:
  node_exporter_port: 9100
  blackbox_exporter_port: 9115

server_configs:
  tidb:
    log.level: "info"
    performance.max-procs: 4
  tikv:
    readpool.coprocessor.max-concurrency: 8
    raftstore.apply-pool-size: 3
    raftstore.store-pool-size: 3
  pd:
    schedule.max-merge-region-size: 20

pd_servers:
  - host: 10.0.1.1

tidb_servers:
  - host: 10.0.1.1

tikv_servers:
  - host: 10.0.1.1

tiflash_servers:
  - host: 10.0.1.1

monitoring_servers:
  - host: 10.0.1.1

grafana_servers:
  - host: 10.0.1.1

# Cluster bereitstellen
tiup cluster deploy tidb-prod v8.5.1 topo.yaml

# Cluster starten
tiup cluster start tidb-prod

# Clusterstatus prüfen
tiup cluster display tidb-prod

# Mit TiDB verbinden
mysql -h 10.0.1.1 -P 4000 -u root

Produktionsbereitstellungsgrundlagen

  1. 3 PD-Knoten bereitstellen: Hohe Verfügbarkeit des Schedulers gewährleisten
  2. Mindestens 3 TiKV-Knoten bereitstellen: Raft-Mehrheitsschreibvorgänge
  3. 2+ TiDB-Knoten bereitstellen: Frontend-Lastverteilung
  4. TiFlash unabhängig bereitstellen: I/O-Konflikte mit TiKV vermeiden
  5. SSD-Festplatten: TiDB-Datenverzeichnis muss NVMe-SSD verwenden
  6. Netzwerk: Latenz zwischen Knoten < 0,5 ms, Bandbreite ≥ 10 Gbps

MySQL-Kompatibilitätscheckliste

TiDB ist hochkompatibel mit dem MySQL 5.7 / 8.0-Protokoll, aber einige Unterschiede erfordern Aufmerksamkeit:

Kompatible Funktionen

Funktion Unterstützung Hinweise
SELECT / INSERT / UPDATE / DELETE ✅ Vollständig unterstützt
JOIN (alle Typen) ✅ Vollständig unterstützt
Unterabfragen ✅ Vollständig unterstützt
Fensterfunktionen ✅ Vollständig unterstützt TiDB 6.0+
CTE (Common Table Expressions) ✅ Vollständig unterstützt TiDB 6.0+
Prepared Statement ✅ Vollständig unterstützt
JSON-Typ ✅ Vollständig unterstützt
UTF8 / UTF8MB4 ✅ Vollständig unterstützt

Inkompatible Funktionen

Funktion Status Workaround
Gespeicherte Prozeduren ❌ Nicht unterstützt Anwendungslogik verwenden
Trigger ❌ Nicht unterstützt Anwendungsereignisse verwenden
Fremdschlüssel ⚠️ Nur Syntax, nicht erzwungen Konsistenz in der Anwendung sicherstellen
XA-Syntax ⚠️ Teilweise unterstützt Internes 2PC von TiDB verwenden
Auto-Increment-Kontinuität ⚠️ Nicht garantiert AUTO_ID_CACHE oder Sequenzen verwenden
SAVEPOINT ✅ Unterstützt TiDB 6.2+
SELECT ... FOR UPDATE ⚠️ Pessimistische Sperre Muss explizit aktiviert werden

Kompatibilitätsprüfungs-Skript

-- TiDB-Version und Kompatibilität prüfen
SELECT tidb_version();

-- Aktuellen Transaktionsmodus prüfen
SELECT @@tidb_txn_mode;

-- Auto-Increment-Verhalten prüfen
SHOW VARIABLES LIKE 'auto_increment%';

-- Zeichensatz-Unterstützung prüfen
SHOW CHARACTER SET WHERE Charset LIKE '%utf%';

💡 Verwenden Sie das Tool JSON-Formatierer, um TiDB-JSON-Datenstrukturen zu validieren.

SQL-Optimierung & Ausführungsplananalyse

EXPLAIN und EXPLAIN ANALYZE

TiDB bietet umfangreiche Ausführungsplan-Analysetools:

-- Ausführungsplan anzeigen
EXPLAIN SELECT o.order_id, c.customer_name
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id
WHERE o.order_date >= '2026-01-01'
  AND o.status = 'shipped';

-- Tatsächliche Ausführungsstatistiken anzeigen (mit Zeit, Zeilenanzahl)
EXPLAIN ANALYZE SELECT o.order_id, c.customer_name
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id
WHERE o.order_date >= '2026-01-01'
  AND o.status = 'shipped';

Wichtige Ausführungsplan-Operatoren

Operator Bedeutung Optimierungsrichtung
TableFullScan Vollständiger Tabellenscan Geeigneten Index hinzufügen
IndexRangeScan Index-Bereichsscan Bereits gut, Tabellen-Lookup-Kosten prüfen
IndexLookUp Index + Tabellen-Lookup Covering-Index in Betracht ziehen
IndexReader Index-Lesezugriff (kein Lookup) Covering-Index, optimal
HashJoin Hash-Join Build-Seite-Datengröße prüfen
MergeJoin Merge-Join Sicherstellen, dass beide Seiten sortiert sind
IndexJoin Index-Nested-Join Gut für kleine Tabelle, die große treibt
StreamAgg Stream-Aggregation Bereits optimal
HashAgg Hash-Aggregation Gruppierungskardinalität prüfen
TopN TopN-Sortierung Bereits optimal
Sort Vollständige Sortierung Prüfen, ob Index-Reihenfolge genutzt werden kann

Praktische SQL-Tuning-Beispiele

-- Beispiel 1: Vollständigen Tabellenscan vermeiden
-- Problem: Geringe Selektivität bei status verursacht Vollscan
EXPLAIN SELECT * FROM orders WHERE status = 'pending';
-- Lösung: Zusammengesetzten Index hinzufügen
ALTER TABLE orders ADD INDEX idx_status_date (status, order_date);

-- Beispiel 2: Covering-Index zur Eliminierung des Tabellen-Lookups
-- Problem: IndexLookUp hat hohe Lookup-Kosten
EXPLAIN SELECT customer_id, order_date FROM orders WHERE status = 'shipped';
-- Lösung: Covering-Index
ALTER TABLE orders ADD INDEX idx_cover (status, customer_id, order_date);

-- Beispiel 3: JOIN-Reihenfolge optimieren
-- Problem: HashJoin Build-Seite zu groß
EXPLAIN ANALYZE SELECT *
FROM order_items oi
JOIN products p ON oi.product_id = p.product_id
WHERE p.category = 'electronics';
-- Lösung: Index auf treibender Tabelle + Statistiken aktualisieren
ANALYZE TABLE products;
ANALYZE TABLE order_items;

SQL-Planverwaltung (SPM)

-- SQL Binding erstellen, um optimalen Plan zu fixieren
CREATE SESSION BINDING FOR
  SELECT * FROM orders WHERE status = 'shipped'
USING
  SELECT * FROM orders USE INDEX (idx_status_date) WHERE status = 'shipped';

-- Vorhandene Bindings anzeigen
SHOW SESSION BINDINGS;

-- Binding entfernen
DROP SESSION BINDING FOR
  SELECT * FROM orders WHERE status = 'shipped';

Verteilte Indexstrategien

Das Indexdesign in verteilten Datenbanken unterscheidet sich erheblich von Single-Machine-MySQL und erfordert die Berücksichtigung von Region-übergreifenden Kosten und Hotspot-Risiken.

Indexdesign-Prinzipien

  1. Region-Scans reduzieren: Index-Präfix sollte gestreut sein, um Konzentration in wenigen Region zu vermeiden
  2. Indexanzahl kontrollieren: Jeder Index erhöht Schreib-Overhead und Speicherbedarf
  3. Zusammengesetzte Indizes bevorzugen: Tabellen-Lookups reduzieren, ein zusammengesetzter Index ersetzt mehrere Einzelspalten-Indizes
  4. Zu breite Indizes vermeiden: Gesamte Indexspaltenbreite sollte < 200 Bytes sein
  5. Index-Platzierung berücksichtigen: TiDB unterstützt die Platzierung von Indizes auf verschiedenen Speichermodulen

Index-Platzierungsstrategie (Placement Rules)

-- Index für kalte Daten auf HDD-Speicher platzieren
ALTER TABLE orders ADD INDEX idx_create_time (create_time)
  PLACEMENT POLICY 'cold_storage';

-- Placement-Richtlinie erstellen
CREATE PLACEMENT POLICY cold_storage LEADER_CONSTRAINTS '[+disk=hdd]' FOLLOWER_CONSTRAINTS '[+disk=hdd]';

Unsichtbare Indizes

-- Unsichtbaren Index erstellen (kein Abfrageeinfluss, nur Schreib-Wartung)
ALTER TABLE orders ADD INDEX idx_test (customer_id) INVISIBLE;

-- Überprüfen, dass der Index unsichtbar ist
SHOW INDEXES FROM orders;

-- Sichtbar machen, nachdem bestätigt wurde, dass keine Leistungseinbußen bestehen
ALTER TABLE orders ALTER INDEX idx_test VISIBLE;

Hotspot-Diagnose & -Behebung

Hotspots sind das häufigste Problem in verteilten Datenbanken und verursachen ungleiche Last auf bestimmten Knoten.

Hotspot-Identifikation

-- Hotspot-Region-Verteilung anzeigen
SELECT STORE_ID, COUNT(*) AS region_count
FROM INFORMATION_SCHEMA.TIKV_REGION_STATUS
GROUP BY STORE_ID
ORDER BY region_count DESC;

-- Schreib-Hotspots anzeigen
SELECT TABLE_NAME, INDEX_NAME, WRITTEN_BYTES, READ_BYTES
FROM INFORMATION_SCHEMA.TIKV_REGION_STATUS
WHERE WRITTEN_BYTES > 1048576
ORDER BY WRITTEN_BYTES DESC
LIMIT 20;

Häufige Hotspot-Szenarien & Lösungen

Szenario 1: Auto-Increment-ID-Hotspot

-- Problem: AUTO_INCREMENT führt zu Schreibkonzentration in einer einzigen Region
CREATE TABLE logs (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  content TEXT,
  created_at TIMESTAMP
);

-- Lösung 1: SHARD_ROW_ID_BITS zur Streuung verwenden
CREATE TABLE logs (
  id BIGINT AUTO_INCREMENT,
  content TEXT,
  created_at TIMESTAMP,
  PRIMARY KEY (id)
) SHARD_ROW_ID_BITS = 4;

-- Lösung 2: Zeitstempel als Primärschlüsselpräfix verwenden
CREATE TABLE logs (
  created_at TIMESTAMP,
  id BIGINT AUTO_INCREMENT,
  content TEXT,
  PRIMARY KEY (created_at, id)
) SHARD_ROW_ID_BITS = 4;

Szenario 2: Index-Hotspot

-- Problem: Schreibvorgänge im Zeitindex konzentrieren sich auf die End-Region
ALTER TABLE orders ADD INDEX idx_created (created_at);

-- Lösung: SHARD_ROW_ID_BITS + PRE_SPLIT_REGIONS verwenden
CREATE TABLE orders (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  order_no VARCHAR(64),
  created_at TIMESTAMP,
  amount DECIMAL(10,2)
) SHARD_ROW_ID_BITS = 4
  PRE_SPLIT_REGIONS = 4;

Szenario 3: Kleine-Tabelle-Voll-Hotspot

-- Problem: Kleine Tabellendaten in einer einzigen Region, Lese-Hotspot bei hoher Nebenläufigkeit
-- Lösung: Follower Read verwenden, um Leselast zu verteilen
SET @@tidb_replica_read = 'leader-and-follower';

-- Oder auf Sitzungsebene aktivieren
SET SESSION tidb_replica_read = 'follower';

PD-Scheduling-Optimierung

# Aktuelle Scheduling-Konfiguration anzeigen
tiup ctl:v8.5.1 pd -u http://10.0.1.1:2379 config show all

# Hotspot-Scheduling-Parameter anpassen
tiup ctl:v8.5.1 pd -u http://10.0.1.1:2379 config set hot-region-schedule-limit 8
tiup ctl:v8.5.1 pd -u http://10.0.1.1:2379 config set balance-hot-region-schedule-limit 4

# Region Merge aktivieren, um leere Region zu reduzieren
tiup ctl:v8.5.1 pd -u http://10.0.0.1:2379 config set enable-merge-region true

TiFlash-Echtzeitanalyse in der Praxis

TiFlash ist die Spaltenspeicher-Engine von TiDB, die Echtzeit-OLAP-Analyse ohne ETL ermöglicht.

TiFlash-Synchronisation aktivieren

-- TiFlash-Synchronisation für gesamte Datenbank aktivieren
ALTER DATABASE orders_db SET TIFLASH REPLICA 2;

-- TiFlash-Synchronisation für einzelne Tabelle aktivieren (2 Replikas)
ALTER TABLE orders SET TIFLASH REPLICA 2;

-- Synchronisationsfortschritt prüfen
SELECT * FROM INFORMATION_SCHEMA.TIFLASH_REPLICA_STATUS;

-- Bestimmte Spalten zu TiFlash synchronisieren (Synchronisations-Overhead reduzieren)
ALTER TABLE orders SET TIFLASH REPLICA 1
  INCLUDE (order_id, customer_id, amount, order_date);

MPP-Modus-Abfragen

-- TiFlash MPP-Engine erzwingen
SET @@tidb_isolation_read_engines = 'tiflash';
SET @@tidb_enforce_mpp = 1;

-- Echtzeit-Umsatzanalyse
SELECT
  DATE(order_date) AS dt,
  p.category,
  COUNT(*) AS order_count,
  SUM(oi.quantity * oi.unit_price) AS revenue,
  AVG(oi.quantity * oi.unit_price) AS avg_order_value
FROM orders o
JOIN order_items oi ON o.order_id = oi.order_id
JOIN products p ON oi.product_id = p.product_id
WHERE o.order_date >= '2026-01-01'
GROUP BY DATE(order_date), p.category
ORDER BY dt DESC, revenue DESC;

-- Standardmäßige Engine-Auswahl wiederherstellen
SET @@tidb_isolation_read_engines = 'tidb,tikv,tiflash';
SET @@tidb_enforce_mpp = 0;

HTAP-Smart-Routing

-- TiDB routet automatisch: kleine Abfragen zu TiKV, große Abfragen zu TiFlash
-- Keine manuelle Konfiguration erforderlich, der Optimierer entscheidet automatisch

-- Prüfen, welche Engine eine Abfrage tatsächlich verwendet
EXPLAIN ANALYZE SELECT COUNT(*), SUM(amount)
FROM orders WHERE order_date >= '2026-01-01';
-- Beobachten, ob der Operator tiflash-Informationen enthält

Backup & Disaster Recovery (BR)

BR (Backup & Restore) ist das native verteilte Backup- und Wiederherstellungstool von TiDB.

Vollständiges Backup & Wiederherstellung

# Vollständiges Backup auf S3
tiup br:v8.5.1 backup full \
  --pd "10.0.1.1:2379" \
  --storage "s3://tidb-backup/full-20260611" \
  --s3.region "us-east-1" \
  --send-credentials-to-tikv true \
  --concurrency 4

# Vollständige Wiederherstellung
tiup br:v8.5.1 restore full \
  --pd "10.0.1.1:2379" \
  --storage "s3://tidb-backup/full-20260611" \
  --s3.region "us-east-1"

Inkrementelles Backup

# Inkrementelles Backup (basierend auf dem TS des letzten Backups)
tiup br:v8.5.1 backup full \
  --pd "10.0.1.1:2379" \
  --storage "s3://tidb-backup/incr-20260611" \
  --last-backup-ts 450335849738604544

Datenbank-/Tabellen-Level-Backup

# Datenbank-Level-Backup
tiup br:v8.5.1 backup db \
  --db "orders_db" \
  --pd "10.0.1.1:2379" \
  --storage "s3://tidb-backup/orders-db-20260611"

# Tabellen-Level-Backup
tiup br:v8.5.1 backup table \
  --db "orders_db" \
  --table "orders" \
  --pd "10.0.1.1:2379" \
  --storage "s3://tidb-backup/orders-table-20260611"

Point-in-Time-Recovery (PITR)

# Wiederherstellung zu einem bestimmten Zeitpunkt
tiup br:v8.5.1 restore full \
  --pd "10.0.1.1:2379" \
  --storage "s3://tidb-backup/full-20260611" \
  --restored-ts "2026-06-11T14:30:00+08:00"

💡 Verwenden Sie das Tool Hash-Verschlüsselung, um die Integritäts-Prüfsummen der Backup-Daten zu verifizieren.

Grafana-Monitoring-System

TiDB-Cluster werden mit einem vollständigen Prometheus + Grafana-Monitoring-System geliefert.

Kern-Monitoring-Dashboards

Dashboard Schlüsselmetriken Alarm-Schwellenwert-Empfehlung
TiDB Overview QPS, Verbindungen, langsame Abfragen Langsame Abfrage > 1s
TiKV Details CPU, IO, Region-Anzahl CPU > 80%
PD Details Scheduling-Aufgaben, Region-Verteilung Scheduling-Verzögerung > 5min
TiFlash Details Sync-Verzögerung, MPP-Task-Anzahl Sync-Verzögerung > 10s
BR Backup-Fortschritt, Dauer Backup-Fehler
Node Exporter Festplatte, Speicher, Netzwerk Festplattennutzung > 85%

Details der Schlüsselmetriken

# TiDB-Schlüsselmetriken
tidb_server_query_duration:
  description: "Abfragelatenz P99"
  alert: "> 500ms für 5 Minuten"

tidb_server_slow_query:
  description: "Anzahl langsamer Abfragen"
  alert: "> 10/min"

tikv_grpc_message_duration:
  description: "TiKV gRPC-Anfragelatenz"
  alert: "P99 > 200ms"

tikv_engine_write_bytes:
  description: "Schreib-Durchsatz"
  monitoring: "Plötzliche Einbrüche beobachten"

pd_scheduler_balance_region:
  description: "Region-Scheduling-Geschwindigkeit"
  alert: "Null für über 10 Minuten"

tiflash_sync_apply_duration:
  description: "TiFlash-Daten-Sync-Verzögerung"
  alert: "P99 > 10s"

Benutzerdefinierte Alarmregeln

# Beispiel für Prometheus-Alarmregel
groups:
  - name: tidb_alerts
    rules:
      - alert: TiDBHighQPS
        expr: sum(rate(tidb_server_handle_query_duration_seconds_count[1m])) > 50000
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "TiDB QPS zu hoch"
          description: "Aktueller QPS überschreitet 50000 seit 5 Minuten"

      - alert: TiKVHighWriteLag
        expr: histogram_quantile(0.99, rate(tikv_grpc_message_duration_seconds_bucket{type="write"}[5m])) > 0.5
        for: 3m
        labels:
          severity: critical
        annotations:
          summary: "TiKV-Schreiblatenz zu hoch"
          description: "P99-Schreiblatenz überschreitet 500ms"

Häufige Fehler & Fehlerbehebung

Fehler 1: Region-Lese-/Schreib-Timeout

Error: region is unavailable, wait for a while and retry

Fehlerbehebungsschritte:

# 1. Region-Status prüfen
tiup ctl:v8.5.1 pd -u http://10.0.1.1:2379 region check miss-peer

# 2. TiKV-Gesundheit prüfen
tiup ctl:v8.5.1 pd -u http://10.0.1.1:2379 store

# 3. Langsame Logs anzeigen
tiup cluster audit tidb-prod --limit 50

Fehler 2: Schreibkonflikt

Error: Write conflict, txn start_ts conflicts with another txn

Lösung:

-- Transaktions-Retry-Parameter anpassen
SET @@tidb_retry_limit = 20;
SET @@tidb_txn_retry_interval = 100; -- Millisekunden

-- Konfliktrate prüfen
SELECT * FROM INFORMATION_SCHEMA.TIDB_TRX
  WHERE state = 'LockRcolliding' LIMIT 10;

Fehler 3: OOM (Nicht genügend Speicher)

Error: Out Of Memory Quota!

Lösung:

-- Abfrage-Speicherlimit festlegen
SET @@tidb_mem_quota_query = 1073741824; -- 1GB

-- Ressourcenkontrolle aktivieren
CREATE RESOURCE GROUP rg_report
  RU_PER_SEC = 500
  PRIORITY = LOW;

-- Benutzer an Ressourcengruppe binden
ALTER USER report_user RESOURCE GROUP rg_report;

Fehler 4: TiFlash-Sync-Verzögerung

-- Synchronisationsfortschritt prüfen
SELECT TABLE_ID, REPLICA_COUNT, PROGRESS, AVAILABLE
FROM INFORMATION_SCHEMA.TIFLASH_REPLICA_STATUS;

-- TiFlash-Knotenstatus prüfen
SELECT * FROM INFORMATION_SCHEMA.TIFLASH_TABLES
  WHERE REPLICA_AVAILABLE = 0;

Migration von MySQL zu TiDB

Vergleich von Migrationslösungen

Lösung Anwendungsfall Ausfallzeit Komplexität
DM Voll+Inkrementell Groß angelegte Migration Nahe Null Mittel
Dumpling + TiDB Lightning Einmalige Migration Stunden Niedrig
mysqldump + source Kleines Datenvolumen Stunden Niedrig

DM-Migration verwenden (Empfohlen)

# dm-task.yaml - DM-Migrationsaufgabenkonfiguration
name: mysql-to-tidb
task-mode: all
target-database:
  host: "10.0.2.1"
  port: 4000
  user: "root"
  password: ""

mysql-instances:
  - source-id: "mysql-replica-01"
    block-allow-list: "bw-rule-1"

block-allow-list:
  bw-rule-1:
    do-dbs: ["orders_db", "users_db"]
    ignore-tables:
      - db-name: "orders_db"
        tbl-name: "log_*"

# DM-Aufgabe starten
dmctl start-task dm-task.yaml

# Aufgabenstatus prüfen
dmctl query-status mysql-to-tidb

# Datenkonsistenz verifizieren
dmctl check-task dm-task.yaml

Prä-Migrations-Kompatibilitätsprüfung

-- Verwendung gespeicherter Prozeduren prüfen
SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE
FROM information_schema.routines
WHERE ROUTINE_SCHEMA NOT IN ('mysql', 'sys');

-- Fremdschlüsseleinschränkungen prüfen
SELECT TABLE_SCHEMA, TABLE_NAME, CONSTRAINT_NAME
FROM information_schema.table_constraints
WHERE CONSTRAINT_TYPE = 'FOREIGN KEY';

-- Trigger prüfen
SELECT TRIGGER_SCHEMA, TRIGGER_NAME, EVENT_OBJECT_TABLE
FROM information_schema.triggers;

-- Auto-Increment-Spalten prüfen
SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, AUTO_INCREMENT
FROM information_schema.columns
WHERE EXTRA LIKE '%auto_increment%';

Leistungs-Benchmarks

TPCC-Benchmark

# OLTP-Leistung mit TPCC testen
git clone https://github.com/pingcap/go-tpc.git
cd go-tpc

# Daten vorbereiten
go-tpc tpcc prepare \
  --host 10.0.1.1 --port 4000 \
  --warehouses 1000 --threads 50

# Benchmark ausführen
go-tpc tpcc run \
  --host 10.0.1.1 --port 4000 \
  --warehouses 1000 --threads 50 \
  --time 600s

# Bereinigen
go-tpc tpcc cleanup \
  --host 10.0.1.1 --port 4000 \
  --warehouses 1000

TPC-H-Benchmark (HTAP)

# OLAP-Leistung mit TPC-H testen
go-tpc tpch prepare \
  --host 10.0.1.1 --port 4000 \
  --scale 100 --threads 10

# TiFlash-Ausführung erzwingen
go-tpc tpch run \
  --host 10.0.1.1 --port 4000 \
  --scale 100 --threads 10 \
  --time 300s \
  --engine tiflash

Typische Leistungsreferenz

Szenario Knotenkonfiguration QPS/TPS P99-Latenz
OLTP (TPCC) 3×TiDB + 3×TiKV 15.000 TPS < 50ms
OLAP (TPC-H) + 2×TiFlash 22 Abfragen/5min Variiert je Abfrage
Gemischtes HTAP Obige Konfiguration TP stabil + AP 10x Unabhängig

FAQ

F1: Ist TiDB geeignet, um MySQL-Sharding zu ersetzen?

Ja, dies ist der typischste Anwendungsfall für TiDB. TiDB bietet transparente horizontale Skalierung ohne Sharding-Logik auf Anwendungsebene und behält gleichzeitig die MySQL-Protokollkompatibilität bei, um die Migrationskosten zu minimieren. Dringend empfohlen, wenn eine einzelne Tabelle 50 Millionen Zeilen überschreitet oder die Sharding-Betriebskomplexität zu hoch ist.

F2: Was ist das Transaktionsisolationslevel von TiDB?

TiDB verwendet standardmäßig das RC (Read Committed)-Isolationslevel (v6.0+) und unterstützt auch die RR (Repeatable Read)-Semantik. Das RR von TiDB ist tatsächlich Snapshot Isolation (SI), die Phantom-Reads verhindert, aber subtile Unterschiede zum RR von MySQL in bestimmten Szenarien aufweist (z. B. Current-Read-Verhalten).

F3: Was ist die optimale Datenskala für TiDB?

  • Einzelne Tabelle: Zehn Millionen bis zehn Milliarden Zeilen; TiDB wird ab 50 Millionen Zeilen empfohlen
  • Gesamte Clusterdaten: TB- bis PB-Skala
  • Region-Größe: Standard 96 MB, empfohlen, nahe an diesem Wert zu bleiben

F4: Wie zwischen TiDB und CockroachDB wählen?

Dimension TiDB CockroachDB
SQL-Kompatibilität MySQL PostgreSQL
HTAP Native Unterstützung Nicht unterstützt
Community Hauptsächlich China/APAC Global
Cloud-Service TiDB Cloud CockroachDB Cloud

Wenn Ihr Stack auf MySQL basiert und HTAP benötigt, wählen Sie TiDB; wenn er auf PostgreSQL basiert und nur OLTP benötigt, wählen Sie CockroachDB.

F5: Wie mit großen Transaktionen in TiDB umgehen?

TiDB hat standardmäßig 100 MB und 5000 Zeilen pro Transaktion. Lösungen für große Transaktionen:

-- Transaktionslimits anpassen (nicht empfohlen, zu hoch einzustellen)
SET @@tidb_txn_entry_size_limit = 536870912;  -- 512MB
SET @@tidb_txn_total_size_limit = 1073741824; -- 1GB

-- Empfohlen: Batch-Commits
-- Große Transaktionen in kleine in der Anwendung aufteilen, 1000-5000 Zeilen pro Batch

F6: Was ist die Lizenz von TiDB?

TiDB Server, TiKV und PD verwenden Apache 2.0 vollständig quelloffen. TiFlash ist seit v8.0+ ebenfalls quelloffen. TiDB Cloud (Serverless/Dedicated) ist ein kommerzieller Service.

Zusammenfassung

TiDB ist im Jahr 2026 zum Benchmark-Produkt im Bereich verteilter Datenbanken geworden. Seine MySQL-Kompatibilität, HTAP-Fähigkeit und Cloud-native-Architektur machen es zur idealen Wahl für Unternehmensdatenbank-Upgrades. Wichtige Erkenntnisse:

  1. Architektur: Vier Komponenten TiDB/TiKV/PD/TiFlash, Compute-Speicher-Trennung
  2. Bereitstellung: TiUP-Ein-Klick-Management, SSD- und Netzwerkanforderungen für Produktion
  3. SQL-Tuning: EXPLAIN ANALYZE verwenden, SPM für Plan-Binding beherrschen
  4. Indexdesign: Verteilte Eigenschaften berücksichtigen, Hotspot-Indizes vermeiden
  5. Hotspot-Management: SHARD_ROW_ID_BITS-Streuung, Follower-Read-Verteilung
  6. HTAP: TiFlash-Spaltenspeicher + MPP-Engine für Echtzeitanalyse
  7. Disaster Recovery: BR unterstützt vollständige/inkrementelle/PITR-Wiederherstellungsstrategien
  8. Monitoring: Vollständiges Grafana-System, Schlüsselmetriken dürfen nicht ignoriert werden
  9. Migration: DM-inkrementelle Migration erreicht nahezu ausfallfreie Umstellung

Probiere diese browser-lokalen Tools aus — keine Registrierung erforderlich →

#TiDB#分布式数据库#NewSQL#MySQL兼容#教程