MySQLテーブル名変更の完全ガイド｜RENAMEとALTERの違い・安全手順

「MySQLでテーブル名を変更したいが、本番環境で実行して大丈夫だろうか？」
「RENAME TABLEとALTER TABLEの違いがよく分からない」
「外部キーやビューがあるけど、そのままリネームして問題ない？」

このような疑問を持って検索している方も多いのではないでしょうか。

テーブル名の変更（リネーム）は、一見シンプルなDDL操作に見えます。しかし実務では、メタデータロック（MDL）、権限、外部キー制約、ビュー・ストアド依存、アプリ側の参照箇所など、多くの影響範囲を伴います。
正しい手順で実施しなければ、本番停止や障害につながるリスクもあります。

本記事では、以下を体系的に解説します。

• RENAME TABLE と ALTER TABLE RENAME の違い
• 複数テーブルの一括変更・スワップ（入れ替え）手法
• 別DB（スキーマ）への移動方法
• 外部キー・ビュー・トリガーの影響
• メタデータロック（MDL）と権限の注意点
• 本番運用で失敗しないベストプラクティス

基礎から実務レベルまで網羅しているため、初心者の方も、現場でDBを扱うエンジニアの方も、ぜひ最後までご覧ください。

MySQLでテーブル名を変更する2つの方法

MySQLでテーブル名を変更する方法は、主に次の2つです。

• RENAME TABLE
• ALTER TABLE ... RENAME

どちらもテーブル名を変更できますが、用途・制約・運用性が異なります。

公式リファレンス：

• MySQL 公式マニュアル（RENAME TABLE）
  https://dev.mysql.com/doc/refman/8.0/en/rename-table.html
• MySQL 公式マニュアル（ALTER TABLE）
  https://dev.mysql.com/doc/refman/8.0/en/alter-table.html

まず理解すべき：テーブル名変更が必要になるケース

命名が実態とズレている

例：

• temp_user が本番永続テーブルになっている
• work_order が実は正式受注データ

このような状態を放置すると、

• 誤削除リスク
• 調査コスト増大
• 保守性低下

につながります。

テーブル統合・分割後の再設計

リファクタリング後、責務が変わったにもかかわらず名前を変更しないと、設計意図が伝わりません。

セキュリティ・監査対応

用途が明確な命名は、

• 権限設計
• 監査ログ確認
• 外部公開制御

の観点でも有効です。

事前確認：絶対にやるべきチェック項目

本番環境でのリネーム前に必ず確認してください。

1. 対象スキーマの確認

SELECT DATABASE();
SHOW TABLES;

接続先DBの取り違えは、最も多い事故原因です。

2. DDLの取得（復旧用）

SHOW CREATE TABLE target_table;

取得して保存しておくことで、

• 外部キー
• インデックス
• エンジン
• 文字コード

を正確に復元できます。

3. 依存関係の洗い出し

確認対象：

• 外部キー
• ビュー
• トリガー
• ストアドプロシージャ
• アプリSQL
• ORM設定
• ETL・BIツール

grepやリポジトリ検索は必須です。

基本：RENAME TABLEでテーブル名を変更する

構文

RENAME TABLE old_table TO new_table;

特徴

• 複数テーブルを1文で変更可能
• スワップ操作が可能
• 別DB移動が可能
• メタデータロック（MDL）が発生

実務では第一選択はRENAME TABLEです。

複数テーブルの一括変更

RENAME TABLE
a TO a_new,
b TO b_new;

注意点

• 左から順に処理される
• 名前衝突に注意
• 一時名を挟む設計が安全

テーブルのスワップ（入れ替え）

本番切替でよく使われるパターンです。

RENAME TABLE
t_old TO t_tmp,
t_new TO t_old,
t_tmp TO t_new;

メリット

• 切替瞬間が短い
• アプリ側の停止時間を最小化できる

注意

• t_tmp が未使用であること
• 長時間トランザクションがないこと

別DB（スキーマ）へ移動する方法

RENAME TABLE db1.t TO db2.t;

必要権限

• 元テーブルへのALTER権限
• 移動先DBでのCREATE権限

落とし穴

• テーブル単位のGRANTは引き継がれない場合がある
• トリガーがあると失敗するケースあり

移動後は必ず権限確認を行いましょう。

ALTER TABLE RENAMEとの違い

構文

ALTER TABLE old_table RENAME new_table;

違いまとめ

実務ではほぼRENAME TABLEが推奨です。

メタデータロック（MDL）の注意点

テーブル名変更はMDL（Metadata Lock）を取得します。

影響例

• 長時間SELECTがあるとリネームが待機
• リネーム待機中にアプリが詰まる

対策

• 低負荷時間に実施
• バッチ停止
• 長時間トランザクション事前確認
• 監視設定

外部キーがある場合の注意

MySQLは制約名を内部生成する場合があります。

例：

table_ibfk_1

問題になるケース

• リネーム後の制約名が既存と衝突
• 制約名が意図せず変更される

安全策

• 事前に制約DROP
• リネーム後に再作成
• DDL比較で確認

ビュー・ストアド・トリガーの影響

ビューやストアド内に旧テーブル名が文字列で残ります。

必須確認項目

• ビューの再実行テスト
• ストアドの動作確認
• トリガー存在確認

特に別DB移動時はトリガーが障害要因になりやすいです。

よくあるエラーと対処

テーブルが存在しない

• スキーマ間違い
• 名前のtypo
  → SHOW TABLESで確認

名前が重複する

• 変更後名が既に存在
  → 一時名を使う

権限不足

• CREATE権限不足
• GRANT未移行

→ 事前に権限棚卸し

本番運用でのベストプラクティス

1. バックアップ

• DDL保存
• 論理バックアップ取得

2. 手順書作成

• 実行SQL
• 事前確認
• 実行後確認
• ロールバック手順

3. 検証環境リハーサル

• ロック時間測定
• 権限確認
• アプリ動作確認

まとめ｜MySQLのテーブル名変更を安全に実施するために

MySQLでテーブル名を変更する際は、

• 基本は RENAME TABLE
• 依存関係の洗い出しが最重要
• メタデータロックを理解する
• 権限確認を怠らない
• 本番前に必ずリハーサル

これらを徹底することで、事故を大幅に減らせます。

テーブル名変更は単なるDDLではなく、システム全体の設計力が問われる操作です。

技術に本気で向き合うエンジニアへ

データベース設計や安全な運用設計に強いエンジニアは、どの現場でも重宝されます。
私たちは、MySQLをはじめとしたRDB設計・パフォーマンスチューニング・安全な本番運用に強みを持つ技術チームです。

もしあなたが、

• データベース設計を本質から理解したい
• 運用レベルまで踏み込んだスキルを磨きたい
• 技術力の高い環境で成長したい

そう考えているなら、ぜひ一度私たちの採用情報をご覧ください。
同じ志を持つ仲間を、私たちは探しています。