SQL Serverでテーブル定義を変更したとき、「ビューやストアドプロシージャーはそのままでOK」と思っていませんか？ 実は、見えない不具合やパフォーマンス劣化の原因になることもあるんです。
この記事では、ビューとストアドプロシージャーのリフレッシュがなぜ必要なのか、どうやって安全に実行するかをわかりやすく解説します。
🧠 実行プランとは？（ストアドプロシージャー編）
SQL Serverでは、ストアドプロシージャーを実行するときに「実行プラン（Execution Plan）」が作成されます。これは、クエリをどう処理するかの設計図のようなものです。
- インデックスの使用
- 結合順序
- テーブルスキャンの方法
などが含まれ、初回実行時に作成されてキャッシュされます。
⚠️ 問題点
テーブル定義が変わっても、古い実行プランが使われ続けることがあり、以下のような問題が起きる可能性があります：
- パフォーマンスが低下する
- 意図しないデータ取得になる
- 結果がズレる、空になる
🔄 sp_recompile でストアドをリフレッシュ
テーブル定義変更後は、以下のコマンドでストアドプロシージャーを再コンパイルしましょう：
EXEC sp_recompile 'プロシージャ名';すべてのストアドを一括でリフレッシュするには：
DECLARE @sql NVARCHAR(MAX) = '';
SELECT @sql += 'EXEC sp_recompile ''' + [name] + ''';' + CHAR(13) + CHAR(10)
FROM sys.objects
WHERE [type] = 'P';
EXEC (@sql);🧭 ビューの落とし穴とリフレッシュ
ビューはテーブルの仮想的な表現ですが、テーブル構造が変わっても自動で更新されません。特に危険なのが SELECT * を使っている場合です。
⚠️ SELECT * のリスク
- カラムの順番が変わる
- 削除されたカラムを参照してエラーになる
- エラーが出ずにデータがズレることも…
✅ 対策
- ビューでは必ず明示的にカラムを指定する
- テーブル定義変更後は
sp_refreshviewを実行する
EXEC sp_refreshview 'ビュー名';すべてのビューを一括でリフレッシュするには：
DECLARE @sql NVARCHAR(MAX) = '';
SELECT @sql += 'EXEC sp_refreshview ''' + [name] + ''';' + CHAR(13) + CHAR(10)
FROM sys.objects
WHERE [type] = 'V';
EXEC (@sql);いつ実行すべき？
| タイミング | 実行対象 |
|---|---|
| テーブルのカラム追加・削除・型変更 | ビュー・ストアド両方 |
| スキーマ変更・マイグレーション | ビュー・ストアド両方 |
| 本番リリース直後 | ビュー・ストアド両方 |
| パフォーマンス劣化時 | ストアドプロシージャー |
| SELECT * を使っているビューがある | ビュー |
✅ まとめ
- ストアドは実行プランをキャッシュする →
sp_recompileでリフレッシュ - ビューはテーブル構造変更に追従しない →
sp_refreshviewで再解析 SELECT *は使わず、明示的なカラム指定を！
この内容を運用ルールに組み込むことで、予期せぬ不具合やパフォーマンス低下を未然に防ぐことができます。 次回は、これらの処理をSQL Server AgentやPowerShellで自動化する方法も紹介します！
コメント