database migration执行时机及服务重启规则咨询

你描述的首次部署场景是迁移工具的标准冷启动场景：空数据库+从未执行过的全量迁移文件，服务启动时自动执行迁移完成建表，是所有迁移工具设计时覆盖的最基础流程，两个问题的结论非常明确：

1. 服务器关机重启后，不需要重复执行已完成的迁移操作 #

所有主流迁移工具（Flyway、Liquibase、Alembic、各语言框架自带的迁移模块等）首次在空库执行时，都会先自动创建一张迁移版本元数据表（不同工具默认表名不同，比如Flyway为flyway_schema_history，Django为django_migrations），表里会持久化存储每一个成功执行的迁移文件的唯一版本标识、文件内容校验哈希、执行时间、执行结果这些元数据。
服务器重启后再次触发迁移流程时，工具的执行逻辑是：

• 先扫描本地部署目录下的所有迁移文件，按版本号排序
• 拉取数据库元数据表里记录的已成功执行的版本列表
• 逐个比对：已经存在于成功执行记录里的迁移文件，会直接跳过，绝对不会重复执行
  只有当你手动篡改了已经执行过的历史迁移文件内容时，工具才会检测到文件哈希和历史记录不匹配，直接抛出校验错误，不会无理由重复执行旧逻辑改坏现有库结构。

2. 未新增迁移文件时数据库不会产生变更的判断完全正确 #

你的测试结果和迁移工具的核心设计逻辑完全一致：
迁移本质是版本化的差量更新机制，工具只会执行「本地存在、但数据库元数据表里没有成功执行记录」的高版本迁移文件。如果本地迁移文件集合和数据库里记录的已执行版本完全匹配、所有历史迁移文件的内容也没有被改动，迁移流程启动后只会做轻量的版本比对操作，不会对现有数据库的表、字段、索引、约束做任何修改，整个比对过程的性能开销可以忽略不计。
实际生产部署里，大家通常都会把「执行迁移」配置成服务启动的固定前置步骤，不需要每次上线/重启手动判断要不要跑迁移，工具本身的校验逻辑就可以保证不会做多余的库变更。

实操提醒：不要手动修改数据库里的迁移版本元数据表，也不要随意改动已经上线执行过的历史迁移文件，否则会破坏版本校验逻辑，很容易触发“表已存在”“字段重复”这类冲突报错。

内容的提问来源于stack exchange，提问作者calvert