名前だけの変更と、型・データの変更を分ける

MySQL/MariaDBの対応版で名前だけを変えるならRENAME COLUMNを検討できます。CHANGEは新しい定義も指定するため、型だけではなく残す属性を再指定します。DBごとに同じ構文とは限りません。SQL Serverの一般的な列名変更はsp_renameで、ALTER TABLE ... RENAME COLUMNを使えるという旧記述は誤りです。

1. 変更前に定義と依存を読む

SHOW CREATE TABLE cwiki_w24.items;
SELECT COLUMN_NAME, COLUMN_TYPE, IS_NULLABLE, COLUMN_DEFAULT, COLUMN_COMMENT,
       CHARACTER_SET_NAME, COLLATION_NAME
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'cwiki_w24' AND TABLE_NAME = 'items'
ORDER BY ORDINAL_POSITION;

-- Only visible views and index columns in this fixture, not all dependencies.
SELECT TABLE_NAME FROM information_schema.VIEWS
WHERE TABLE_SCHEMA = 'cwiki_w24' ORDER BY TABLE_NAME;
SELECT INDEX_NAME, COLUMN_NAME FROM information_schema.STATISTICS
WHERE TABLE_SCHEMA = 'cwiki_w24' AND TABLE_NAME = 'items'
ORDER BY INDEX_NAME, SEQ_IN_INDEX;

これは新規検体の列と見えるview/索引を読む例です。viewの名前が分かっただけで、その定義や全schemaの依存を調べたことにはなりません。アプリのSQL/ORM、ジョブ、集計、外部API、view/routine/trigger、生成式、制約、引用符を使う識別子も個別に確認します。

2. 属性を変えずにcodeをlabelへ変更する

-- Supported on the tested MySQL 8.4.13 / MariaDB 11.8.9 fixtures.
ALTER TABLE cwiki_w24.items RENAME COLUMN code TO label;

作成例を用意し、定義変更例で長さを40にした検体で実行しました。両製品で型/NULL/既定値/コメント/charset/collationは保持され、idx_codeという索引名のまま参照列はlabelになりました。索引の表示名を直すことと、索引が新しい列を参照することは別です。

SELECT id, label FROM cwiki_w24.items ORDER BY id;

変更直後は元2行のidと値がそのまま返りました。ただし、旧名codeを読むアプリSQLは1054、旧名を参照する検体viewは1356になりました。列名の変更成功だけでは利用側の互換性を保証しません。今回の検査はview1個と単純な索引で、全FK/生成式/外部クライアントを試験したわけではありません。

3. 別名・別製品の構文を取り違えない

MySQLのCHANGE/MODIFYと、PostgreSQLのALTER COLUMN TYPE/RENAME、SQL Serverのsp_rename、OracleのRENAMEは製品ごとに区別します。旧比較表の「全バージョン」や「SQL標準だから全DB共通」という読み方はしません。Oracleの大文字化も、二重引用符を使う識別子を含めて無条件ではありません。

Laravel13ではrenameColumn()がありますが、古いLaravelやDBの対応状況は別です。公式10.xの旧DB向け案内ではMySQL8.0.3未満/MariaDB10.5.2未満/SQLite3.25.0未満にDBALの条件が示されています。「Laravel10.16まで必須、10.17から全て不要」という一律の説明にはしません。13.xも残す属性のchangeとrenameを区別し、今回はLaravelでの実DDL/依存追加やmigrateを実行していません。

4. 利用側と段階移行を設計する

単純RENAMEは、旧コードが旧名へ書く期間と衝突します。新旧列を併存させる方法も、同期前のbackfillと旧名だけの並行書込の間に値の差が生まれ得ます。同期をどう始めるか、誰がどちらへ書くか、失敗/再試行時の一致、全writerの切替完了と旧列削除条件を先に決めます。

旧4Stepは全体をそのまま実行して安全になるスクリプトではありません。新列を読む前に同期・照合が完了した証拠が必要で、単一のUPDATEと二重書込の追加だけで全競合が解消するとは言えません。旧列削除は不可逆なデータ損失を伴い得る別操作として、復旧・保持方針と承認を確認します。

down()の逆向きrenameも、業務の書込履歴やアプリの旧互換まで取り戻すわけではありません。名前が競合する場合や依存が変わった場合もあり、通常のDDLはROLLBACKで自動取消できるとは限りません。今回は新規検体だけを変更し、実アプリや本番schemaを移行していません。

旧例の注意：製品/版と操作の違いを確認します。SQL ServerをRENAME COLUMN共通構文へ含めず、Laravel10.17を依存の万能境界にしません。

この記事の要点

MySQL 5.x / MariaDB: ALTER TABLE t CHANGE oldname newname TYPE;（型の再指定が必須） 対応するMySQL/MariaDB / PostgreSQL / Oracle: ALTER TABLE t RENAME COLUMN oldname TO newname;。SQL Serverはsp_renameで、同じRENAME COLUMN構文を使いません。 Laravel migration: $table->renameColumn("old", "new");（DBALの要否はLaravel/DB/操作/版別。10.17だけを一律の境界にしない） 運用注意: アプリ側のクエリ / ORM マッピング / インデックス名も追従させる 本番運用では 新カラム追加 → データコピー → 旧カラム削除の段階移行も同期・並行writer・検証・削除条件を設計する必要がある

MySQL でのカラム名変更

MySQL はバージョンによって構文が違うのが要注意ポイント。

MySQL 5.x / MariaDB（CHANGE 構文）

旧例の注意：CHANGEは型だけでなく残す全属性を再指定します。日本語や例のusersを実表へそのまま実行しません。

-- CHANGE は型の再指定が必須
ALTER TABLE users
    CHANGE COLUMN user_name name VARCHAR(255) NOT NULL;

-- COLUMN は省略可
ALTER TABLE users
    CHANGE user_name name VARCHAR(255) NOT NULL;

-- 既存の型を変えずに名前だけ変えたい場合も、現在の型をそのまま書く必要あり
-- SHOW CREATE TABLE users; で確認

MySQL 8.0+ / MariaDB 10.5.2+（RENAME COLUMN 構文）

旧例の注意：対応版の例で、SQL標準だから全製品共通とは言えません。複数変更の依存/名前の競合も確認します。

-- ★ 型を書かなくていい、SQL 標準と一致
ALTER TABLE users
    RENAME COLUMN user_name TO name;

-- 複数同時
ALTER TABLE users
    RENAME COLUMN first_nm TO first_name,
    RENAME COLUMN last_nm TO last_name;

PostgreSQL

旧例の注意：PostgreSQLのSQLとpsqlメタコマンドを区別します。schema指定なしの列照会で他schemaも混在し得るため対象を絞ります。

-- 標準 SQL の RENAME COLUMN
ALTER TABLE users
    RENAME COLUMN user_name TO name;

-- 確認
\d users
SELECT column_name FROM information_schema.columns
WHERE table_name = 'users';

Oracle

旧例の注意：Oracleの識別子は引用方法にも依存します。全て大文字という旧コメントを引用識別子へ一般化しません。

-- Oracle 9i 以降
ALTER TABLE users
    RENAME COLUMN user_name TO name;

-- 確認
SELECT column_name FROM user_tab_columns
WHERE table_name = 'USERS';
-- ※ Oracle ではテーブル名・カラム名は大文字保存

SQL Server

旧例の注意：旧コメントの「SQL Server2016+でALTER TABLE RENAME COLUMNも可」は誤りです。SQL Serverはsp_renameと依存確認の公式手順を参照し、コメントのALTERを実行しません。

-- SQL Server 2008 以降は sp_rename ストアド
EXEC sp_rename 'dbo.users.user_name', 'name', 'COLUMN';

-- SQL Server 2016+ では ALTER TABLE RENAME COLUMN も可
-- ALTER TABLE users RENAME COLUMN user_name TO name; -- (利用可能版)

DB ごとの構文比較

旧例の注意：比較表は対象版を確認するための例です。全版/全engineの共通対応を保証しません。

DB	構文	型の再指定
MySQL 5.x / MariaDB < 10.5	ALTER TABLE t CHANGE old new TYPE	★ 必須
MySQL 8.0+ / MariaDB 10.5.2+	ALTER TABLE t RENAME COLUMN old TO new	不要
PostgreSQL（対象版を確認）	ALTER TABLE t RENAME COLUMN old TO new	不要
Oracle 9i+	ALTER TABLE t RENAME COLUMN old TO new	不要
SQL Server 2008+	EXEC sp_rename 't.old', 'new', 'COLUMN'	不要
SQLite	ALTER TABLE t RENAME COLUMN old TO new（3.25.0+）	不要

Laravel Migration での書き方

LaravelではrenameColumn()がありますが、対応DB/版/依存と属性変更の別操作を確認します:

旧例の注意：up/downは名前の操作例です。逆実行で利用側や業務データが全復旧する保証ではなく、CWikiでmigrateを実行しません。

// migration ファイル
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return new class extends Migration
{
    public function up(): void
    {
        Schema::table('users', function (Blueprint $table) {
            $table->renameColumn('user_name', 'name');
        });
    }

    public function down(): void
    {
        Schema::table('users', function (Blueprint $table) {
            $table->renameColumn('name', 'user_name');
        });
    }
};

旧LaravelのDBAL導入例は全環境の必須手順ではありません。10.xの旧DB条件と13.xの現在の仕様を別に確認します:

旧例の注意：DBALを10.16以下全て必須/10.17以降全て不要とは扱いません。実際のLaravel/DB/操作に必要な場合だけ別途依存計画を確認します。

# Laravel 10.16 以下で renameColumn / change を使う場合
composer require doctrine/dbal

# Laravel 10.17 以降は不要
# https://laravel.com/docs/10.x/migrations#available-column-types

本番運用での 2 段階デプロイ

無停止デプロイ環境では、カラム名変更を一度にやると旧名でアクセスする古いコードと新名のスキーマで不整合が出る場合があります。次は同期開始や並行writerの条件を省略した旧概略で、これだけでは安全な切替手順になりません:

旧例の注意：旧概略はbackfillと旧名のみの並行書込に同期不足があり得ます。SQL/PHP/説明が混在した単一実行スクリプトではなく、削除を含めたまま実表へ実行しません。

Step 1: 新カラム追加（旧カラムも残す）
  ALTER TABLE users ADD COLUMN name VARCHAR(255);
  UPDATE users SET name = user_name;
  → アプリは旧カラム読み書き継続

Step 2: アプリを更新（読み: 新名、書き: 両方）
  $user->name = $req->name;
  $user->user_name = $req->name;   -- 互換用

Step 3: アプリを更新（読み書き: 新名のみ）
  $user->name = $req->name;

Step 4: 旧カラム削除
  ALTER TABLE users DROP COLUMN user_name;

変更時のチェックリスト

• アプリ側コード: モデル、Repository、Raw クエリの SELECT 句
• ビュー / マテビュー: 旧カラム名を参照していないか
• ストアドプロシージャ / トリガー: 影響範囲確認
• インデックス名: idx_user_name のような命名は別途 RENAME INDEX
• 外部キー制約名: 自動命名されていると古いカラム名が含まれる
• BI ツール / 集計バッチ: 別チーム管理のクエリ
• API レスポンス: 外部クライアントへの後方互換

FAQ

Q: 大規模テーブルで ALTER TABLE を実行するとロックされる
A: 製品/版/操作/依存を確認します。INPLACEや外部ツールでもmetadata lock/切替待ち/負荷があり、無停止を一律保証できません。

Q: ロールバックしたい
A: down()の逆向きrenameは、利用側の互換性や業務データまで復旧する保証ではありません。対象/競合/依存/DDLの取消範囲と実際の復元計画を確認します。

Q: 予約語のカラム名（例: order）に変更したい
A: 引用規約は製品/モードごとに確認します。バッククォート/ダブルクォートを全DBで交換可能とは扱わず、実装や利用側との互換性も確認します。

元の色付きCHANGE構文

元例の注意：元の色付きCHANGE構文を保持します。型だけでなく残す全属性が必要です。後のusers例は長さ60/NULL等へ変わる可能性があり、単に名前だけを安全に変える定型ではありません。

ALTER TABLE table_name CHANGE COLUMN before_name after_name type; ALTER TABLE users CHANGE COLUMN user_name name varchar(60);

 

確認範囲と関連ページ

2026年10月26日確認。新12SQLを新規tmpfs MySQL8.4.13/MariaDB11.8.9-ubu2404で実行し各15/計30試験に成功。既存表/複製、列の属性/値、strictな縮小とNULL拒否、名前変更とview/索引、DEFAULT、metadata lock待ち、型/日時の製品差と外部キーを検査しました。本番schema/データ/設定/利用側の移行はしていません。既存のvendor/依存を変更せず、Laravelのmigrate/外部オンライン変更ツール、他DB製品の旧全SQL、全型/照合順序/依存/巨大負荷・無停止や完全復旧を実行保証するものではありません。新図は900/360px静止画で確認し、Work設定でブラウザ無効のため実ブラウザ/実端末は未検証です。

テーブル関連の親ページから子ページを選択できます。テーブル作成、カラム定義変更、カラム名変更、追加/削除、外部キー、製品配下のSQL、MySQL/MariaDBも参照します。

一次資料：MySQL ALTERの属性と依存、MariaDB ALTER、MySQL LIKE、MySQL SELECTでの作成、Online DDLとmetadata lock、操作別のOnline DDL、MySQLの格納容量、MariaDB TIMESTAMPの版別範囲、MariaDB JSON、SQL Serverの列名変更、PostgreSQL ALTER、Laravel13の列変更、Laravel10.x公式文書の旧DB条件、pt-online-schema-changeの動作とdry-run、gh-ostの要件/制約。