Guía Práctica y Ajuste de TiDB: Base de Datos Distribuida

数据库

¿Por qué elegir TiDB en 2026?

TiDB, como base de datos distribuida HTAP (Procesamiento Híbrido Transaccional y Analítico) de nueva generación, se ha convertido en la solución predilecta para la actualización de bases de datos empresariales en 2026. Resuelve perfectamente el cuello de botella de máquina única y la complejidad del sharding de MySQL tradicional.

Ventajas Clave de TiDB

Dimensión TiDB Sharding MySQL CockroachDB Amazon Aurora
Escalado Horizontal transparente Sharding a nivel de aplicación Horizontal Vertical + escalado de lectura
Compatibilidad MySQL Muy alta (95%+) MySQL nativo Media Alta
HTAP Soporte nativo Requiere componentes adicionales No soportado Limitado
Complejidad operativa Media (TiUP) Alta Media Baja (gestionado)
Consistencia fuerte Protocolo Raft Nativo Protocolo Raft Limitada
Código abierto Completamente abierto - Código abierto Código cerrado

Hitos Clave de TiDB en 2026

  1. TiDB 8.x estable: Mejora de rendimiento del 40%+, soporta mayores volúmenes de datos
  2. Mejoras MPP de TiFlash: Análisis en tiempo real significativamente mejorado, más funciones de ventana
  3. TiDB Serverless: Modelo de pago por uso nativo en la nube, menor barrera de entrada
  4. Control de Recursos: Aislamiento de CPU/IO para escenarios multi-tenant
  5. Ordenamiento Global: Reduce drásticamente la sobrecarga en importaciones de datos a gran escala

Resumen de la Arquitectura de TiDB

TiDB adopta una arquitectura de separación computación-almacenamiento con cuatro componentes principales:

Responsabilidades de los Componentes

┌─────────────────────────────────────────────────────┐
│                    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: Capa de cálculo SQL sin estado, maneja el análisis, optimización y ejecución de SQL
  • PD (Placement Driver): Cerebro del clúster, gestiona la programación, metadatos y marcas de tiempo globales
  • TiKV: Motor de almacenamiento por filas basado en RocksDB + Raft, maneja lecturas/escrituras transaccionales
  • TiFlash: Motor de almacenamiento columnar basado en tecnología ClickHouse, maneja análisis en tiempo real

Mecanismo de Flujo de Datos

  1. Ruta de escritura: Cliente → TiDB → PD (obtener TSO) → TiKV (escritura Raft) → TiFlash (sincronización asíncrona)
  2. Ruta de lectura (OLTP): Cliente → TiDB → TiKV (escaneo puntual/rango)
  3. Ruta de lectura (OLAP): Cliente → TiDB → TiFlash (cálculo paralelo MPP)

💡 Usa la herramienta Formateador SQL para embellecer consultas SQL de TiDB y facilitar el análisis del plan de ejecución.

Desplegando TiDB con TiUP

TiUP es la herramienta oficial de gestión de clústeres de TiDB, que soporta despliegue, escalado y actualizaciones con un solo clic.

Configuración del Entorno

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

# Verificar instalación
tiup --version

Despliegue de Clúster de Prueba Mínimo

# topo.yaml - Configuración de topología mínima
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

# Desplegar clúster
tiup cluster deploy tidb-prod v8.5.1 topo.yaml

# Iniciar clúster
tiup cluster start tidb-prod

# Verificar estado del clúster
tiup cluster display tidb-prod

# Conectarse a TiDB
mysql -h 10.0.1.1 -P 4000 -u root

Esenciales para Despliegue en Producción

  1. Desplegar 3 nodos PD: Asegurar alta disponibilidad del planificador
  2. Desplegar al menos 3 nodos TiKV: Escritura por mayoría Raft
  3. Desplegar 2+ nodos TiDB: Balanceo de carga frontend
  4. Desplegar TiFlash de forma independiente: Evitar contención de I/O con TiKV
  5. Discos SSD: El directorio de datos de TiKV debe usar NVMe SSD
  6. Red: Latencia entre nodos < 0.5ms, ancho de banda ≥ 10Gbps

Lista de Compatibilidad MySQL

TiDB es altamente compatible con el protocolo MySQL 5.7 / 8.0, pero algunas diferencias requieren atención:

Funcionalidades Compatibles

Funcionalidad Soporte Notas
SELECT / INSERT / UPDATE / DELETE ✅ Completamente soportado
JOIN (todos los tipos) ✅ Completamente soportado
Subconsultas ✅ Completamente soportado
Funciones de ventana ✅ Completamente soportado TiDB 6.0+
CTE (Expresiones de Tabla Común) ✅ Completamente soportado TiDB 6.0+
Prepared Statement ✅ Completamente soportado
Tipo JSON ✅ Completamente soportado
UTF8 / UTF8MB4 ✅ Completamente soportado

Funcionalidades Incompatibles

Funcionalidad Estado Alternativa
Procedimientos almacenados ❌ No soportado Usar lógica de aplicación
Triggers ❌ No soportado Usar eventos de aplicación
Claves foráneas ⚠️ Solo sintaxis, no se aplican Asegurar consistencia en la aplicación
Sintaxis XA ⚠️ Soporte parcial Usar 2PC interno de TiDB
Continuidad de auto-incremento ⚠️ No garantizada Usar AUTO_ID_CACHE o secuencias
SAVEPOINT ✅ Soportado TiDB 6.2+
SELECT ... FOR UPDATE ⚠️ Bloqueo pesimista Debe habilitarse explícitamente

Script de Verificación de Compatibilidad

-- Verificar versión y compatibilidad de TiDB
SELECT tidb_version();

-- Verificar modo de transacción actual
SELECT @@tidb_txn_mode;

-- Verificar comportamiento de auto-incremento
SHOW VARIABLES LIKE 'auto_increment%';

-- Verificar soporte de conjuntos de caracteres
SHOW CHARACTER SET WHERE Charset LIKE '%utf%';

💡 Usa la herramienta Formateador JSON para validar estructuras de datos JSON en TiDB.

Optimización SQL y Análisis del Plan de Ejecución

EXPLAIN y EXPLAIN ANALYZE

TiDB proporciona herramientas ricas de análisis del plan de ejecución:

-- Ver plan de ejecución
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';

-- Ver estadísticas reales de ejecución (con tiempos, conteo de filas)
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';

Operadores Clave del Plan de Ejecución

Operador Significado Dirección de Optimización
TableFullScan Escaneo completo de tabla Agregar índice apropiado
IndexRangeScan Escaneo de rango por índice Ya es bueno, verificar costo de búsqueda en tabla
IndexLookUp Índice + búsqueda en tabla Considerar índice de cobertura
IndexReader Lectura de índice (sin búsqueda) Índice de cobertura, óptimo
HashJoin Join por hash Verificar tamaño de datos del lado Build
MergeJoin Join por mezcla Asegurar que ambos lados estén ordenados
IndexJoin Join anidado por índice Bueno para tabla pequeña que impulsa tabla grande
StreamAgg Agregación por flujo Ya es óptimo
HashAgg Agregación por hash Verificar cardinalidad de agrupación
TopN Ordenamiento TopN Ya es óptimo
Sort Ordenamiento completo Verificar si se puede usar el orden del índice

Ejemplos Prácticos de Ajuste SQL

-- Ejemplo 1: Evitar escaneo completo de tabla
-- Problema: Baja selectividad en status causa escaneo completo
EXPLAIN SELECT * FROM orders WHERE status = 'pending';
-- Solución: Agregar índice compuesto
ALTER TABLE orders ADD INDEX idx_status_date (status, order_date);

-- Ejemplo 2: Índice de cobertura para eliminar búsqueda en tabla
-- Problema: IndexLookUp tiene alto costo de búsqueda
EXPLAIN SELECT customer_id, order_date FROM orders WHERE status = 'shipped';
-- Solución: Índice de cobertura
ALTER TABLE orders ADD INDEX idx_cover (status, customer_id, order_date);

-- Ejemplo 3: Optimizar orden de JOIN
-- Problema: El lado Build del HashJoin es demasiado grande
EXPLAIN ANALYZE SELECT *
FROM order_items oi
JOIN products p ON oi.product_id = p.product_id
WHERE p.category = 'electronics';
-- Solución: Agregar índice en tabla impulsora + actualizar estadísticas
ANALYZE TABLE products;
ANALYZE TABLE order_items;

Gestión de Planes SQL (SPM)

-- Crear SQL Binding para fijar el plan óptimo
CREATE SESSION BINDING FOR
  SELECT * FROM orders WHERE status = 'shipped'
USING
  SELECT * FROM orders USE INDEX (idx_status_date) WHERE status = 'shipped';

-- Ver Bindings existentes
SHOW SESSION BINDINGS;

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

Estrategias de Índices Distribuidos

El diseño de índices en bases de datos distribuidas difiere significativamente de MySQL de máquina única, requiriendo consideración del costo entre Region y el riesgo de puntos calientes.

Principios de Diseño de Índices

  1. Reducir escaneos de Region: El prefijo del índice debe estar disperso para evitar concentración en pocas Region
  2. Controlar la cantidad de índices: Cada índice añade sobrecarga de escritura y almacenamiento
  3. Preferir índices compuestos: Reducir búsquedas en tabla, un índice compuesto reemplaza múltiples índices de una sola columna
  4. Evitar índices demasiado anchos: El ancho total de columnas del índice debe ser < 200 bytes
  5. Considerar ubicación del índice: TiDB soporta colocar índices en diferentes motores de almacenamiento

Estrategia de Ubicación de Índices (Placement Rules)

-- Colocar índice de datos fríos en almacenamiento HDD
ALTER TABLE orders ADD INDEX idx_create_time (create_time)
  PLACEMENT POLICY 'cold_storage';

-- Crear política de ubicación
CREATE PLACEMENT POLICY cold_storage LEADER_CONSTRAINTS '[+disk=hdd]' FOLLOWER_CONSTRAINTS '[+disk=hdd]';

Índices Invisibles

-- Crear índice invisible (sin impacto en consultas, solo mantenimiento en escritura)
ALTER TABLE orders ADD INDEX idx_test (customer_id) INVISIBLE;

-- Verificar que el índice es invisible
SHOW INDEXES FROM orders;

-- Establecer visible tras confirmar que no hay impacto en rendimiento
ALTER TABLE orders ALTER INDEX idx_test VISIBLE;

Diagnóstico y Resolución de Puntos Calientes

Los puntos calientes son el problema más común en bases de datos distribuidas, causando carga desigual en nodos específicos.

Identificación de Puntos Calientes

-- Ver distribución de Region de puntos calientes
SELECT STORE_ID, COUNT(*) AS region_count
FROM INFORMATION_SCHEMA.TIKV_REGION_STATUS
GROUP BY STORE_ID
ORDER BY region_count DESC;

-- Ver puntos calientes de escritura
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;

Escenarios Comunes de Puntos Calientes y Soluciones

Escenario 1: Punto Caliente por ID Auto-Incremental

-- Problema: AUTO_INCREMENT causa que las escrituras se concentren en una sola Region
CREATE TABLE logs (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  content TEXT,
  created_at TIMESTAMP
);

-- Solución 1: Usar SHARD_ROW_ID_BITS para dispersar
CREATE TABLE logs (
  id BIGINT AUTO_INCREMENT,
  content TEXT,
  created_at TIMESTAMP,
  PRIMARY KEY (id)
) SHARD_ROW_ID_BITS = 4;

-- Solución 2: Usar marca de tiempo como prefijo de clave primaria
CREATE TABLE logs (
  created_at TIMESTAMP,
  id BIGINT AUTO_INCREMENT,
  content TEXT,
  PRIMARY KEY (created_at, id)
) SHARD_ROW_ID_BITS = 4;

Escenario 2: Punto Caliente de Índice

-- Problema: Escrituras en índice de tiempo se concentran en la Region final
ALTER TABLE orders ADD INDEX idx_created (created_at);

-- Solución: Usar 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;

Escenario 3: Punto Caliente Completo en Tabla Pequeña

-- Problema: Datos de tabla pequeña en una sola Region, punto caliente de lectura de alta concurrencia
-- Solución: Usar Follower Read para distribuir la presión de lectura
SET @@tidb_replica_read = 'leader-and-follower';

-- O habilitar a nivel de sesión
SET SESSION tidb_replica_read = 'follower';

Optimización de Programación PD

# Ver configuración de programación actual
tiup ctl:v8.5.1 pd -u http://10.0.1.1:2379 config show all

# Ajustar parámetros de programación de puntos calientes
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

# Habilitar Region Merge para reducir Region vacías
tiup ctl:v8.5.1 pd -u http://10.0.0.1:2379 config set enable-merge-region true

Análisis en Tiempo Real con TiFlash en la Práctica

TiFlash es el motor de almacenamiento columnar de TiDB, que permite análisis OLAP en tiempo real sin ETL.

Habilitar Sincronización TiFlash

-- Habilitar sincronización TiFlash para toda la base de datos
ALTER DATABASE orders_db SET TIFLASH REPLICA 2;

-- Habilitar sincronización TiFlash para una sola tabla (2 réplicas)
ALTER TABLE orders SET TIFLASH REPLICA 2;

-- Verificar progreso de sincronización
SELECT * FROM INFORMATION_SCHEMA.TIFLASH_REPLICA_STATUS;

-- Sincronizar columnas específicas a TiFlash (reducir sobrecarga de sincronización)
ALTER TABLE orders SET TIFLASH REPLICA 1
  INCLUDE (order_id, customer_id, amount, order_date);

Consultas en Modo MPP

-- Forzar motor MPP de TiFlash
SET @@tidb_isolation_read_engines = 'tiflash';
SET @@tidb_enforce_mpp = 1;

-- Análisis de ventas en tiempo real
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;

-- Restaurar selección de motor predeterminada
SET @@tidb_isolation_read_engines = 'tidb,tikv,tiflash';
SET @@tidb_enforce_mpp = 0;

Enrutamiento Inteligente HTAP

-- TiDB enruta automáticamente: consultas pequeñas a TiKV, consultas grandes a TiFlash
-- No se necesita configuración manual, el optimizador decide automáticamente

-- Verificar qué motor usa realmente una consulta
EXPLAIN ANALYZE SELECT COUNT(*), SUM(amount)
FROM orders WHERE order_date >= '2026-01-01';
-- Observar si el operador contiene información de tiflash

Copia de Seguridad y Recuperación ante Desastres (BR)

BR (Backup & Restore) es la herramienta nativa de copia de seguridad y restauración distribuida de TiDB.

Copia de Seguridad y Restauración Completa

# Copia de seguridad completa a 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

# Restauración completa
tiup br:v8.5.1 restore full \
  --pd "10.0.1.1:2379" \
  --storage "s3://tidb-backup/full-20260611" \
  --s3.region "us-east-1"

Copia de Seguridad Incremental

# Copia de seguridad incremental (basada en el TS de la última copia)
tiup br:v8.5.1 backup full \
  --pd "10.0.1.1:2379" \
  --storage "s3://tidb-backup/incr-20260611" \
  --last-backup-ts 450335849738604544

Copia de Seguridad a Nivel de Base de Datos/Tabla

# Copia de seguridad a nivel de base de datos
tiup br:v8.5.1 backup db \
  --db "orders_db" \
  --pd "10.0.1.1:2379" \
  --storage "s3://tidb-backup/orders-db-20260611"

# Copia de seguridad a nivel de tabla
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"

Recuperación en un Punto en el Tiempo (PITR)

# Restaurar a un punto específico en el tiempo
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"

💡 Usa la herramienta Cifrado Hash para verificar las sumas de verificación de integridad de los datos de respaldo.

Sistema de Monitoreo Grafana

Los clústeres TiDB incluyen un sistema completo de monitoreo Prometheus + Grafana.

Dashboards de Monitoreo Clave

Dashboard Métricas Clave Sugerencia de Umbral de Alerta
TiDB Overview QPS, conexiones, consultas lentas Consulta lenta > 1s
TiKV Details CPU, IO, conteo de Region CPU > 80%
PD Details Tareas de programación, distribución de Region Retraso de programación > 5min
TiFlash Details Retraso de sincronización, conteo de tareas MPP Retraso de sincronización > 10s
BR Progreso de respaldo, duración Fallo de respaldo
Node Exporter Disco, memoria, red Uso de disco > 85%

Detalles de Métricas Clave

# Métricas clave de TiDB
tidb_server_query_duration:
  description: "Latencia de consulta P99"
  alert: "> 500ms por 5 minutos"

tidb_server_slow_query:
  description: "Conteo de consultas lentas"
  alert: "> 10/min"

tikv_grpc_message_duration:
  description: "Latencia de solicitud gRPC de TiKV"
  alert: "P99 > 200ms"

tikv_engine_write_bytes:
  description: "Rendimiento de escritura"
  monitoring: "Vigilar caídas repentinas"

pd_scheduler_balance_region:
  description: "Velocidad de programación de Region"
  alert: "Cero por más de 10 minutos"

tiflash_sync_apply_duration:
  description: "Retraso de sincronización de datos de TiFlash"
  alert: "P99 > 10s"

Reglas de Alerta Personalizadas

# Ejemplo de regla de alerta de 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 de TiDB demasiado alto"
          description: "El QPS actual supera 50000 durante 5 minutos"

      - 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: "Latencia de escritura de TiKV demasiado alta"
          description: "La latencia de escritura P99 supera 500ms"

Errores Comunes y Solución de Problemas

Error 1: Tiempo de Espera de Lectura/Escritura de Region

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

Pasos para la Solución de Problemas:

# 1. Verificar estado de Region
tiup ctl:v8.5.1 pd -u http://10.0.1.1:2379 region check miss-peer

# 2. Verificar salud de TiKV
tiup ctl:v8.5.1 pd -u http://10.0.1.1:2379 store

# 3. Ver logs lentos
tiup cluster audit tidb-prod --limit 50

Error 2: Conflicto de Escritura

Error: Write conflict, txn start_ts conflicts with another txn

Solución:

-- Ajustar parámetros de reintento de transacción
SET @@tidb_retry_limit = 20;
SET @@tidb_txn_retry_interval = 100; -- milisegundos

-- Verificar tasa de conflictos
SELECT * FROM INFORMATION_SCHEMA.TIDB_TRX
  WHERE state = 'LockRcolliding' LIMIT 10;

Error 3: OOM (Sin Memoria)

Error: Out Of Memory Quota!

Solución:

-- Establecer límite de memoria de consulta
SET @@tidb_mem_quota_query = 1073741824; -- 1GB

-- Habilitar control de recursos
CREATE RESOURCE GROUP rg_report
  RU_PER_SEC = 500
  PRIORITY = LOW;

-- Vincular usuario a grupo de recursos
ALTER USER report_user RESOURCE GROUP rg_report;

Error 4: Retraso de Sincronización de TiFlash

-- Verificar progreso de sincronización
SELECT TABLE_ID, REPLICA_COUNT, PROGRESS, AVAILABLE
FROM INFORMATION_SCHEMA.TIFLASH_REPLICA_STATUS;

-- Verificar estado de nodos TiFlash
SELECT * FROM INFORMATION_SCHEMA.TIFLASH_TABLES
  WHERE REPLICA_AVAILABLE = 0;

Migrando de MySQL a TiDB

Comparación de Soluciones de Migración

Solución Caso de Uso Tiempo de Inactividad Complejidad
DM completo+incremental Migración a gran escala Casi nulo Media
Dumpling + TiDB Lightning Migración única Horas Baja
mysqldump + source Volumen de datos pequeño Horas Baja

Usando Migración DM (Recomendado)

# dm-task.yaml - Configuración de tarea de migración 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_*"

# Iniciar tarea DM
dmctl start-task dm-task.yaml

# Verificar estado de la tarea
dmctl query-status mysql-to-tidb

# Verificar consistencia de datos
dmctl check-task dm-task.yaml

Verificación de Compatibilidad Pre-Migración

-- Verificar uso de procedimientos almacenados
SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE
FROM information_schema.routines
WHERE ROUTINE_SCHEMA NOT IN ('mysql', 'sys');

-- Verificar restricciones de claves foráneas
SELECT TABLE_SCHEMA, TABLE_NAME, CONSTRAINT_NAME
FROM information_schema.table_constraints
WHERE CONSTRAINT_TYPE = 'FOREIGN KEY';

-- Verificar triggers
SELECT TRIGGER_SCHEMA, TRIGGER_NAME, EVENT_OBJECT_TABLE
FROM information_schema.triggers;

-- Verificar columnas auto-incrementales
SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, AUTO_INCREMENT
FROM information_schema.columns
WHERE EXTRA LIKE '%auto_increment%';

Benchmarks de Rendimiento

Benchmark TPCC

# Probar rendimiento OLTP con TPCC
git clone https://github.com/pingcap/go-tpc.git
cd go-tpc

# Preparar datos
go-tpc tpcc prepare \
  --host 10.0.1.1 --port 4000 \
  --warehouses 1000 --threads 50

# Ejecutar benchmark
go-tpc tpcc run \
  --host 10.0.1.1 --port 4000 \
  --warehouses 1000 --threads 50 \
  --time 600s

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

Benchmark TPC-H (HTAP)

# Probar rendimiento OLAP con TPC-H
go-tpc tpch prepare \
  --host 10.0.1.1 --port 4000 \
  --scale 100 --threads 10

# Forzar ejecución en TiFlash
go-tpc tpch run \
  --host 10.0.1.1 --port 4000 \
  --scale 100 --threads 10 \
  --time 300s \
  --engine tiflash

Referencia de Rendimiento Típico

Escenario Configuración de Nodos QPS/TPS Latencia P99
OLTP (TPCC) 3×TiDB + 3×TiKV 15,000 TPS < 50ms
OLAP (TPC-H) + 2×TiFlash 22 consultas/5min Varía por consulta
HTAP Mixto Configuración anterior TP estable + AP 10x Independiente

Preguntas Frecuentes

P1: ¿Es TiDB adecuado para reemplazar el sharding de MySQL?

Sí, este es el caso de uso más típico de TiDB. TiDB proporciona escalado horizontal transparente sin lógica de sharding a nivel de aplicación, manteniendo compatibilidad con el protocolo MySQL para un costo mínimo de migración. Altamente recomendado cuando una tabla supera los 50 millones de filas o la complejidad operativa del sharding es demasiado alta.

P2: ¿Cuál es el nivel de aislamiento de transacciones de TiDB?

TiDB usa por defecto el nivel de aislamiento RC (Read Committed) (v6.0+), y también soporta la semántica RR (Repeatable Read). El RR de TiDB es en realidad Snapshot Isolation (SI), que previene lecturas fantasma pero tiene diferencias sutiles con el RR de MySQL en escenarios específicos (por ejemplo, comportamiento de lectura actual).

P3: ¿Cuál es la escala de datos óptima para TiDB?

  • Tabla única: De decenas de millones a decenas de miles de millones de filas; se recomienda TiDB al superar los 50 millones de filas
  • Datos totales del clúster: Escala de TB a PB
  • Tamaño de Region: Por defecto 96MB, se recomienda mantener cerca de este valor

P4: ¿Cómo elegir entre TiDB y CockroachDB?

Dimensión TiDB CockroachDB
Compatibilidad SQL MySQL PostgreSQL
HTAP Soporte nativo No soportado
Comunidad Principalmente China/APAC Global
Servicio en la nube TiDB Cloud CockroachDB Cloud

Si tu stack está basado en MySQL y necesitas HTAP, elige TiDB; si está basado en PostgreSQL y solo OLTP, elige CockroachDB.

P5: ¿Cómo manejar transacciones grandes en TiDB?

TiDB tiene por defecto 100MB y 5000 filas por transacción. Soluciones para transacciones grandes:

-- Ajustar límites de transacción (no se recomienda establecer valores demasiado altos)
SET @@tidb_txn_entry_size_limit = 536870912;  -- 512MB
SET @@tidb_txn_total_size_limit = 1073741824; -- 1GB

-- Recomendado: commits por lotes
-- Dividir transacciones grandes en pequeñas en la aplicación, 1000-5000 filas por lote

P6: ¿Cuál es la Licencia de TiDB?

TiDB Server, TiKV y PD usan Apache 2.0 completamente de código abierto. TiFlash también es de código abierto desde v8.0+. TiDB Cloud (Serverless/Dedicated) es un servicio comercial.

Resumen

TiDB se ha convertido en el producto de referencia en el espacio de bases de datos distribuidas en 2026. Su compatibilidad MySQL, capacidad HTAP y arquitectura nativa en la nube lo convierten en la opción ideal para la actualización de bases de datos empresariales. Puntos clave:

  1. Arquitectura: Cuatro componentes TiDB/TiKV/PD/TiFlash, separación computación-almacenamiento
  2. Despliegue: Gestión con un clic de TiUP, requisitos de SSD y red para producción
  3. Ajuste SQL: Usar EXPLAIN ANALYZE, dominar SPM para vinculación de planes
  4. Diseño de índices: Considerar características distribuidas, evitar índices de puntos calientes
  5. Gestión de puntos calientes: Dispersión con SHARD_ROW_ID_BITS, distribución con Follower Read
  6. HTAP: Almacenamiento columnar TiFlash + motor MPP para análisis en tiempo real
  7. Recuperación ante desastres: BR soporta estrategias de recuperación completa/incremental/PITR
  8. Monitoreo: Sistema Grafana completo, las métricas clave no deben ignorarse
  9. Migración: La migración incremental con DM logra una transición con tiempo de inactividad casi nulo

Prueba estas herramientas que se ejecutan en tu navegador — no requieren registro →

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