Guia de Ajuste e Prática do Banco de Dados Distribuído TiDB

数据库

Por que Escolher TiDB em 2026?

O TiDB, como banco de dados distribuído HTAP (Processamento Híbrido Transacional e Analítico) de nova geração, tornou-se a solução ideal para atualizações de bancos de dados empresariais em 2026. Ele resolve perfeitamente o gargalo de máquina única e a complexidade de sharding do MySQL tradicional.

Vantagens Principais do TiDB

Dimensão TiDB Sharding MySQL CockroachDB Amazon Aurora
Escalabilidade Horizontal transparente Sharding em nível de aplicação Horizontal Vertical + escalabilidade de leitura
Compatibilidade MySQL Muito alta (95%+) MySQL nativo Média Alta
HTAP Suporte nativo Necessita componentes extras Não suportado Limitado
Complexidade operacional Média (TiUP) Alta Média Baixa (gerenciado)
Consistência forte Protocolo Raft Nativo Protocolo Raft Limitada
Código aberto Totalmente aberto - Código aberto Código fechado

Marcos Principais do TiDB em 2026

  1. TiDB 8.x estável: Melhoria de desempenho de 40%+, suporta maiores volumes de dados
  2. Aprimoramentos MPP do TiFlash: Análise em tempo real significativamente melhorada, mais funções de janela
  3. TiDB Serverless: Modelo de pagamento por uso nativo na nuvem, menor barreira de entrada
  4. Controle de Recursos: Isolamento de CPU/IO para cenários multi-tenant
  5. Ordenação Global: Reduz drasticamente a sobrecarga em importações de dados em larga escala

Visão Geral da Arquitetura do TiDB

O TiDB adota uma arquitetura de separação computação-armazenamento com quatro componentes principais:

Responsabilidades dos 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: Camada de computação SQL sem estado, gerencia análise, otimização e execução de SQL
  • PD (Placement Driver): Cérebro do cluster, gerencia agendamento, metadados e timestamps globais
  • TiKV: Motor de armazenamento por linhas baseado em RocksDB + Raft, gerencia leituras/escritas transacionais
  • TiFlash: Motor de armazenamento colunar baseado em tecnologia ClickHouse, gerencia análise em tempo real

Mecanismo de Fluxo de Dados

  1. Caminho de escrita: Cliente → TiDB → PD (obter TSO) → TiKV (escrita Raft) → TiFlash (sincronização assíncrona)
  2. Caminho de leitura (OLTP): Cliente → TiDB → TiKV (escaneamento pontual/por intervalo)
  3. Caminho de leitura (OLAP): Cliente → TiDB → TiFlash (computação paralela MPP)

💡 Use a ferramenta Formatador SQL para embelezar consultas SQL do TiDB e facilitar a análise do plano de execução.

Implantando TiDB com TiUP

O TiUP é a ferramenta oficial de gerenciamento de clusters do TiDB, suportando implantação, escalabilidade e atualizações com um clique.

Configuração do Ambiente

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

# Verificar instalação
tiup --version

Implantação de Cluster de Teste Mínimo

# topo.yaml - Configuração de topologia 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

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

# Iniciar cluster
tiup cluster start tidb-prod

# Verificar status do cluster
tiup cluster display tidb-prod

# Conectar ao TiDB
mysql -h 10.0.1.1 -P 4000 -u root

Essenciais para Implantação em Produção

  1. Implantar 3 nós PD: Garantir alta disponibilidade do agendador
  2. Implantar pelo menos 3 nós TiKV: Escrita por maioria Raft
  3. Implantar 2+ nós TiDB: Balanceamento de carga frontend
  4. Implantar TiFlash independentemente: Evitar contenção de I/O com TiKV
  5. Discos SSD: O diretório de dados do TiKV deve usar NVMe SSD
  6. Rede: Latência entre nós < 0.5ms, largura de banda ≥ 10Gbps

Lista de Compatibilidade MySQL

O TiDB é altamente compatível com o protocolo MySQL 5.7 / 8.0, mas algumas diferenças requerem atenção:

Funcionalidades Compatíveis

Funcionalidade Suporte Observações
SELECT / INSERT / UPDATE / DELETE ✅ Totalmente suportado
JOIN (todos os tipos) ✅ Totalmente suportado
Subconsultas ✅ Totalmente suportado
Funções de janela ✅ Totalmente suportado TiDB 6.0+
CTE (Expressões de Tabela Comum) ✅ Totalmente suportado TiDB 6.0+
Prepared Statement ✅ Totalmente suportado
Tipo JSON ✅ Totalmente suportado
UTF8 / UTF8MB4 ✅ Totalmente suportado

Funcionalidades Incompatíveis

Funcionalidade Status Alternativa
Procedimentos armazenados ❌ Não suportado Usar lógica da aplicação
Triggers ❌ Não suportado Usar eventos da aplicação
Chaves estrangeiras ⚠️ Apenas sintaxe, não aplicadas Garantir consistência na aplicação
Sintaxe XA ⚠️ Suporte parcial Usar 2PC interno do TiDB
Continuidade de auto-incremento ⚠️ Não garantida Usar AUTO_ID_CACHE ou sequências
SAVEPOINT ✅ Suportado TiDB 6.2+
SELECT ... FOR UPDATE ⚠️ Bloqueio pessimista Deve ser habilitado explicitamente

Script de Verificação de Compatibilidade

-- Verificar versão e compatibilidade do TiDB
SELECT tidb_version();

-- Verificar modo de transação atual
SELECT @@tidb_txn_mode;

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

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

💡 Use a ferramenta Formatador JSON para validar estruturas de dados JSON do TiDB.

Otimização SQL e Análise do Plano de Execução

EXPLAIN e EXPLAIN ANALYZE

O TiDB fornece ferramentas ricas de análise do plano de execução:

-- Visualizar plano de execução
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';

-- Visualizar estatísticas reais de execução (com tempos, contagem de linhas)
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 Chave do Plano de Execução

Operador Significado Direção de Otimização
TableFullScan Escaneamento completo de tabela Adicionar índice apropriado
IndexRangeScan Escaneamento de intervalo por índice Já está bom, verificar custo de busca na tabela
IndexLookUp Índice + busca na tabela Considerar índice de cobertura
IndexReader Leitura de índice (sem busca) Índice de cobertura, ótimo
HashJoin Join por hash Verificar tamanho dos dados do lado Build
MergeJoin Join por mesclagem Garantir que ambos os lados estejam ordenados
IndexJoin Join aninhado por índice Bom para tabela pequena direcionando tabela grande
StreamAgg Agregação por fluxo Já está ótimo
HashAgg Agregação por hash Verificar cardinalidade de agrupamento
TopN Ordenação TopN Já está ótimo
Sort Ordenação completa Verificar se a ordem do índice pode ser usada

Exemplos Práticos de Ajuste SQL

-- Exemplo 1: Evitar escaneamento completo de tabela
-- Problema: Baixa seletividade em status causa escaneamento completo
EXPLAIN SELECT * FROM orders WHERE status = 'pending';
-- Solução: Adicionar índice composto
ALTER TABLE orders ADD INDEX idx_status_date (status, order_date);

-- Exemplo 2: Índice de cobertura para eliminar busca na tabela
-- Problema: IndexLookUp tem alto custo de busca
EXPLAIN SELECT customer_id, order_date FROM orders WHERE status = 'shipped';
-- Solução: Índice de cobertura
ALTER TABLE orders ADD INDEX idx_cover (status, customer_id, order_date);

-- Exemplo 3: Otimizar ordem de JOIN
-- Problema: Lado Build do HashJoin muito grande
EXPLAIN ANALYZE SELECT *
FROM order_items oi
JOIN products p ON oi.product_id = p.product_id
WHERE p.category = 'electronics';
-- Solução: Adicionar índice na tabela direcionadora + atualizar estatísticas
ANALYZE TABLE products;
ANALYZE TABLE order_items;

Gerenciamento de Planos SQL (SPM)

-- Criar SQL Binding para fixar o plano ótimo
CREATE SESSION BINDING FOR
  SELECT * FROM orders WHERE status = 'shipped'
USING
  SELECT * FROM orders USE INDEX (idx_status_date) WHERE status = 'shipped';

-- Visualizar Bindings existentes
SHOW SESSION BINDINGS;

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

Estratégias de Índices Distribuídos

O design de índices em bancos de dados distribuídos difere significativamente do MySQL de máquina única, exigindo consideração do custo entre Region e do risco de hotspots.

Princípios de Design de Índices

  1. Reduzir escaneamentos de Region: O prefixo do índice deve estar disperso para evitar concentração em poucas Region
  2. Controlar quantidade de índices: Cada índice adiciona sobrecarga de escrita e armazenamento
  3. Preferir índices compostos: Reduzir buscas na tabela, um índice composto substitui múltiplos índices de coluna única
  4. Evitar índices muito largos: A largura total das colunas do índice deve ser < 200 bytes
  5. Considerar posicionamento do índice: O TiDB suporta colocar índices em diferentes motores de armazenamento

Estratégia de Posicionamento de Índices (Placement Rules)

-- Colocar índice de dados frios em armazenamento HDD
ALTER TABLE orders ADD INDEX idx_create_time (create_time)
  PLACEMENT POLICY 'cold_storage';

-- Criar política de posicionamento
CREATE PLACEMENT POLICY cold_storage LEADER_CONSTRAINTS '[+disk=hdd]' FOLLOWER_CONSTRAINTS '[+disk=hdd]';

Índices Invisíveis

-- Criar índice invisível (sem impacto em consultas, apenas manutenção em escrita)
ALTER TABLE orders ADD INDEX idx_test (customer_id) INVISIBLE;

-- Verificar que o índice é invisível
SHOW INDEXES FROM orders;

-- Tornar visível após confirmar que não há impacto no desempenho
ALTER TABLE orders ALTER INDEX idx_test VISIBLE;

Diagnóstico e Resolução de Hotspots

Hotspots são o problema mais comum em bancos de dados distribuídos, causando carga desigual em nós específicos.

Identificação de Hotspots

-- Visualizar distribuição de Region de hotspots
SELECT STORE_ID, COUNT(*) AS region_count
FROM INFORMATION_SCHEMA.TIKV_REGION_STATUS
GROUP BY STORE_ID
ORDER BY region_count DESC;

-- Visualizar hotspots de escrita
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;

Cenários Comuns de Hotspots e Soluções

Cenário 1: Hotspot por ID Auto-Incremental

-- Problema: AUTO_INCREMENT faz as escritas se concentrarem em uma única Region
CREATE TABLE logs (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  content TEXT,
  created_at TIMESTAMP
);

-- Solução 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;

-- Solução 2: Usar timestamp como prefixo da chave primária
CREATE TABLE logs (
  created_at TIMESTAMP,
  id BIGINT AUTO_INCREMENT,
  content TEXT,
  PRIMARY KEY (created_at, id)
) SHARD_ROW_ID_BITS = 4;

Cenário 2: Hotspot de Índice

-- Problema: Escritas em índice de tempo se concentram na Region final
ALTER TABLE orders ADD INDEX idx_created (created_at);

-- Solução: 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;

Cenário 3: Hotspot Completo em Tabela Pequena

-- Problema: Dados de tabela pequena em uma única Region, hotspot de leitura de alta concorrência
-- Solução: Usar Follower Read para distribuir a pressão de leitura
SET @@tidb_replica_read = 'leader-and-follower';

-- Ou habilitar em nível de sessão
SET SESSION tidb_replica_read = 'follower';

Otimização de Agendamento PD

# Visualizar configuração de agendamento atual
tiup ctl:v8.5.1 pd -u http://10.0.1.1:2379 config show all

# Ajustar parâmetros de agendamento de hotspots
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 reduzir Regions vazias
tiup ctl:v8.5.1 pd -u http://10.0.0.1:2379 config set enable-merge-region true

Análise em Tempo Real com TiFlash na Prática

O TiFlash é o motor de armazenamento colunar do TiDB, permitindo análise OLAP em tempo real sem ETL.

Habilitar Sincronização TiFlash

-- Habilitar sincronização TiFlash para todo o banco de dados
ALTER DATABASE orders_db SET TIFLASH REPLICA 2;

-- Habilitar sincronização TiFlash para uma única tabela (2 réplicas)
ALTER TABLE orders SET TIFLASH REPLICA 2;

-- Verificar progresso da sincronização
SELECT * FROM INFORMATION_SCHEMA.TIFLASH_REPLICA_STATUS;

-- Sincronizar colunas específicas para TiFlash (reduzir sobrecarga de sincronização)
ALTER TABLE orders SET TIFLASH REPLICA 1
  INCLUDE (order_id, customer_id, amount, order_date);

Consultas em Modo MPP

-- Forçar motor MPP do TiFlash
SET @@tidb_isolation_read_engines = 'tiflash';
SET @@tidb_enforce_mpp = 1;

-- Análise de vendas em tempo 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 seleção de motor padrão
SET @@tidb_isolation_read_engines = 'tidb,tikv,tiflash';
SET @@tidb_enforce_mpp = 0;

Roteamento Inteligente HTAP

-- O TiDB roteia automaticamente: consultas pequenas para TiKV, consultas grandes para TiFlash
-- Não é necessária configuração manual, o otimizador decide automaticamente

-- Verificar qual motor uma consulta realmente usa
EXPLAIN ANALYZE SELECT COUNT(*), SUM(amount)
FROM orders WHERE order_date >= '2026-01-01';
-- Observar se o operador contém informações do tiflash

Backup e Recuperação de Desastres (BR)

O BR (Backup & Restore) é a ferramenta nativa de backup e restauração distribuída do TiDB.

Backup e Restauração Completa

# Backup completo para 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

# Restauração 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"

Backup Incremental

# Backup incremental (baseado no TS do último backup)
tiup br:v8.5.1 backup full \
  --pd "10.0.1.1:2379" \
  --storage "s3://tidb-backup/incr-20260611" \
  --last-backup-ts 450335849738604544

Backup em Nível de Banco de Dados/Tabela

# Backup em nível de banco de dados
tiup br:v8.5.1 backup db \
  --db "orders_db" \
  --pd "10.0.1.1:2379" \
  --storage "s3://tidb-backup/orders-db-20260611"

# Backup em nível de tabela
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"

Recuperação em um Ponto no Tempo (PITR)

# Restaurar para um ponto específico no tempo
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"

💡 Use a ferramenta Criptografia Hash para verificar os checksums de integridade dos dados de backup.

Sistema de Monitoramento Grafana

Os clusters TiDB vêm com um sistema completo de monitoramento Prometheus + Grafana.

Dashboards de Monitoramento Principais

Dashboard Métricas Chave Sugestão de Limiar de Alerta
TiDB Overview QPS, conexões, consultas lentas Consulta lenta > 1s
TiKV Details CPU, IO, contagem de Region CPU > 80%
PD Details Tarefas de agendamento, distribuição de Region Atraso de agendamento > 5min
TiFlash Details Atraso de sincronização, contagem de tarefas MPP Atraso de sincronização > 10s
BR Progresso do backup, duração Falha no backup
Node Exporter Disco, memória, rede Uso de disco > 85%

Detalhes das Métricas Chave

# Métricas chave do TiDB
tidb_server_query_duration:
  description: "Latência de consulta P99"
  alert: "> 500ms por 5 minutos"

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

tikv_grpc_message_duration:
  description: "Latência de requisição gRPC do TiKV"
  alert: "P99 > 200ms"

tikv_engine_write_bytes:
  description: "Throughput de escrita"
  monitoring: "Observar quedas repentinas"

pd_scheduler_balance_region:
  description: "Velocidade de agendamento de Region"
  alert: "Zero por mais de 10 minutos"

tiflash_sync_apply_duration:
  description: "Atraso de sincronização de dados do TiFlash"
  alert: "P99 > 10s"

Regras de Alerta Personalizadas

# Exemplo de regra de alerta do 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 do TiDB muito alto"
          description: "O QPS atual excede 50000 por 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: "Latência de escrita do TiKV muito alta"
          description: "A latência de escrita P99 excede 500ms"

Erros Comuns e Solução de Problemas

Erro 1: Timeout de Leitura/Escrita de Region

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

Passos para Solução de Problemas:

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

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

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

Erro 2: Conflito de Escrita

Error: Write conflict, txn start_ts conflicts with another txn

Solução:

-- Ajustar parâmetros de retry de transação
SET @@tidb_retry_limit = 20;
SET @@tidb_txn_retry_interval = 100; -- milissegundos

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

Erro 3: OOM (Sem Memória)

Error: Out Of Memory Quota!

Solução:

-- Definir limite de memória de consulta
SET @@tidb_mem_quota_query = 1073741824; -- 1GB

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

-- Vincular usuário ao grupo de recursos
ALTER USER report_user RESOURCE GROUP rg_report;

Erro 4: Atraso de Sincronização do TiFlash

-- Verificar progresso da sincronização
SELECT TABLE_ID, REPLICA_COUNT, PROGRESS, AVAILABLE
FROM INFORMATION_SCHEMA.TIFLASH_REPLICA_STATUS;

-- Verificar status dos nós TiFlash
SELECT * FROM INFORMATION_SCHEMA.TIFLASH_TABLES
  WHERE REPLICA_AVAILABLE = 0;

Migrando do MySQL para o TiDB

Comparação de Soluções de Migração

Solução Caso de Uso Tempo de Indisponibilidade Complexidade
DM completo+incremental Migração em larga escala Quase zero Média
Dumpling + TiDB Lightning Migração única Horas Baixa
mysqldump + source Pequeno volume de dados Horas Baixa

Usando Migração DM (Recomendado)

# dm-task.yaml - Configuração de tarefa de migração 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 tarefa DM
dmctl start-task dm-task.yaml

# Verificar status da tarefa
dmctl query-status mysql-to-tidb

# Verificar consistência dos dados
dmctl check-task dm-task.yaml

Verificação de Compatibilidade Pré-Migração

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

-- Verificar restrições de chaves estrangeiras
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 colunas auto-incrementais
SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, AUTO_INCREMENT
FROM information_schema.columns
WHERE EXTRA LIKE '%auto_increment%';

Benchmarks de Desempenho

Benchmark TPCC

# Testar desempenho OLTP com TPCC
git clone https://github.com/pingcap/go-tpc.git
cd go-tpc

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

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

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

Benchmark TPC-H (HTAP)

# Testar desempenho OLAP com TPC-H
go-tpc tpch prepare \
  --host 10.0.1.1 --port 4000 \
  --scale 100 --threads 10

# Forçar execução no TiFlash
go-tpc tpch run \
  --host 10.0.1.1 --port 4000 \
  --scale 100 --threads 10 \
  --time 300s \
  --engine tiflash

Referência de Desempenho Típico

Cenário Configuração de Nós QPS/TPS Latência P99
OLTP (TPCC) 3×TiDB + 3×TiKV 15,000 TPS < 50ms
OLAP (TPC-H) + 2×TiFlash 22 consultas/5min Varia por consulta
HTAP Misto Configuração acima TP estável + AP 10x Independente

Perguntas Frequentes

P1: O TiDB é adequado para substituir o sharding do MySQL?

Sim, este é o caso de uso mais típico do TiDB. O TiDB fornece escalabilidade horizontal transparente sem lógica de sharding em nível de aplicação, mantendo compatibilidade com o protocolo MySQL para custo mínimo de migração. Altamente recomendado quando uma tabela excede 50 milhões de linhas ou a complexidade operacional do sharding é muito alta.

P2: Qual é o nível de isolamento de transações do TiDB?

O TiDB usa por padrão o nível de isolamento RC (Read Committed) (v6.0+), e também suporta a semântica RR (Repeatable Read). O RR do TiDB é na verdade Snapshot Isolation (SI), que previne leituras fantasma mas tem diferenças sutis em relação ao RR do MySQL em cenários específicos (por exemplo, comportamento de leitura atual).

P3: Qual é a escala de dados ideal para o TiDB?

  • Tabela única: De dezenas de milhões a dezenas de bilhões de linhas; recomenda-se TiDB ao exceder 50 milhões de linhas
  • Dados totais do cluster: Escala de TB a PB
  • Tamanho de Region: Padrão 96MB, recomenda-se manter próximo a este valor

P4: Como escolher entre TiDB e CockroachDB?

Dimensão TiDB CockroachDB
Compatibilidade SQL MySQL PostgreSQL
HTAP Suporte nativo Não suportado
Comunidade Principalmente China/APAC Global
Serviço em nuvem TiDB Cloud CockroachDB Cloud

Se sua stack é baseada em MySQL e precisa de HTAP, escolha TiDB; se é baseada em PostgreSQL e apenas OLTP, escolha CockroachDB.

P5: Como lidar com transações grandes no TiDB?

O TiDB tem por padrão 100MB e 5000 linhas por transação. Soluções para transações grandes:

-- Ajustar limites de transação (não recomendado definir valores muito altos)
SET @@tidb_txn_entry_size_limit = 536870912;  -- 512MB
SET @@tidb_txn_total_size_limit = 1073741824; -- 1GB

-- Recomendado: commits em lote
-- Dividir transações grandes em pequenas na aplicação, 1000-5000 linhas por lote

P6: Qual é a Licença do TiDB?

O TiDB Server, TiKV e PD usam Apache 2.0 totalmente de código aberto. O TiFlash também é de código aberto desde v8.0+. O TiDB Cloud (Serverless/Dedicated) é um serviço comercial.

Resumo

O TiDB tornou-se o produto de referência no espaço de bancos de dados distribuídos em 2026. Sua compatibilidade MySQL, capacidade HTAP e arquitetura nativa na nuvem fazem dele a escolha ideal para atualizações de bancos de dados empresariais. Pontos principais:

  1. Arquitetura: Quatro componentes TiDB/TiKV/PD/TiFlash, separação computação-armazenamento
  2. Implantação: Gerenciamento com um clique do TiUP, requisitos de SSD e rede para produção
  3. Ajuste SQL: Usar EXPLAIN ANALYZE, dominar SPM para vinculação de planos
  4. Design de índices: Considerar características distribuídas, evitar índices de hotspots
  5. Gerenciamento de hotspots: Dispersão com SHARD_ROW_ID_BITS, distribuição com Follower Read
  6. HTAP: Armazenamento colunar TiFlash + motor MPP para análise em tempo real
  7. Recuperação de desastres: BR suporta estratégias de recuperação completa/incremental/PITR
  8. Monitoramento: Sistema Grafana completo, métricas chave não devem ser ignoradas
  9. Migração: Migração incremental com DM alcanha transição com indisponibilidade quase zero

Experimente estas ferramentas executadas localmente no navegador — nenhum cadastro necessário →

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