本文介绍如何在 liquibase 中安全高效地执行大表批量更新（如 update 百万级数据），通过按主键或逻辑范围分片拆解 sql，规避长事务、连接超时与锁表风险。
本文介绍如何在 liquibase 中安全高效地执行大表批量更新（如 update 百万级数据），通过按主键或逻辑范围分片拆解 sql，规避长事务、连接超时与锁表风险。
在使用 Liquibase 管理多环境数据库变更时，直接对千万级大表执行全量 UPDATE（例如 UPDATE my_table SET column1 = 'some'）极易引发严重问题：事务持续时间过长（30 分钟以上）、连接中断、锁表阻塞业务、甚至因内存溢出或数据库超时导致变更失败。Liquibase 本身不内置自动分片执行引擎，但完全支持通过手动设计“可分片的变更脚本”实现安全、可控的批量更新。
✅ 推荐实践：基于主键/有序字段分片执行
核心思路是将单条全表更新语句，拆分为多条作用于数据子集的独立 UPDATE 语句，并确保每条语句处理的数据量可控（建议单次 5–50 万行，具体依表结构、索引、硬件而定）。最可靠且高效的分片维度是有索引的单调递增主键（如 id）：
<!-- changelog.xml -->
<changeSet id="update-my-table-in-batches" author="dev">
<comment>Batch update column1 for large table, split by id ranges</comment>
<update tableName="my_table">
<column name="column1" value="some"/>
<where>id < 500000</where>
</update>
</changeSet>
<changeSet id="update-my-table-in-batches-2" author="dev">
<update tableName="my_table">
<column name="column1" value="some"/>
<where>id >= 500000 AND id < 1000000</where>
</update>
</changeSet>
<changeSet id="update-my-table-in-batches-3" author="dev">
<update tableName="my_table">
<column name="column1" value="some"/>
<where>id >= 1000000</where>
</update>
</changeSet>? 关键优势：
- 每个 <changeSet> 独立提交，失败仅回滚当前批次，不影响其余；
- 利用 id 索引快速定位，避免全表扫描；
- 可精确控制每批数据量，适配不同环境资源限制；
- 完全兼容 Liquibase 的校验和、执行状态跟踪与回滚机制（若定义了 <rollback>）。
⚠️ 注意事项与增强建议
- 务必确保分片字段已建索引：若按 id 分片，确认 my_table.id 是主键或有高效索引，否则性能无改善。
- 避免重叠与遗漏：分片条件需严格互斥且覆盖全集（如使用 BETWEEN 或链式 >= / <），上线前用 SELECT COUNT(*) WHERE ... 验证各批次数据量总和是否等于全表。
- 考虑业务低峰期执行：即使分片，仍可能产生短时锁，建议在维护窗口运行。
-
补充监控与日志：在生产环境变更前，可在 preConditions 中加入行数校验，例如：
<preConditions onFail="HALT"> <sqlCheck expectedResult="0">SELECT COUNT(*) FROM my_table WHERE column1 != 'some'</sqlCheck> </preConditions>
- 替代方案（高级场景）：若无合适数字主键，可基于时间字段（如 created_at）、哈希分片（MOD(HASH(id), 4) = 0）或借助数据库原生批处理函数（如 PostgreSQL 的 LIMIT/OFFSET 结合循环脚本），但需注意跨数据库兼容性。
通过合理分片设计，你无需引入外部调度工具或放弃 Liquibase 的版本化治理能力，即可将高风险的大表变更转化为稳定、可追溯、可重复的标准化流程。
