ClickHouse迁移回滚方法咨询：如何修改schema_migrations表实现回滚

一、无工具时的手动回滚思路 #

ClickHouse本身没有官方的迁移回滚工具，核心就是手动反向执行当初的迁移操作，再配合修正schema_migrations表的状态：

• 要是迁移是建表：直接跑 DROP TABLE IF EXISTS 表名
• 要是迁移是加列：执行 ALTER TABLE 表名 DROP COLUMN 列名
• 要是迁移改了列类型：得改回原类型（比如之前把String改成Int64，就再改回去），注意数据兼容，最好先备份数据
• 要是迁移建了物化视图：DROP MATERIALIZED VIEW IF EXISTS 视图名

二、schema_migrations表的修正步骤 #

这个表就是用来记录已经执行过的迁移标识，防止重复执行。回滚时需要删掉对应迁移的记录，这样后续工具才会认为该迁移没执行过。

1. 先查清楚表结构 #

先跑这条SQL确认表的字段：

SELECT * FROM schema_migrations;

一般会有version（迁移的版本号/唯一标识）、dirty（标记是否有未完成的迁移）、applied（执行时间）这些字段，对应你截图里的结构。

2. 删除目标迁移记录 #

找到你要回滚的那条迁移的version值，执行删除：

DELETE FROM schema_migrations WHERE version = '你的迁移版本号';

注意：如果这个表用的是ReplacingMergeTree引擎（ClickHouse常用引擎），删完后得跑 OPTIMIZE TABLE schema_migrations FINAL 才能确保记录真的被删掉。

3. 修正dirty状态（如果需要） #

如果回滚的是没完成的迁移，可能要把dirty字段从1改成0：

ALTER TABLE schema_migrations UPDATE dirty = 0 WHERE dirty = 1;

同样，ReplacingMergeTree引擎要加OPTIMIZE命令生效。

三、必看注意事项 #

• 先备份数据！：回滚前一定要备份相关表的数据，比如用SELECT * INTO OUTFILE或者BACKUP TABLE，别搞丢数据
• 检查依赖：如果后面的迁移依赖了要回滚的操作，回滚后得同步调整后面的迁移脚本
• 先在测试环境试：所有操作先在测试环境跑一遍验证没问题，再碰生产环境

内容的提问来源于stack exchange，提问作者Игорь Макеев