Guide de Réglage et Pratique de la Base de Données Distribuée TiDB

数据库

Pourquoi choisir TiDB en 2026 ?

TiDB, en tant que base de données distribuée HTAP (Traitement Hybride Transactionnel et Analytique) de nouvelle génération, est devenue la solution de référence pour la modernisation des bases de données d'entreprise en 2026. Elle résout parfaitement le goulot d'étranglement mono-machine et la complexité du sharding de MySQL traditionnel.

Avantages clés de TiDB

Dimension TiDB Sharding MySQL CockroachDB Amazon Aurora
Mise à l'échelle Horizontale transparente Sharding au niveau applicatif Horizontale Verticale + mise à l'échelle en lecture
Compatibilité MySQL Très élevée (95%+) MySQL natif Moyenne Élevée
HTAP Support natif Composants supplémentaires nécessaires Non supporté Limité
Complexité opérationnelle Moyenne (TiUP) Élevée Moyenne Faible (géré)
Cohérence forte Protocole Raft Native Protocole Raft Limitée
Open source Entièrement open source - Open source Code fermé

Jalons clés de TiDB en 2026

  1. TiDB 8.x stable : Amélioration des performances de 40%+, support de volumes de données plus importants
  2. Améliorations MPP de TiFlash : Analyse en temps réel significativement améliorée, plus de fonctions de fenêtre
  3. TiDB Serverless : Modèle cloud natif à l'usage, barrière d'entrée réduite
  4. Contrôle des ressources : Isolation CPU/IO pour les scénarios multi-tenant
  5. Tri global : Réduction drastique de la surcharge lors des imports de données à grande échelle

Vue d'ensemble de l'architecture TiDB

TiDB adopte une architecture de séparation calcul-stockage avec quatre composants principaux :

Responsabilités des composants

┌─────────────────────────────────────────────────────┐
│                    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 : Couche de calcul SQL sans état, gère l'analyse, l'optimisation et l'exécution SQL
  • PD (Placement Driver) : Cerveau du cluster, gère l'ordonnancement, les métadonnées et les horodatages globaux
  • TiKV : Moteur de stockage en lignes basé sur RocksDB + Raft, gère les lectures/écritures transactionnelles
  • TiFlash : Moteur de stockage en colonnes basé sur la technologie ClickHouse, gère l'analyse en temps réel

Mécanisme de flux de données

  1. Chemin d'écriture : Client → TiDB → PD (obtenir TSO) → TiKV (écriture Raft) → TiFlash (synchro asynchrone)
  2. Chemin de lecture (OLTP) : Client → TiDB → TiKV (scan ponctuel/par plage)
  3. Chemin de lecture (OLAP) : Client → TiDB → TiFlash (calcul parallèle MPP)

💡 Utilisez l'outil Formateur SQL pour formater les requêtes SQL de TiDB et faciliter l'analyse du plan d'exécution.

Déploiement de TiDB avec TiUP

TiUP est l'outil officiel de gestion de cluster TiDB, prenant en charge le déploiement, la mise à l'échelle et les mises à jour en un clic.

Configuration de l'environnement

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

# Vérifier l'installation
tiup --version

Déploiement minimal d'un cluster de test

# topo.yaml - Configuration de topologie minimale
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

# Déployer le cluster
tiup cluster deploy tidb-prod v8.5.1 topo.yaml

# Démarrer le cluster
tiup cluster start tidb-prod

# Vérifier l'état du cluster
tiup cluster display tidb-prod

# Se connecter à TiDB
mysql -h 10.0.1.1 -P 4000 -u root

Essentiels pour le déploiement en production

  1. Déployer 3 nœuds PD : Assurer la haute disponibilité de l'ordonnanceur
  2. Déployer au moins 3 nœuds TiKV : Écriture par majorité Raft
  3. Déployer 2+ nœuds TiDB : Équilibrage de charge frontend
  4. Déployer TiFlash indépendamment : Éviter la contention I/O avec TiKV
  5. Disques SSD : Le répertoire de données TiKV doit utiliser NVMe SSD
  6. Réseau : Latence inter-nœuds < 0,5 ms, bande passante ≥ 10 Gbps

Liste de compatibilité MySQL

TiDB est hautement compatible avec le protocole MySQL 5.7 / 8.0, mais certaines différences nécessitent une attention particulière :

Fonctionnalités compatibles

Fonctionnalité Support Notes
SELECT / INSERT / UPDATE / DELETE ✅ Entièrement supporté
JOIN (tous types) ✅ Entièrement supporté
Sous-requêtes ✅ Entièrement supporté
Fonctions de fenêtrage ✅ Entièrement supporté TiDB 6.0+
CTE (Expressions de table communes) ✅ Entièrement supporté TiDB 6.0+
Prepared Statement ✅ Entièrement supporté
Type JSON ✅ Entièrement supporté
UTF8 / UTF8MB4 ✅ Entièrement supporté

Fonctionnalités incompatibles

Fonctionnalité Statut Contournement
Procédures stockées ❌ Non supporté Utiliser la logique applicative
Triggers ❌ Non supporté Utiliser les événements applicatifs
Clés étrangères ⚠️ Syntaxe uniquement, non appliquées Assurer la cohérence dans l'application
Syntaxe XA ⚠️ Support partiel Utiliser le 2PC interne de TiDB
Continuité auto-incrément ⚠️ Non garantie Utiliser AUTO_ID_CACHE ou séquences
SAVEPOINT ✅ Supporté TiDB 6.2+
SELECT ... FOR UPDATE ⚠️ Verrou pessimiste Doit être activé explicitement

Script de vérification de compatibilité

-- Vérifier la version et la compatibilité TiDB
SELECT tidb_version();

-- Vérifier le mode de transaction actuel
SELECT @@tidb_txn_mode;

-- Vérifier le comportement d'auto-incrément
SHOW VARIABLES LIKE 'auto_increment%';

-- Vérifier le support des jeux de caractères
SHOW CHARACTER SET WHERE Charset LIKE '%utf%';

💡 Utilisez l'outil Formateur JSON pour valider les structures de données JSON de TiDB.

Optimisation SQL et analyse du plan d'exécution

EXPLAIN et EXPLAIN ANALYZE

TiDB fournit des outils d'analyse de plan d'exécution riches :

-- Voir le plan d'exécution
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';

-- Voir les statistiques d'exécution réelles (avec temps, nombre de lignes)
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';

Opérateurs clés du plan d'exécution

Opérateur Signification Direction d'optimisation
TableFullScan Scan complet de table Ajouter un index approprié
IndexRangeScan Scan de plage par index Déjà bon, vérifier le coût de recherche en table
IndexLookUp Index + recherche en table Envisager un index de couverture
IndexReader Lecture d'index (sans recherche) Index de couverture, optimal
HashJoin Jointure par hachage Vérifier la taille des données côté Build
MergeJoin Jointure par fusion S'assurer que les deux côtés sont triés
IndexJoin Jointure imbriquée par index Bon pour petite table pilotant grande table
StreamAgg Agrégation par flux Déjà optimal
HashAgg Agrégation par hachage Vérifier la cardinalité de regroupement
TopN Tri TopN Déjà optimal
Sort Tri complet Vérifier si l'ordre de l'index peut être utilisé

Exemples pratiques de réglage SQL

-- Exemple 1 : Éviter le scan complet de table
-- Problème : Faible sélectivité sur status provoque un scan complet
EXPLAIN SELECT * FROM orders WHERE status = 'pending';
-- Solution : Ajouter un index composé
ALTER TABLE orders ADD INDEX idx_status_date (status, order_date);

-- Exemple 2 : Index de couverture pour éliminer la recherche en table
-- Problème : IndexLookUp a un coût de recherche élevé
EXPLAIN SELECT customer_id, order_date FROM orders WHERE status = 'shipped';
-- Solution : Index de couverture
ALTER TABLE orders ADD INDEX idx_cover (status, customer_id, order_date);

-- Exemple 3 : Optimiser l'ordre de JOIN
-- Problème : Côté Build du HashJoin trop volumineux
EXPLAIN ANALYZE SELECT *
FROM order_items oi
JOIN products p ON oi.product_id = p.product_id
WHERE p.category = 'electronics';
-- Solution : Ajouter un index sur la table pilote + mettre à jour les statistiques
ANALYZE TABLE products;
ANALYZE TABLE order_items;

Gestion des plans SQL (SPM)

-- Créer un SQL Binding pour fixer le plan optimal
CREATE SESSION BINDING FOR
  SELECT * FROM orders WHERE status = 'shipped'
USING
  SELECT * FROM orders USE INDEX (idx_status_date) WHERE status = 'shipped';

-- Voir les Bindings existants
SHOW SESSION BINDINGS;

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

Stratégies d'index distribués

La conception d'index dans les bases de données distribuées diffère considérablement de MySQL mono-machine, nécessitant la prise en compte du coût inter-Region et du risque de points chauds.

Principes de conception d'index

  1. Réduire les scans de Region : Le préfixe d'index doit être dispersé pour éviter la concentration dans quelques Region
  2. Contrôler le nombre d'index : Chaque index ajoute une surcharge d'écriture et de stockage
  3. Préférer les index composés : Réduire les recherches en table, un index composé remplace plusieurs index mono-colonne
  4. Éviter les index trop larges : La largeur totale des colonnes d'index doit être < 200 octets
  5. Considérer le placement d'index : TiDB supporte le placement d'index sur différents moteurs de stockage

Stratégie de placement d'index (Placement Rules)

-- Placer l'index des données froides sur un stockage HDD
ALTER TABLE orders ADD INDEX idx_create_time (create_time)
  PLACEMENT POLICY 'cold_storage';

-- Créer une politique de placement
CREATE PLACEMENT POLICY cold_storage LEADER_CONSTRAINTS '[+disk=hdd]' FOLLOWER_CONSTRAINTS '[+disk=hdd]';

Index invisibles

-- Créer un index invisible (aucun impact sur les requêtes, maintenance en écriture uniquement)
ALTER TABLE orders ADD INDEX idx_test (customer_id) INVISIBLE;

-- Vérifier que l'index est invisible
SHOW INDEXES FROM orders;

-- Rendre visible après confirmation de l'absence d'impact sur les performances
ALTER TABLE orders ALTER INDEX idx_test VISIBLE;

Diagnostic et résolution des points chauds

Les points chauds sont le problème le plus courant dans les bases de données distribuées, causant une charge inégale sur certains nœuds.

Identification des points chauds

-- Voir la distribution des Region de points chauds
SELECT STORE_ID, COUNT(*) AS region_count
FROM INFORMATION_SCHEMA.TIKV_REGION_STATUS
GROUP BY STORE_ID
ORDER BY region_count DESC;

-- Voir les points chauds en écriture
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;

Scénarios courants de points chauds et solutions

Scénario 1 : Point chaud d'ID auto-incrémenté

-- Problème : AUTO_INCREMENT concentre les écritures dans une seule Region
CREATE TABLE logs (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  content TEXT,
  created_at TIMESTAMP
);

-- Solution 1 : Utiliser SHARD_ROW_ID_BITS pour disperser
CREATE TABLE logs (
  id BIGINT AUTO_INCREMENT,
  content TEXT,
  created_at TIMESTAMP,
  PRIMARY KEY (id)
) SHARD_ROW_ID_BITS = 4;

-- Solution 2 : Utiliser l'horodatage comme préfixe de clé primaire
CREATE TABLE logs (
  created_at TIMESTAMP,
  id BIGINT AUTO_INCREMENT,
  content TEXT,
  PRIMARY KEY (created_at, id)
) SHARD_ROW_ID_BITS = 4;

Scénario 2 : Point chaud d'index

-- Problème : Les écritures d'index temporel se concentrent sur la Region finale
ALTER TABLE orders ADD INDEX idx_created (created_at);

-- Solution : Utiliser SHARD_ROW_ID_BITS + PRE_SPLIT_REGIONS
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;

Scénario 3 : Point chaud complet sur petite table

-- Problème : Données de petite table dans une seule Region, point chaud de lecture à haute concurrence
-- Solution : Utiliser Follower Read pour distribuer la pression de lecture
SET @@tidb_replica_read = 'leader-and-follower';

-- Ou activer au niveau de la session
SET SESSION tidb_replica_read = 'follower';

Optimisation de l'ordonnancement PD

# Voir la configuration d'ordonnancement actuelle
tiup ctl:v8.5.1 pd -u http://10.0.1.1:2379 config show all

# Ajuster les paramètres d'ordonnancement des points chauds
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

# Activer Region Merge pour réduire les Region vides
tiup ctl:v8.5.1 pd -u http://10.0.0.1:2379 config set enable-merge-region true

Analyse en temps réel TiFlash en pratique

TiFlash est le moteur de stockage en colonnes de TiDB, permettant l'analyse OLAP en temps réel sans ETL.

Activer la synchronisation TiFlash

-- Activer la synchronisation TiFlash pour toute la base de données
ALTER DATABASE orders_db SET TIFLASH REPLICA 2;

-- Activer la synchronisation TiFlash pour une seule table (2 répliques)
ALTER TABLE orders SET TIFLASH REPLICA 2;

-- Vérifier la progression de la synchronisation
SELECT * FROM INFORMATION_SCHEMA.TIFLASH_REPLICA_STATUS;

-- Synchroniser des colonnes spécifiques vers TiFlash (réduire la surcharge)
ALTER TABLE orders SET TIFLASH REPLICA 1
  INCLUDE (order_id, customer_id, amount, order_date);

Requêtes en mode MPP

-- Forcer le moteur MPP de TiFlash
SET @@tidb_isolation_read_engines = 'tiflash';
SET @@tidb_enforce_mpp = 1;

-- Analyse des ventes en temps réel
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;

-- Restaurer la sélection de moteur par défaut
SET @@tidb_isolation_read_engines = 'tidb,tikv,tiflash';
SET @@tidb_enforce_mpp = 0;

Routage intelligent HTAP

-- TiDB route automatiquement : petites requêtes vers TiKV, grandes requêtes vers TiFlash
-- Aucune configuration manuelle nécessaire, l'optimiseur décide automatiquement

-- Vérifier quel moteur une requête utilise réellement
EXPLAIN ANALYZE SELECT COUNT(*), SUM(amount)
FROM orders WHERE order_date >= '2026-01-01';
-- Observer si l'opérateur contient des informations tiflash

Sauvegarde et reprise après sinistre (BR)

BR (Backup & Restore) est l'outil natif de sauvegarde et restauration distribuée de TiDB.

Sauvegarde et restauration complètes

# Sauvegarde complète vers 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

# Restauration complète
tiup br:v8.5.1 restore full \
  --pd "10.0.1.1:2379" \
  --storage "s3://tidb-backup/full-20260611" \
  --s3.region "us-east-1"

Sauvegarde incrémentale

# Sauvegarde incrémentale (basée sur le TS de la dernière sauvegarde)
tiup br:v8.5.1 backup full \
  --pd "10.0.1.1:2379" \
  --storage "s3://tidb-backup/incr-20260611" \
  --last-backup-ts 450335849738604544

Sauvegarde au niveau base de données/table

# Sauvegarde au niveau base de données
tiup br:v8.5.1 backup db \
  --db "orders_db" \
  --pd "10.0.1.1:2379" \
  --storage "s3://tidb-backup/orders-db-20260611"

# Sauvegarde au niveau table
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"

Récupération à un point dans le temps (PITR)

# Restaurer à un point précis dans le temps
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"

💡 Utilisez l'outil Chiffrement par hachage pour vérifier les sommes de contrôle d'intégrité des données de sauvegarde.

Système de surveillance Grafana

Les clusters TiDB sont livrés avec un système de surveillance complet Prometheus + Grafana.

Tableaux de bord de surveillance principaux

Tableau de bord Métriques clés Seuil d'alerte suggéré
TiDB Overview QPS, connexions, requêtes lentes Requête lente > 1s
TiKV Details CPU, IO, nombre de Region CPU > 80%
PD Details Tâches d'ordonnancement, distribution Region Retard d'ordonnancement > 5min
TiFlash Details Retard de synchronisation, nombre de tâches MPP Retard de synchronisation > 10s
BR Progression de sauvegarde, durée Échec de sauvegarde
Node Exporter Disque, mémoire, réseau Utilisation disque > 85%

Détails des métriques clés

# Métriques clés TiDB
tidb_server_query_duration:
  description: "Latence de requête P99"
  alert: "> 500ms pendant 5 minutes"

tidb_server_slow_query:
  description: "Nombre de requêtes lentes"
  alert: "> 10/min"

tikv_grpc_message_duration:
  description: "Latence de requête gRPC TiKV"
  alert: "P99 > 200ms"

tikv_engine_write_bytes:
  description: "Débit d'écriture"
  monitoring: "Surveiller les chutes soudaines"

pd_scheduler_balance_region:
  description: "Vitesse d'ordonnancement des Region"
  alert: "Zéro pendant plus de 10 minutes"

tiflash_sync_apply_duration:
  description: "Retard de synchronisation des données TiFlash"
  alert: "P99 > 10s"

Règles d'alerte personnalisées

# Exemple de règle d'alerte Prometheus
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: "QPS TiDB trop élevé"
          description: "Le QPS actuel dépasse 50000 depuis 5 minutes"

      - 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: "Latence d'écriture TiKV trop élevée"
          description: "La latence d'écriture P99 dépasse 500ms"

Erreurs courantes et dépannage

Erreur 1 : Timeout de lecture/écriture de Region

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

Étapes de dépannage :

# 1. Vérifier le statut des Region
tiup ctl:v8.5.1 pd -u http://10.0.1.1:2379 region check miss-peer

# 2. Vérifier la santé de TiKV
tiup ctl:v8.5.1 pd -u http://10.0.1.1:2379 store

# 3. Consulter les journaux lents
tiup cluster audit tidb-prod --limit 50

Erreur 2 : Conflit d'écriture

Error: Write conflict, txn start_ts conflicts with another txn

Solution :

-- Ajuster les paramètres de retry de transaction
SET @@tidb_retry_limit = 20;
SET @@tidb_txn_retry_interval = 100; -- millisecondes

-- Vérifier le taux de conflits
SELECT * FROM INFORMATION_SCHEMA.TIDB_TRX
  WHERE state = 'LockRcolliding' LIMIT 10;

Erreur 3 : OOM (Mémoire insuffisante)

Error: Out Of Memory Quota!

Solution :

-- Définir la limite mémoire de requête
SET @@tidb_mem_quota_query = 1073741824; -- 1GB

-- Activer le contrôle des ressources
CREATE RESOURCE GROUP rg_report
  RU_PER_SEC = 500
  PRIORITY = LOW;

-- Lier l'utilisateur au groupe de ressources
ALTER USER report_user RESOURCE GROUP rg_report;

Erreur 4 : Retard de synchronisation TiFlash

-- Vérifier la progression de la synchronisation
SELECT TABLE_ID, REPLICA_COUNT, PROGRESS, AVAILABLE
FROM INFORMATION_SCHEMA.TIFLASH_REPLICA_STATUS;

-- Vérifier l'état des nœuds TiFlash
SELECT * FROM INFORMATION_SCHEMA.TIFLASH_TABLES
  WHERE REPLICA_AVAILABLE = 0;

Migration de MySQL vers TiDB

Comparaison des solutions de migration

Solution Cas d'utilisation Temps d'indisponibilité Complexité
DM complet+incrémental Migration à grande échelle Quasi nul Moyenne
Dumpling + TiDB Lightning Migration ponctuelle Heures Faible
mysqldump + source Faible volume de données Heures Faible

Utilisation de la migration DM (recommandé)

# dm-task.yaml - Configuration de tâche de migration DM
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_*"

# Démarrer la tâche DM
dmctl start-task dm-task.yaml

# Vérifier le statut de la tâche
dmctl query-status mysql-to-tidb

# Vérifier la cohérence des données
dmctl check-task dm-task.yaml

Vérification de compatibilité pré-migration

-- Vérifier l'utilisation des procédures stockées
SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE
FROM information_schema.routines
WHERE ROUTINE_SCHEMA NOT IN ('mysql', 'sys');

-- Vérifier les contraintes de clés étrangères
SELECT TABLE_SCHEMA, TABLE_NAME, CONSTRAINT_NAME
FROM information_schema.table_constraints
WHERE CONSTRAINT_TYPE = 'FOREIGN KEY';

-- Vérifier les triggers
SELECT TRIGGER_SCHEMA, TRIGGER_NAME, EVENT_OBJECT_TABLE
FROM information_schema.triggers;

-- Vérifier les colonnes auto-incrémentées
SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, AUTO_INCREMENT
FROM information_schema.columns
WHERE EXTRA LIKE '%auto_increment%';

Benchmarks de performance

Benchmark TPCC

# Tester les performances OLTP avec TPCC
git clone https://github.com/pingcap/go-tpc.git
cd go-tpc

# Préparer les données
go-tpc tpcc prepare \
  --host 10.0.1.1 --port 4000 \
  --warehouses 1000 --threads 50

# Exécuter le benchmark
go-tpc tpcc run \
  --host 10.0.1.1 --port 4000 \
  --warehouses 1000 --threads 50 \
  --time 600s

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

Benchmark TPC-H (HTAP)

# Tester les performances OLAP avec TPC-H
go-tpc tpch prepare \
  --host 10.0.1.1 --port 4000 \
  --scale 100 --threads 10

# Forcer l'exécution sur TiFlash
go-tpc tpch run \
  --host 10.0.1.1 --port 4000 \
  --scale 100 --threads 10 \
  --time 300s \
  --engine tiflash

Référence de performance typique

Scénario Configuration des nœuds QPS/TPS Latence P99
OLTP (TPCC) 3×TiDB + 3×TiKV 15 000 TPS < 50ms
OLAP (TPC-H) + 2×TiFlash 22 requêtes/5min Variable selon la requête
HTAP mixte Configuration ci-dessus TP stable + AP 10x Indépendant

FAQ

Q1 : TiDB est-il adapté pour remplacer le sharding MySQL ?

Oui, c'est le cas d'utilisation le plus typique de TiDB. TiDB offre une mise à l'échelle horizontale transparente sans logique de sharding au niveau applicatif, tout en maintenant la compatibilité avec le protocole MySQL pour un coût de migration minimal. Fortement recommandé lorsqu'une table dépasse 50 millions de lignes ou que la complexité opérationnelle du sharding est trop élevée.

Q2 : Quel est le niveau d'isolation des transactions de TiDB ?

TiDB utilise par défaut le niveau d'isolation RC (Read Committed) (v6.0+), et supporte également la sémantique RR (Repeatable Read). Le RR de TiDB est en réalité une Snapshot Isolation (SI), qui empêche les lectures fantômes mais présente des différences subtiles avec le RR de MySQL dans certains scénarios (par exemple, le comportement de lecture courante).

Q3 : Quelle est l'échelle de données optimale pour TiDB ?

  • Table unique : De dizaines de millions à des dizaines de milliards de lignes ; TiDB recommandé au-delà de 50 millions de lignes
  • Données totales du cluster : Échelle de TB à PB
  • Taille de Region : Par défaut 96 Mo, recommandé de rester proche de cette valeur

Q4 : Comment choisir entre TiDB et CockroachDB ?

Dimension TiDB CockroachDB
Compatibilité SQL MySQL PostgreSQL
HTAP Support natif Non supporté
Communauté Principalement Chine/APAC Globale
Service cloud TiDB Cloud CockroachDB Cloud

Si votre stack est basée sur MySQL et nécessite HTAP, choisissez TiDB ; si elle est basée sur PostgreSQL et OLTP uniquement, choisissez CockroachDB.

Q5 : Comment gérer les grandes transactions dans TiDB ?

TiDB limite par défaut à 100 Mo et 5000 lignes par transaction. Solutions pour les grandes transactions :

-- Ajuster les limites de transaction (non recommandé de définir trop haut)
SET @@tidb_txn_entry_size_limit = 536870912;  -- 512MB
SET @@tidb_txn_total_size_limit = 1073741824; -- 1GB

-- Recommandé : commits par lots
-- Diviser les grandes transactions en petites dans l'application, 1000-5000 lignes par lot

Q6 : Quelle est la licence de TiDB ?

TiDB Server, TiKV et PD utilisent la licence Apache 2.0 entièrement open source. TiFlash est également open source depuis v8.0+. TiDB Cloud (Serverless/Dedicated) est un service commercial.

Résumé

TiDB est devenu le produit de référence dans l'espace des bases de données distribuées en 2026. Sa compatibilité MySQL, sa capacité HTAP et son architecture cloud-native en font le choix idéal pour la modernisation des bases de données d'entreprise. Points clés :

  1. Architecture : Quatre composants TiDB/TiKV/PD/TiFlash, séparation calcul-stockage
  2. Déploiement : Gestion en un clic avec TiUP, exigences SSD et réseau pour la production
  3. Réglage SQL : Utiliser EXPLAIN ANALYZE, maîtriser SPM pour la liaison de plans
  4. Conception d'index : Considérer les caractéristiques distribuées, éviter les index de points chauds
  5. Gestion des points chauds : Dispersion SHARD_ROW_ID_BITS, distribution Follower Read
  6. HTAP : Stockage en colonnes TiFlash + moteur MPP pour l'analyse en temps réel
  7. Reprise après sinistre : BR supporte les stratégies de restauration complète/incrémentale/PITR
  8. Surveillance : Système Grafana complet, les métriques clés ne doivent pas être ignorées
  9. Migration : La migration incrémentale DM permet une bascule avec une indisponibilité quasi nulle

Essayez ces outils exécutés localement dans le navigateur — aucune inscription requise →

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