1. 课程导论：Liquibase 是什么、增量迁移的痛点、元数据锁与 GC 停顿的关系概述
1.1 Liquibase 是什么
Liquibase 是一款开源、数据库无关的数据库变更管理工具。它通过 变更集（ChangeSet） 和 变更日志（ChangeLog） 的机制，将数据库 Schema 的版本演进纳入 Git 等版本控制系统，实现数据库变更的自动化、可追溯、可回滚。
核心工作流程：
- 开发人员在 XML / YAML / JSON / SQL 格式的 ChangeLog 中定义变更集。
- Liquibase 在目标数据库中维护两张元数据表：
DATABASECHANGELOG（记录已执行变更集）和DATABASECHANGELOGLOCK（记录锁状态）。 - 执行
liquibase update时，工具读取 ChangeLog，比对元数据表，仅执行未应用的变更集。
关键特性： 支持回滚（rollback）、上下文（contexts）、标签（labels）、前置条件（preConditions）、多环境差异化执行。
1.2 增量迁移的痛点
在生产环境中，增量迁移（Incremental Migration）面临以下核心挑战：
| 痛点 | 描述 | 典型场景 |
|---|---|---|
| 锁竞争 | Liquibase 在变更前后对 DATABASECHANGELOGLOCK 表加写锁，多实例并发时易阻塞。 |
K8s 多副本启动、CI/CD 并行部署 |
| 长事务阻塞 | DDL 操作（如 ALTER TABLE）可能触发元数据锁等待，阻塞后续读写。 | 大表加列、修改索引 |
| GC 停顿放大 | 锁等待期间，应用线程阻塞，JVM 堆内存压力上升，触发 Full GC。 | 高并发交易系统 |
| 回滚复杂度 | 增量变更的回滚脚本需手动维护，且可能因数据依赖导致失败。 | 字段类型变更、数据迁移 |
注意： 增量迁移的锁问题并非 Liquibase 独有，但 Liquibase 的元数据锁机制会与数据库自身的元数据锁（Metadata Lock）叠加，形成 锁链，显著增加系统停顿风险。
1.3 元数据锁与 GC 停顿的关系概述
元数据锁（Metadata Lock，简称 MDL）是数据库（如 MySQL InnoDB）用于保护表结构定义的一种锁机制。当 DDL 语句执行时，数据库会对目标表施加 排他元数据锁，阻塞后续所有对该表的读写操作。
GC 停顿（Stop-The-World，STW）是 JVM 进行垃圾回收时暂停所有应用线程的行为。当元数据锁等待导致应用线程长时间阻塞时，JVM 堆内存中的对象无法及时释放，压力持续累积，最终触发 Full GC，造成更长的停顿。
两者之间的因果链条如下：
- Liquibase 发起 DDL → 数据库对目标表加排他 MDL。
- 并发查询/写入被阻塞 → 应用线程进入锁等待状态。
- 线程阻塞不释放连接 → 连接池耗尽，新请求排队。
- 请求队列堆积 → 堆内存中待处理对象激增。
- JVM 触发 Full GC → 所有线程暂停，系统吞吐量归零。
- GC 停顿延长锁持有时间 → 锁竞争进一步恶化，形成恶性循环。
1.4 本课程的核心价值
本课程将围绕以下三个维度展开实战排错：
- 诊断维度： 如何通过数据库
SHOW PROCESSLIST、performance_schema、JVM 线程 Dump、GC 日志等工具，精准定位锁与 GC 的关联根因。 - 预防维度： Liquibase 配置优化（锁超时、重试策略、变更集拆分）、DDL 执行窗口选择、连接池参数调优。
- 治理维度： 增量迁移的标准化流程、回滚预案、灰度发布策略、监控告警体系搭建。