Руководство по настройке и практике распределённой базы данных TiDB

数据库

Почему стоит выбрать TiDB в 2026 году?

TiDB, как распределённая база данных HTAP (гибридная транзакционная и аналитическая обработка) нового поколения, стала основным решением для модернизации корпоративных баз данных в 2026 году. Она идеально решает проблему узкого места одиночного сервера и сложность шардинга традиционного MySQL.

Ключевые преимущества TiDB

Измерение TiDB Шардинг MySQL CockroachDB Amazon Aurora
Масштабирование Прозрачное горизонтальное Шардинг на уровне приложения Горизонтальное Вертикальное + масштабирование чтения
Совместимость с MySQL Очень высокая (95%+) Нативный MySQL Средняя Высокая
HTAP Нативная поддержка Требуются дополнительные компоненты Не поддерживается Ограниченная
Операционная сложность Средняя (TiUP) Высокая Средняя Низкая (управляемая)
Строгая согласованность Протокол Raft Нативная Протокол Raft Ограниченная
Открытый исходный код Полностью открытый - Открытый Закрытый

Ключевые вехи TiDB в 2026 году

  1. TiDB 8.x стабильная: Улучшение производительности на 40%+, поддержка больших объёмов данных
  2. Улучшения MPP в TiFlash: Значительно улучшена аналитика в реальном времени, больше оконных функций
  3. Serverless TiDB: Облачная модель оплаты по факту использования, более низкий порог входа
  4. Управление ресурсами: Изоляция CPU/IO для мультитенантных сценариев
  5. Глобальная сортировка: Резко снижает накладные расходы при крупномасштабном импорте данных

Обзор архитектуры TiDB

TiDB использует архитектуру разделения вычислений и хранения с четырьмя основными компонентами:

Ответственность компонентов

┌─────────────────────────────────────────────────────┐
│                    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: Слой SQL-вычислений без состояния, обрабатывает разбор, оптимизацию и выполнение SQL
  • PD (Placement Driver): Мозг кластера, управляет планированием, метаданными и глобальными временными метками
  • TiKV: Система хранения по строкам на основе RocksDB + Raft, обрабатывает транзакционные чтение/запись
  • TiFlash: Система столбцового хранения на основе технологии ClickHouse, обрабатывает аналитику в реальном времени

Механизм потока данных

  1. Путь записи: Клиент → TiDB → PD (получить TSO) → TiKV (запись Raft) → TiFlash (асинхронная синхронизация)
  2. Путь чтения (OLTP): Клиент → TiDB → TiKV (точечное/диапазонное сканирование)
  3. Путь чтения (OLAP): Клиент → TiDB → TiFlash (параллельные вычисления MPP)

💡 Используйте инструмент Форматирование SQL для форматирования SQL-запросов TiDB и упрощения анализа плана выполнения.

Развёртывание TiDB с помощью TiUP

TiUP — официальный инструмент управления кластером TiDB, поддерживающий развёртывание, масштабирование и обновления в один клик.

Настройка окружения

# Установить TiUP
curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh
source ~/.bash_profile

# Проверить установку
tiup --version

Минимальное развёртывание тестового кластера

# topo.yaml - Минимальная конфигурация топологии
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

# Развёртывание кластера
tiup cluster deploy tidb-prod v8.5.1 topo.yaml

# Запуск кластера
tiup cluster start tidb-prod

# Проверка состояния кластера
tiup cluster display tidb-prod

# Подключение к TiDB
mysql -h 10.0.1.1 -P 4000 -u root

Основные требования для промышленного развёртывания

  1. Развёртывание 3 узлов PD: Обеспечение высокой доступности планировщика
  2. Развёртывание минимум 3 узлов TiKV: Запись большинством Raft
  3. Развёртывание 2+ узлов TiDB: Балансировка нагрузки фронтенда
  4. Развёртывание TiFlash отдельно: Предотвращение конкуренции за I/O с TiKV
  5. SSD-диски: Каталог данных TiKV должен использовать NVMe SSD
  6. Сеть: Задержка между узлами < 0.5 мс, пропускная способность ≥ 10 Гбит/с

Контрольный список совместимости MySQL

TiDB обладает высокой совместимостью с протоколом MySQL 5.7 / 8.0, но некоторые различия требуют внимания:

Совместимые функции

Функция Поддержка Примечания
SELECT / INSERT / UPDATE / DELETE ✅ Полностью поддерживается
JOIN (все типы) ✅ Полностью поддерживается
Подзапросы ✅ Полностью поддерживается
Оконные функции ✅ Полностью поддерживается TiDB 6.0+
CTE (обобщённые табличные выражения) ✅ Полностью поддерживается TiDB 6.0+
Prepared Statement ✅ Полностью поддерживается
Тип JSON ✅ Полностью поддерживается
UTF8 / UTF8MB4 ✅ Полностью поддерживается

Несовместимые функции

Функция Статус Альтернатива
Хранимые процедуры ❌ Не поддерживается Использовать логику приложения
Триггеры ❌ Не поддерживается Использовать события приложения
Внешние ключи ⚠️ Только синтаксис, не применяется Обеспечивать целостность в приложении
Синтаксис XA ⚠️ Частичная поддержка Использовать внутренний 2PC TiDB
Непрерывность auto-increment ⚠️ Не гарантируется Использовать AUTO_ID_CACHE или последовательности
SAVEPOINT ✅ Поддерживается TiDB 6.2+
SELECT ... FOR UPDATE ⚠️ Пессимистичная блокировка Необходимо явно включить

Скрипт проверки совместимости

-- Проверить версию и совместимость TiDB
SELECT tidb_version();

-- Проверить текущий режим транзакций
SELECT @@tidb_txn_mode;

-- Проверить поведение auto-increment
SHOW VARIABLES LIKE 'auto_increment%';

-- Проверить поддержку кодировок
SHOW CHARACTER SET WHERE Charset LIKE '%utf%';

💡 Используйте инструмент Форматирование JSON для проверки структур данных JSON в TiDB.

Оптимизация SQL и анализ плана выполнения

EXPLAIN и EXPLAIN ANALYZE

TiDB предоставляет богатые инструменты анализа плана выполнения:

-- Просмотр плана выполнения
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';

-- Просмотр фактической статистики выполнения (со временем, количеством строк)
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';

Ключевые операторы плана выполнения

Оператор Значение Направление оптимизации
TableFullScan Полное сканирование таблицы Добавить подходящий индекс
IndexRangeScan Диапазонное сканирование по индексу Уже хорошо, проверить стоимость поиска в таблице
IndexLookUp Индекс + поиск в таблице Рассмотреть покрывающий индекс
IndexReader Чтение индекса (без поиска) Покрывающий индекс, оптимально
HashJoin Хеш-соединение Проверить размер данных на стороне Build
MergeJoin Соединение слиянием Убедиться, что обе стороны отсортированы
IndexJoin Индексное вложенное соединение Подходит для управления малой таблицой большой
StreamAgg Потоковая агрегация Уже оптимально
HashAgg Хеш-агрегация Проверить мощность группировки
TopN Сортировка TopN Уже оптимально
Sort Полная сортировка Проверить, можно ли использовать порядок индекса

Практические примеры настройки SQL

-- Пример 1: Избежать полного сканирования таблицы
-- Проблема: Низкая избирательность по status вызывает полное сканирование
EXPLAIN SELECT * FROM orders WHERE status = 'pending';
-- Решение: Добавить составной индекс
ALTER TABLE orders ADD INDEX idx_status_date (status, order_date);

-- Пример 2: Покрывающий индекс для устранения поиска в таблице
-- Проблема: IndexLookUp имеет высокую стоимость поиска
EXPLAIN SELECT customer_id, order_date FROM orders WHERE status = 'shipped';
-- Решение: Покрывающий индекс
ALTER TABLE orders ADD INDEX idx_cover (status, customer_id, order_date);

-- Пример 3: Оптимизировать порядок JOIN
-- Проблема: Сторона Build в HashJoin слишком велика
EXPLAIN ANALYZE SELECT *
FROM order_items oi
JOIN products p ON oi.product_id = p.product_id
WHERE p.category = 'electronics';
-- Решение: Добавить индекс на ведущую таблицу + обновить статистику
ANALYZE TABLE products;
ANALYZE TABLE order_items;

Управление планами SQL (SPM)

-- Создать SQL Binding для фиксации оптимального плана
CREATE SESSION BINDING FOR
  SELECT * FROM orders WHERE status = 'shipped'
USING
  SELECT * FROM orders USE INDEX (idx_status_date) WHERE status = 'shipped';

-- Просмотр существующих привязок
SHOW SESSION BINDINGS;

-- Удалить привязку
DROP SESSION BINDING FOR
  SELECT * FROM orders WHERE status = 'shipped';

Стратегии распределённых индексов

Проектирование индексов в распределённых базах данных существенно отличается от MySQL на одном сервере и требует учёта стоимости меж-Region запросов и риска горячих точек.

Принципы проектирования индексов

  1. Уменьшить сканирование Region: Префикс индекса должен быть рассеян, чтобы избежать концентрации в нескольких Region
  2. Контролировать количество индексов: Каждый индекс увеличивает накладные расходы на запись и хранение
  3. Предпочитать составные индексы: Уменьшить поиск в таблице, один составной индекс заменяет несколько одноколоночных
  4. Избегать слишком широких индексов: Общая ширина столбцов индекса должна быть < 200 байт
  5. Учитывать размещение индекса: TiDB поддерживает размещение индексов на разных движках хранения

Стратегия размещения индексов (Placement Rules)

-- Разместить индекс холодных данных на HDD-хранилище
ALTER TABLE orders ADD INDEX idx_create_time (create_time)
  PLACEMENT POLICY 'cold_storage';

-- Создать политику размещения
CREATE PLACEMENT POLICY cold_storage LEADER_CONSTRAINTS '[+disk=hdd]' FOLLOWER_CONSTRAINTS '[+disk=hdd]';

Невидимые индексы

-- Создать невидимый индекс (не влияет на запросы, обслуживание только при записи)
ALTER TABLE orders ADD INDEX idx_test (customer_id) INVISIBLE;

-- Убедиться, что индекс невидим
SHOW INDEXES FROM orders;

-- Сделать видимым после подтверждения отсутствия влияния на производительность
ALTER TABLE orders ALTER INDEX idx_test VISIBLE;

Диагностика и устранение горячих точек

Горячие точки — наиболее распространённая проблема в распределённых базах данных, вызывающая неравномерную нагрузку на определённые узлы.

Идентификация горячих точек

-- Просмотр распределения Region горячих точек
SELECT STORE_ID, COUNT(*) AS region_count
FROM INFORMATION_SCHEMA.TIKV_REGION_STATUS
GROUP BY STORE_ID
ORDER BY region_count DESC;

-- Просмотр горячих точек записи
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;

Типичные сценарии горячих точек и решения

Сценарий 1: Горячая точка автоинкрементного ID

-- Проблема: AUTO_INCREMENT приводит к концентрации записей в одной Region
CREATE TABLE logs (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  content TEXT,
  created_at TIMESTAMP
);

-- Решение 1: Использовать SHARD_ROW_ID_BITS для рассеивания
CREATE TABLE logs (
  id BIGINT AUTO_INCREMENT,
  content TEXT,
  created_at TIMESTAMP,
  PRIMARY KEY (id)
) SHARD_ROW_ID_BITS = 4;

-- Решение 2: Использовать временную метку как префикс первичного ключа
CREATE TABLE logs (
  created_at TIMESTAMP,
  id BIGINT AUTO_INCREMENT,
  content TEXT,
  PRIMARY KEY (created_at, id)
) SHARD_ROW_ID_BITS = 4;

Сценарий 2: Горячая точка индекса

-- Проблема: Записи в индексе времени концентрируются в конечной Region
ALTER TABLE orders ADD INDEX idx_created (created_at);

-- Решение: Использовать 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;

Сценарий 3: Полная горячая точка малой таблицы

-- Проблема: Данные малой таблицы в одной Region, горячая точка чтения при высокой конкурентности
-- Решение: Использовать Follower Read для распределения нагрузки чтения
SET @@tidb_replica_read = 'leader-and-follower';

-- Или включить на уровне сессии
SET SESSION tidb_replica_read = 'follower';

Оптимизация планирования PD

# Просмотр текущей конфигурации планирования
tiup ctl:v8.5.1 pd -u http://10.0.1.1:2379 config show all

# Настройка параметров планирования горячих точек
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 для уменьшения пустых Region
tiup ctl:v8.5.1 pd -u http://10.0.0.1:2379 config set enable-merge-region true

Аналитика в реальном времени TiFlash на практике

TiFlash — столбцовый движок хранения TiDB, позволяющий выполнять OLAP-аналитику в реальном времени без ETL.

Включение синхронизации TiFlash

-- Включить синхронизацию TiFlash для всей базы данных
ALTER DATABASE orders_db SET TIFLASH REPLICA 2;

-- Включить синхронизацию TiFlash для одной таблицы (2 реплики)
ALTER TABLE orders SET TIFLASH REPLICA 2;

-- Проверить прогресс синхронизации
SELECT * FROM INFORMATION_SCHEMA.TIFLASH_REPLICA_STATUS;

-- Синхронизировать определённые столбцы в TiFlash (уменьшить накладные расходы)
ALTER TABLE orders SET TIFLASH REPLICA 1
  INCLUDE (order_id, customer_id, amount, order_date);

Запросы в режиме MPP

-- Принудительно использовать движок MPP TiFlash
SET @@tidb_isolation_read_engines = 'tiflash';
SET @@tidb_enforce_mpp = 1;

-- Аналитика продаж в реальном времени
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;

-- Восстановить выбор движка по умолчанию
SET @@tidb_isolation_read_engines = 'tidb,tikv,tiflash';
SET @@tidb_enforce_mpp = 0;

Интеллектуальная маршрутизация HTAP

-- TiDB автоматически маршрутизирует: малые запросы к TiKV, большие к TiFlash
-- Ручная настройка не требуется, оптимизатор решает автоматически

-- Проверить, какой движок фактически использует запрос
EXPLAIN ANALYZE SELECT COUNT(*), SUM(amount)
FROM orders WHERE order_date >= '2026-01-01';
-- Наблюдать, содержит ли оператор информацию о tiflash

Резервное копирование и аварийное восстановление (BR)

BR (Backup & Restore) — встроенный инструмент распределённого резервного копирования и восстановления TiDB.

Полное резервное копирование и восстановление

# Полное резервное копирование в 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

# Полное восстановление
tiup br:v8.5.1 restore full \
  --pd "10.0.1.1:2379" \
  --storage "s3://tidb-backup/full-20260611" \
  --s3.region "us-east-1"

Инкрементальное резервное копирование

# Инкрементальное резервное копирование (на основе TS последней копии)
tiup br:v8.5.1 backup full \
  --pd "10.0.1.1:2379" \
  --storage "s3://tidb-backup/incr-20260611" \
  --last-backup-ts 450335849738604544

Резервное копирование на уровне базы данных/таблицы

# Резервное копирование на уровне базы данных
tiup br:v8.5.1 backup db \
  --db "orders_db" \
  --pd "10.0.1.1:2379" \
  --storage "s3://tidb-backup/orders-db-20260611"

# Резервное копирование на уровне таблицы
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"

Восстановление на определённый момент времени (PITR)

# Восстановление на определённый момент времени
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"

💡 Используйте инструмент Хеш-шифрование для проверки контрольных сумм целостности данных резервных копий.

Система мониторинга Grafana

Кластеры TiDB поставляются с полной системой мониторинга Prometheus + Grafana.

Основные дашборды мониторинга

Дашборд Ключевые метрики Рекомендуемый порог тревоги
TiDB Overview QPS, соединения, медленные запросы Медленный запрос > 1с
TiKV Details CPU, IO, количество Region CPU > 80%
PD Details Задачи планирования, распределение Region Задержка планирования > 5мин
TiFlash Details Задержка синхронизации, количество задач MPP Задержка синхронизации > 10с
BR Прогресс резервного копирования, длительность Ошибка резервного копирования
Node Exporter Диск, память, сеть Использование диска > 85%

Детали ключевых метрик

# Ключевые метрики TiDB
tidb_server_query_duration:
  description: "Латентность запросов P99"
  alert: "> 500мс в течение 5 минут"

tidb_server_slow_query:
  description: "Количество медленных запросов"
  alert: "> 10/мин"

tikv_grpc_message_duration:
  description: "Латентность gRPC-запросов TiKV"
  alert: "P99 > 200мс"

tikv_engine_write_bytes:
  description: "Пропускная способность записи"
  monitoring: "Следить за резкими падениями"

pd_scheduler_balance_region:
  description: "Скорость планирования Region"
  alert: "Ноль более 10 минут"

tiflash_sync_apply_duration:
  description: "Задержка синхронизации данных TiFlash"
  alert: "P99 > 10с"

Пользовательские правила тревог

# Пример правила тревоги 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 слишком высок"
          description: "Текущий QPS превышает 50000 в течение 5 минут"

      - 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 слишком высока"
          description: "Латентность записи P99 превышает 500мс"

Частые ошибки и устранение неполадок

Ошибка 1: Таймаут чтения/записи Region

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

Шаги устранения неполадок:

# 1. Проверить статус Region
tiup ctl:v8.5.1 pd -u http://10.0.1.1:2379 region check miss-peer

# 2. Проверить состояние TiKV
tiup ctl:v8.5.1 pd -u http://10.0.1.1:2379 store

# 3. Просмотреть медленные логи
tiup cluster audit tidb-prod --limit 50

Ошибка 2: Конфликт записи

Error: Write conflict, txn start_ts conflicts with another txn

Решение:

-- Настроить параметры повторных попыток транзакции
SET @@tidb_retry_limit = 20;
SET @@tidb_txn_retry_interval = 100; -- миллисекунды

-- Проверить уровень конфликтов
SELECT * FROM INFORMATION_SCHEMA.TIDB_TRX
  WHERE state = 'LockRcolliding' LIMIT 10;

Ошибка 3: OOM (нехватка памяти)

Error: Out Of Memory Quota!

Решение:

-- Установить лимит памяти запроса
SET @@tidb_mem_quota_query = 1073741824; -- 1GB

-- Включить управление ресурсами
CREATE RESOURCE GROUP rg_report
  RU_PER_SEC = 500
  PRIORITY = LOW;

-- Привязать пользователя к группе ресурсов
ALTER USER report_user RESOURCE GROUP rg_report;

Ошибка 4: Задержка синхронизации TiFlash

-- Проверить прогресс синхронизации
SELECT TABLE_ID, REPLICA_COUNT, PROGRESS, AVAILABLE
FROM INFORMATION_SCHEMA.TIFLASH_REPLICA_STATUS;

-- Проверить состояние узлов TiFlash
SELECT * FROM INFORMATION_SCHEMA.TIFLASH_TABLES
  WHERE REPLICA_AVAILABLE = 0;

Миграция с MySQL на TiDB

Сравнение решений для миграции

Решение Сценарий использования Время простоя Сложность
DM полное+инкрементальное Крупномасштабная миграция Почти нулевое Средняя
Dumpling + TiDB Lightning Одноразовая миграция Часы Низкая
mysqldump + source Небольшой объём данных Часы Низкая

Использование миграции DM (рекомендуется)

# dm-task.yaml - Конфигурация задачи миграции 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_*"

# Запустить задачу DM
dmctl start-task dm-task.yaml

# Проверить статус задачи
dmctl query-status mysql-to-tidb

# Проверить целостность данных
dmctl check-task dm-task.yaml

Предмиграционная проверка совместимости

-- Проверить использование хранимых процедур
SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE
FROM information_schema.routines
WHERE ROUTINE_SCHEMA NOT IN ('mysql', 'sys');

-- Проверить ограничения внешних ключей
SELECT TABLE_SCHEMA, TABLE_NAME, CONSTRAINT_NAME
FROM information_schema.table_constraints
WHERE CONSTRAINT_TYPE = 'FOREIGN KEY';

-- Проверить триггеры
SELECT TRIGGER_SCHEMA, TRIGGER_NAME, EVENT_OBJECT_TABLE
FROM information_schema.triggers;

-- Проверить столбцы auto-increment
SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, AUTO_INCREMENT
FROM information_schema.columns
WHERE EXTRA LIKE '%auto_increment%';

Тесты производительности

Тест TPCC

# Тестирование производительности OLTP с TPCC
git clone https://github.com/pingcap/go-tpc.git
cd go-tpc

# Подготовка данных
go-tpc tpcc prepare \
  --host 10.0.1.1 --port 4000 \
  --warehouses 1000 --threads 50

# Запуск теста
go-tpc tpcc run \
  --host 10.0.1.1 --port 4000 \
  --warehouses 1000 --threads 50 \
  --time 600s

# Очистка
go-tpc tpcc cleanup \
  --host 10.0.1.1 --port 4000 \
  --warehouses 1000

Тест TPC-H (HTAP)

# Тестирование производительности OLAP с TPC-H
go-tpc tpch prepare \
  --host 10.0.1.1 --port 4000 \
  --scale 100 --threads 10

# Принудительное выполнение в TiFlash
go-tpc tpch run \
  --host 10.0.1.1 --port 4000 \
  --scale 100 --threads 10 \
  --time 300s \
  --engine tiflash

Типичная справка по производительности

Сценарий Конфигурация узлов QPS/TPS Латентность P99
OLTP (TPCC) 3×TiDB + 3×TiKV 15 000 TPS < 50мс
OLAP (TPC-H) + 2×TiFlash 22 запроса/5мин Зависит от запроса
Смешанный HTAP Вышеуказанная конфигурация TP стабильно + AP 10x Независимо

Часто задаваемые вопросы

В1: Подходит ли TiDB для замены шардинга MySQL?

Да, это наиболее типичный сценарий использования TiDB. TiDB обеспечивает прозрачное горизонтальное масштабирование без логики шардинга на уровне приложения, сохраняя при этом совместимость с протоколом MySQL для минимальных затрат на миграцию. Настоятельно рекомендуется, когда одна таблица превышает 50 миллионов строк или операционная сложность шардинга слишком высока.

В2: Какой уровень изоляции транзакций у TiDB?

TiDB по умолчанию использует уровень изоляции RC (Read Committed) (v6.0+), а также поддерживает семантику RR (Repeatable Read). RR TiDB фактически является Snapshot Isolation (SI), которая предотвращает фантомные чтения, но имеет тонкие отличия от RR MySQL в определённых сценариях (например, поведение текущего чтения).

В3: Каков оптимальный масштаб данных для TiDB?

  • Одна таблица: От десятков миллионов до десятков миллиардов строк; TiDB рекомендуется при превышении 50 миллионов строк
  • Общие данные кластера: Масштаб от TB до PB
  • Размер Region: По умолчанию 96 МБ, рекомендуется держаться близко к этому значению

В4: Как выбрать между TiDB и CockroachDB?

Измерение TiDB CockroachDB
Совместимость SQL MySQL PostgreSQL
HTAP Нативная поддержка Не поддерживается
Сообщество В основном Китай/APAC Глобальное
Облачный сервис TiDB Cloud CockroachDB Cloud

Если ваш стек основан на MySQL и нужен HTAP, выбирайте TiDB; если на PostgreSQL и только OLTP — CockroachDB.

В5: Как работать с большими транзакциями в TiDB?

TiDB по умолчанию ограничивает 100 МБ и 5000 строк на транзакцию. Решения для больших транзакций:

-- Настроить лимиты транзакции (не рекомендуется устанавливать слишком высоко)
SET @@tidb_txn_entry_size_limit = 536870912;  -- 512MB
SET @@tidb_txn_total_size_limit = 1073741824; -- 1GB

-- Рекомендуется: пакетные фиксации
-- Разбивать большие транзакции на маленькие в приложении, 1000-5000 строк на пакет

В6: Какая лицензия у TiDB?

TiDB Server, TiKV и PD используют полностью открытую лицензию Apache 2.0. TiFlash также является открытым начиная с v8.0+. TiDB Cloud (Serverless/Dedicated) — коммерческий сервис.

Итоги

TiDB стала эталонным продуктом в области распределённых баз данных в 2026 году. Её совместимость с MySQL, возможности HTAP и облачная архитектура делают её идеальным выбором для модернизации корпоративных баз данных. Ключевые выводы:

  1. Архитектура: Четыре компонента TiDB/TiKV/PD/TiFlash, разделение вычислений и хранения
  2. Развёртывание: Управление TiUP в один клик, требования к SSD и сети для продакшена
  3. Настройка SQL: Использовать EXPLAIN ANALYZE, освоить SPM для привязки планов
  4. Проектирование индексов: Учитывать распределённые особенности, избегать индексов горячих точек
  5. Управление горячими точками: Рассеивание SHARD_ROW_ID_BITS, распределение Follower Read
  6. HTAP: Столбцовый TiFlash + движок MPP для аналитики в реальном времени
  7. Аварийное восстановление: BR поддерживает стратегии полного/инкрементального/PITR восстановления
  8. Мониторинг: Полная система Grafana, ключевые метрики нельзя игнорировать
  9. Миграция: Инкрементальная миграция DM обеспечивает переключение практически без простоя

Попробуйте эти локальные браузерные инструменты — регистрация не требуется →

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