dotnet ef database update が落ちる、起動時に自動適用が例外で止まる——マイグレーション失敗は「モデル差分」「履歴表」「既に存在するオブジェクト」が絡みやすい。慌てて手動でオブジェクトをいじる前に、どこまで適用済みかを確認する。
先に結論
- まず
__EFMigrationsHistory と実際のスキーマ状態を突き合わせる
- 「既に存在する」系は履歴だけズレ／二重適用が多い
- 接続先（開発／検証／本番）を取り違えていないか最初に確認
- 失敗途中でトランザクションがロールバックされたか、一部だけ残ったかをログで見る
切り分けの順番
- 例外メッセージ（オブジェクト名、制約名、権限）をそのまま控える
- 接続文字列のサーバ／DB 名が意図どおりか確認
- 履歴表にどの MigrationId まで入っているか確認
- 対象テーブル／索引が既にあるか、欠落しているかを実DBで確認
- 複数環境で同じマイグレーションを別経路（手作業DDL）で入れていないか
よくあるパターン
- 履歴に無いのにオブジェクトはある（手適用／別ブランチ適用）
- 履歴にはあるのにオブジェクトが無い（途中失敗やリストア）
- 列型変更でデータが入らず失敗（長さ・NULL・既定値）
- 権限不足で CREATE／ALTER が拒否される
関連: DbUpdateException の切り分け
対処の考え方
- 開発DBなら作り直し（drop + update）が早いこともある
- 共有／本番寄りのDBは履歴と実体を揃える方針を決めてから動く
- 空のマイグレーションで整合を取る、失敗した Migration を修正して再適用、など手段は状況次第
- CI では「適用済みか」「pending が何か」を先に表示するステップがあると安心
ざっくりまとめ
- 失敗時は履歴表と実スキーマのズレ確認が本丸
- 接続先取り違えと権限もすぐ疑う
- 手でオブジェクトをいじるのは最後。先に原因の型を特定する
関連記事