SQL 在线DDL指的是在数据库表结构变更过程中，不阻塞表的正常读写操作，让业务可以持续访问目标表的技术。传统DDL操作往往需要锁表，变更大表时会导致业务长时间不可用，而在线DDL通过特定的实现机制解决了这个问题。
在线DDL的核心实现流程
以MySQL的InnoDB引擎为例，在线DDL的整体流程可以分为三个阶段：
- 准备阶段：引擎会检查当前表是否支持在线DDL操作，创建临时表结构，同时获取表的元数据锁，这个阶段锁的持有时间很短，不会阻塞业务。
- 执行阶段：引擎按照变更类型执行对应的操作，对于支持在线执行的变更，会一边修改临时表结构，一边记录原表的增量数据变更。
- 提交阶段：将执行阶段记录的增量数据回放到临时表中，然后替换原表，释放元数据锁，整个变更完成。
关键实现机制
临时表机制
在线DDL执行时会先创建一个和原表结构一致的临时表，然后根据变更需求修改临时表的结构。原表的读写操作不受影响，所有的增量数据变更会被记录下来，后续再同步到临时表中。临时表的创建和替换过程对业务透明，用户感知不到中间状态。
增量日志回放
在DDL执行期间，原表的所有增删改操作都会被记录到增量日志中。当临时表的结构变更完成后，引擎会把增量日志中的数据按照顺序回放到临时表，保证临时表的数据和原表最终一致。这个回放过程会持有短暂的锁，但是时间极短，通常不会影响业务。
元数据锁控制
在线DDL过程中会涉及元数据锁的获取和释放，准备阶段和提交阶段会获取元数据锁，但是持有时间很短。执行阶段只持有低级别的元数据锁，允许表的读写操作，因此不会阻塞业务请求。
不同变更类型的实现差异
在线DDL的变更类型分为即时执行、原地执行、需要拷贝表三种，不同类别的实现逻辑有区别：
| 变更类型 | 实现方式 | 是否阻塞写操作 |
|---|---|---|
| 即时执行 | 仅修改元数据，不需要操作表数据 | 否 |
| 原地执行 | 直接修改原表的存储结构，不需要拷贝全量数据 | 否 |
| 需要拷贝表 | 需要创建临时表并拷贝全量数据，同时回放增量日志 | 仅在提交阶段短暂阻塞 |
代码示例：查看在线DDL执行状态
在MySQL中可以通过查询performance_schema库的相关表来查看在线DDL的执行进度：
-- 查看当前正在执行的DDL操作
SELECT
PROCESSLIST_ID,
PROCESSLIST_INFO,
PROCESSLIST_STATE
FROM performance_schema.threads
WHERE PROCESSLIST_INFO LIKE 'ALTER TABLE%';
-- 查看DDL的执行进度（MySQL 8.0+支持）
SELECT
EVENT_NAME,
WORK_COMPLETED,
WORK_ESTIMATED
FROM performance_schema.events_stages_current
WHERE EVENT_NAME LIKE 'stage/innodb/alter%';
在线DDL的限制
虽然在线DDL可以大幅降低变更对业务的影响，但是也存在一些限制：
- 部分复杂的表结构变更仍然不支持在线执行，比如修改主键类型、删除主键等操作，执行时会退化为锁表变更。
- 在线DDL执行期间会占用额外的磁盘空间和CPU资源，大表变更时需要预留足够的资源，避免影响数据库整体性能。
- 增量日志的大小有限制，如果DDL执行时间过长，增量日志可能会被写满，导致变更失败。
总结
SQL在线DDL的核心是通过临时表、增量日志回放、轻量级元数据锁等机制，在保证数据一致性的前提下，最大程度减少表结构变更对业务读写的影响。不同数据库引擎的实现细节有差异，但是核心思路都是分离结构变更和数据同步的过程，降低锁的持有时间。开发者在使用在线DDL时，需要先确认变更类型是否支持在线执行，同时评估变更期间的资源消耗，避免对线上业务造成不必要的影响。