tidb fast ddl
# TiDB Fast DDL
# 1. 概述
Fast DDL 是 TiDB 推出的一项重要优化技术，旨在解决传统 DDL 操作执行慢、阻塞业务的问题。通过 Fast DDL，TiDB 实现了在线 DDL 变更的性能大幅提升，可以在不影响业务正常运行的情况下快速完成表结构变更操作。
从 TiDB v6.5.0 版本开始，Fast DDL 功能已经默认开启，为用户带来显著的性能提升：
- 与早期版本相比，DDL 操作性能提升了约 10 倍
- 在 v8 版本中，建表速度相比 v7.5 提升了约 50 倍
- 启用 Fast Create Table 优化后，DDL 操作的 QPS 可提升一倍
# 2. TiDB DDL 基本原理
TiDB DDL 模块通过引入 DDL Owner 角色来代理执行所有进入 TiDB 集群中的 DDL 语句。在同一时间，整个 TiDB 集群中只有一个 TiDB 节点能当选为 Owner。当选 Owner 后，该 TiDB 节点中启动的 worker 才能处理集群中的 DDL 任务。
TiDB DDL 操作可分为两大类：
- General DDL 语句：仅涉及元数据修改的 DDL 语句，执行速度很快。
- Reorg DDL 语句：需要重组（Reorganize）数据的 DDL 语句，如添加索引、修改列类型等，这类操作是 Fast DDL 主要优化的对象。
# 3. Fast DDL 的实现原理
Fast DDL 主要通过以下几个方面实现性能提升：
# 3.1 分布式执行框架
Fast DDL 采用分布式执行框架，将一个 DDL 任务拆分成多个子任务，调度到不同的 TiDB 节点上并行执行，大幅提高执行效率。特别是对于添加索引等耗时操作，效果显著。
# 3.2 本地临时存储
在执行 ADD INDEX 等操作时，Fast DDL 会利用执行节点的本地磁盘作为临时存储空间（RocksDB an instance），用于存储排序后的索引键值对。这避免了将中间数据写入 TiKV，减少了网络传输和分布式事务的开销，从而提高了数据处理速度。
# 3.3 并行处理能力优化
通过增强并行处理能力，Fast DDL 可以同时处理更多的数据，特别是在大表上执行 DDL 操作时，性能提升明显。
# 4. Fast DDL 工作流程拆解 (以 ADD INDEX 为例)
一个典型的 ADD INDEX 任务在 Fast DDL 模式下主要经历以下阶段：
- 扫描数据 (Scan)：DDL Owner 会创建一个分布式执行计划，将表的行数据（主键和索引列）扫描任务分发给多个 TiDB 节点。每个节点负责扫描表的一部分数据。
- 本地排序 (Sort)：每个执行节点将扫描到的数据在本地临时目录中进行排序，生成有序的中间文件。
- 数据导入 (Ingest)：所有执行节点完成本地排序后，DDL Owner 会通知这些节点将排好序的索引数据直接导入到对应的 TiKV Region 中。这个过程被称为 "Ingest"，它绕过了传统的写入路径，效率极高。
- 校验索引 (Validate)：数据导入完成后，系统会校验索引数据的一致性，确保新创建的索引是准确无误的。
- 更新元数据 (Update Metadata)：校验通过后，DDL Owner 会更新表元数据，将索引状态置为可用 (Public)，整个 DDL 操作完成。
# 5. 配置和使用 Fast DDL
# 5.1 启用 Fast DDL
从 TiDB v6.5.0 开始，Fast DDL 功能默认开启。可以通过以下系统变量控制：
-- 启用 Fast Online DDL 模式
SET GLOBAL tidb_ddl_enable_fast_reorg = ON; -- 默认已开启
2
# 5.2 调整相关参数
可以通过调整以下参数优化 Fast DDL 的性能：
-- 控制 DDL 操作的并发度
SET GLOBAL tidb_ddl_reorg_worker_cnt = 16; -- 默认值取决于系统配置
-- 控制快速模式可使用的本地磁盘最大配额 (所有 DDL 任务共享)
SET GLOBAL tidb_ddl_disk_quota = '100G'; -- 默认 100GB
-- 控制单个 DDL 任务可使用的最大内存
SET GLOBAL tidb_ddl_reorg_batch_size = 2048; -- 默认值
2
3
4
5
6
7
8
# 5.3 临时目录配置
对于 TiDB On-Premise 集群，可以通过 TiDB 的配置文件参数 --temp-dir 指定临时文件存储目录。确保该目录所在磁盘有足够的空间和 I/O 性能。
# 6. 支持的 DDL 操作
目前，Fast DDL 主要加速以下 Reorg DDL 操作：
ADD INDEX/ADD PRIMARY KEYMODIFY COLUMN/CHANGE COLUMN(当涉及列类型转换时)ALTER TABLE ... REORGANIZE PARTITION
对于 DROP INDEX、ADD COLUMN (不带默认值) 等不涉及大量数据重组的操作，本身执行速度较快，不通过 Fast DDL 框架。
# 7. 性能对比
# 7.1 与其他数据库系统对比
TiDB 的 Fast DDL 在性能测试中展现出明显优势：
- 与 Aurora、CockroachDB 相比，TiDB Cloud 的 Online DDL 性能更优。
- 与 OceanBase 相比，TiDB 的 DDL 操作也具有竞争力。
# 7.2 版本间性能提升
- TiDB v6.5 版本的 Fast DDL 性能比之前版本提升约 10 倍。
- TiDB v8 版本建表速度比 v7.5 版本提升约 50 倍。
# 8. 适用场景
Fast DDL 特别适用于以下场景：
- 大表结构变更：对大表添加索引或字段时，Fast DDL 可以显著减少操作时间。
- 高并发业务环境：在线 DDL 变更不会阻塞业务正常运行。
- 多租户大规模部署：支持百万级别表的高效管理。
- 频繁的表结构调整：快速响应业务需求变化，支持敏捷开发。
# 9. 监控与诊断
# 9.1 查看 DDL 任务
可以通过 ADMIN SHOW DDL JOBS 命令查看当前正在运行或历史的 DDL 任务详情。
ADMIN SHOW DDL JOBS;
关注 STATE 和 SCHEMA_STATE 字段，了解任务进展。
# 9.2 Grafana 监控面板
在 TiDB 的 Grafana 监控中，TiDB -> DDL 面板提供了丰富的监控项：
- DDL Job By State：查看处于不同状态的 DDL 任务数量。
- DDL Add Index Progress：监控添加索引任务的进度。
- DDL Reorg Worker Count：查看 Reorg worker 的数量。
- DDL Temp Disk Usage：监控 Fast DDL 使用的临时磁盘空间。
# 9.3 常见问题排查
- 临时磁盘空间不足：如果 Grafana 显示
DDL Temp Disk Usage达到配额，DDL 任务会暂停。此时需要增加tidb_ddl_disk_quota或清理磁盘空间。 - DDL 任务卡住：检查
ADMIN SHOW DDL JOBS的状态，并查看相关 TiDB 节点的日志文件 (tidb.log)，搜索DDL关键字以获取详细错误信息。
# 10. 限制和注意事项
使用 Fast DDL 时需要注意：
- 临时空间需求：Fast DDL 需要足够的本地磁盘空间作为临时存储。
- 资源消耗：高并发的 DDL 操作可能会消耗较多 CPU、内存和磁盘 I/O。
- 兼容性：某些特殊类型的 DDL 操作可能不适用于 Fast DDL 模式。
- 监控：建议在执行大型 DDL 操作时密切监控系统资源使用情况。
# 11. 最佳实践
- 合理设置并发度：根据系统资源情况调整
tidb_ddl_reorg_worker_cnt参数。 - 预估磁盘空间：确保
tidb_ddl_disk_quota设置合理，避免空间不足。 - 选择低峰期：尽量在业务低峰期执行大型 DDL 操作，以减少对业务的影响。
- 分批执行：对于超大表，考虑将 DDL 操作分批执行。
- 提前测试：在生产环境应用前，在测试环境验证 DDL 操作的执行时间和影响。