名前変更の前後で、別々に確かめること

RENAME USERはuserとhostの組を変更します。権限/パスワードの継続と、DEFINERの書換え、接続中セッション、アプリ設定の更新は別です。オブジェクトの所有者を丸ごと新名へ移す命令と考えないでください。

1. 旧名・新名と対象hostを照合する

SELECT User, Host
FROM mysql.user
WHERE User IN ('cwiki_w23_reader', 'cwiki_w23_renamed')
ORDER BY User, Host;

新しい隔離検体の名前だけを絞った読取例です。実際は承認済みの対象名に置換し、既存名を勝手に作り直しません。同じuserでもhostが別なら別アカウントです。host省略は%になるため、名前だけで操作を組み立てないでください。候補が表示されないことだけで、権限不足や別接続先を除外したとは言えません。

2. DEFINER依存は変更前に読む

-- Only visible objects in this fixture schema, not a full dependency inventory.
SELECT 'VIEW' AS object_type, TABLE_SCHEMA AS object_schema,
       TABLE_NAME AS object_name, DEFINER
FROM information_schema.VIEWS WHERE TABLE_SCHEMA = 'cwiki_w23_sample'
UNION ALL
SELECT 'ROUTINE', ROUTINE_SCHEMA, ROUTINE_NAME, DEFINER
FROM information_schema.ROUTINES WHERE ROUTINE_SCHEMA = 'cwiki_w23_sample'
UNION ALL
SELECT 'TRIGGER', TRIGGER_SCHEMA, TRIGGER_NAME, DEFINER
FROM information_schema.TRIGGERS WHERE TRIGGER_SCHEMA = 'cwiki_w23_sample'
UNION ALL
SELECT 'EVENT', EVENT_SCHEMA, EVENT_NAME, DEFINER
FROM information_schema.EVENTS WHERE EVENT_SCHEMA = 'cwiki_w23_sample'
ORDER BY object_type, object_schema, object_name;

この読取SQLは検体DB内の、現在の管理接続から見えるview/routine/trigger/eventの一覧です。0件でも他schemaや不可視の依存がない証明ではありません。SQL SECURITYや実行経路、実際の利用者の権限も確認します。対象名が一致するオブジェクトがあれば、名前変更だけで解決すると扱いません。

MySQL8.4ではDEFINERを孤立させるRENAMEは通常拒否されます。検体ではCREATE USER権限だけを持つ管理者の実行が4006でした。強いDEFINER関連権限で警告付き成功を許す条件もありますが、その権限を追加して保護を迂回する案内にはしません。

同じ依存を持つMariaDB11.8.9検体では名前変更が成功してもviewのDEFINER文字列は旧名のままで、呼出しは1449で失敗しました。両製品を同一扱いせず、依存ごとの正式な変更計画と利用側の確認を先に行います。この調査は検体viewだけの動作確認で、全オブジェクトの移行検証ではありません。

3. 依存のない隔離アカウントを変更する例

-- Run only after checking the fixture's destination and DEFINER dependencies.
RENAME USER 'cwiki_w23_reader'@'localhost'
  TO 'cwiki_w23_renamed'@'localhost';
SHOW GRANTS FOR 'cwiki_w23_renamed'@'localhost';

作成記事の隔離検体でSELECTだけを付与したlocalhostアカウントの例です。新名は未作成、DEFINER依存なしとして実行しました。旧名の新規ログインは両製品で1045、新名では同じ検体パスワードで読取成功、別hostの同名アカウントは不変でした。FLUSHは実行していません。SHOW GRANTSにはMariaDBで認証情報が出る場合があるため、結果は公開しません。

4. エラーでも一部成功していないか確認する

新名が既にある場合の単一変更は検体で1396となり、元の利用者は残りました。一方、複数の変更の一つに存在しない旧名を混ぜた検査では、MySQL8.4.13は全体を変更せず、MariaDB11.8.9は有効な組だけ変更して1396を返しました。MariaDBのエラーを「何も変わらなかった」と扱って同じSQLを再投入しません。

変更の直前/直後に対象アカウント集合と権限・依存を照合します。SQL文としての全体成功/失敗と、利用者がROLLBACKで元へ戻せることは別です。元へ戻すRENAMEも名前の競合や依存がある別操作なので、無条件の復旧策とは言えません。

5. 利用側の切替と既存接続を計画する

アプリのsecret、ジョブ、監視、接続pool、外部連携に旧名が残っていないか確認します。既存接続が残るかどうかだけで無停止/無影響を保証しません。権限の反映時機や現在のセキュリティコンテキストを製品別に調べ、新規接続と必要な操作の結果を確認します。既存poolの切替はこの検体では試験していません。

このページの既存コードは構文・単一/複数・host変更の比較用に残します。接続元の拡大、DROP/CREATEによる再作成、パスワード変更を同時にまとめると、障害原因と影響を切り分けにくくなります。名前だけが目的なら、必要な変更を増やさない計画にしてください。

旧例の注意：要約の権限条件は基本条件です。read_onlyやDEFINER保護など製品/版/設定の追加条件を除外しません。

この記事の要点

RENAME USER 文を使うとユーザーアカウントを削除・再作成せずに名前を変更できる ユーザーは「名前＋接続元ホスト」で識別されるため、'user'@'host' の組み合わせ単位で変更する 権限/パスワードは引き継がれるが、DEFINERは自動移行しない。利用側の接続切替は別に計画する 実行には CREATE USER 権限または UPDATE 権限（mysql システムDB に対する）が必要

RENAME USER 文の概要

MariaDB/MySQL で既存のユーザーアカウントの名前を変更するには RENAME USER 文を使用します。「ユーザーを一度削除してから作成し直す」操作と違って、権限定義（GRANTで付与されたもの）とパスワードは引き継がれます。DB/表の自動削除やDEFINERの自動書換えは行いません。アカウント運用上の都合で命名規則を変えたい場合や、アプリ刷新に伴ってアカウント名を整理したい場合に便利な構文です。

構文

旧例の注意：日本語は置換箇所で、user/hostを別々に引用します。既存名と依存を事前照合します。

RENAME USER '旧ユーザ名'@'ホスト' TO '新ユーザ名'@'ホスト';

MariaDB/MySQL ではユーザーは「ユーザー名」と「接続元ホスト」のペアで識別される点に注意が必要です。'app_user'@'localhost' と 'app_user'@'%' は別アカウントとして扱われるため、両方を変えたい場合は両方の RENAME 文を発行します。

使用例

例1：単一アカウントの名前変更

旧例の注意：旧名/新名は例です。既存アカウントへ試すのではなく、変更前の依存と利用側切替を計画します。

-- 旧名 old_user → 新名 new_user に変更（接続元はそのまま localhost）
RENAME USER 'old_user'@'localhost' TO 'new_user'@'localhost';

例2：複数アカウントを一括変更

カンマ区切りで複数のアカウントを 1 文にまとめて変更することもできます。

旧例の注意：複数変更はMariaDBでは1396でも一部成功し得ます。エラーなら全件不変と考えて再投入しません。

RENAME USER
    'devuser'@'localhost' TO 'app_dev'@'localhost',
    'devuser'@'%'         TO 'app_dev'@'%';

例3：ホストごと変更する

接続元の制限を緩めたい／厳しくしたい場合は、ホスト部分を書き換えます。

旧例の注意：コメントの「LAN全体から接続」は保証ではありません。hostの文字列パターンだけでは経路/認証/ネットワーク境界は決まりません。接続元を広げる旧例をそのまま実行しません。

-- localhost からの接続のみだったユーザーを、社内 LAN 全体から接続できるように変更
RENAME USER 'batch'@'localhost' TO 'batch'@'192.168.10.%';

権限と影響範囲

旧例の注意：権限/認証属性の継続とDEFINER/既存接続の状態は別です。表の行を無停止の保証として使いません。

項目	引き継ぎ
GRANT で付与された権限	引き継がれる
パスワード	引き継がれる（再設定不要）
所有オブジェクト（VIEW / STORED PROCEDURE 等の DEFINER）	自動書換えなし。MySQL8.4は孤立を生む変更を通常拒否、MariaDB検体は旧名が残った
現在接続中のセッション	無影響と保証しない。権限の反映条件と既存/新規接続を別に確認
アプリの接続文字列	手動で書き換えが必要

実行に必要な権限

RENAME USER の実行には次のいずれかが必要です。

• グローバルな CREATE USER 権限
• mysql システムデータベースに対する UPDATE 権限

必要な権限を持つ管理者が実行します。root利用を定型にせず、MySQLのread_onlyやDEFINER保護の追加条件も確認します。

注意点とハマりどころ

• 同名アカウントを TO で指定するとエラーになります。新名は既存に存在しないユーザー名にしてください。
• 同時に走るアプリの接続文字列を忘れずに更新します。古い名前のままだとログインできなくなります。
• 通常のRENAME USER後にFLUSH PRIVILEGES;は不要です。既存接続への反映条件や利用側切替をFLUSHで代用しません。
• DEFINERは自動書換えされません。MySQL8.4の拒否/警告条件とMariaDBの旧名残存を区別し、変更前に依存を調べます。information_schema.routines や views を SELECT して確認しましょう。

確認方法

旧例の注意：変更後だけでなく前にも照合します。MariaDBのSHOW GRANTS出力に認証情報を含む場合があり、結果全文を公開しません。

-- 変更後にユーザー一覧を確認
SELECT User, Host FROM mysql.user WHERE User IN ('old_user','new_user');

-- 権限が引き継がれているかを確認
SHOW GRANTS FOR 'new_user'@'localhost';

RENAME USER と DROP/CREATE の使い分け

旧例の注意：名前変更と権限/認証の変更をまとめる必須手順ではありません。DROP/CREATEでの再作成や広いhost化は別の影響/承認を確認します。

シーン	推奨手段
名前だけを変えたい（権限は継続、DEFINER依存は別確認）	RENAME USER
権限も一新したい	REVOKE/GRANT等の対象を個別設計。DROP/CREATEによる再作成を自動的に選ばない
接続元ホストの制限だけ変えたい	host変更の照合/接続元拡大/利用側の影響を確認してRENAMEを計画
パスワードも変えたい	名前と認証を分けて計画。認証方式/秘密値の更新が必要な場合だけ別途ALTER USER

関連記事

• MySQL & MariaDB
• ユーザー関連
• ユーザー作成
• MySQL/MariaDBへの接続

確認範囲と関連ページ

2026年10月26日確認。掲載した新8SQLをローカルの新規tmpfs MySQL8.4.13/MariaDB11.8.9-ubu2404で実行し、各12/計24試験に成功しました。作成だけの表読取拒否、SELECT許可と書込拒否、IF NOT EXISTS後の旧/別パスワード、別hostの保持、RENAMEの接続/権限/衝突/複数指定/DEFINER viewの差を検査しました。本番アカウント/認証/権限/DB設定には変更していません。全製品/旧版/全認証pluginやTLS実通信、replication、既存pool、全DEFINERオブジェクト、旧比較の全SQLを実行保証するものではありません。新図は900/360pxの静止画で文字枠を確認し、実ブラウザ/実端末の検証とは区別しています。

ユーザー関連の親ページから子ページを選択できます。作成、名前変更、一覧、製品配下のSQL、MySQL/MariaDBも参照してください。

一次資料：MySQL CREATE USERと既存名・秘密情報、MariaDB CREATE USERとhost、MySQL RENAME USERとDEFINER保護、MariaDB RENAME USERの部分成功、権限変更の反映、MySQLアカウント名とhost、MariaDB mysql.userの互換view、MySQL SHOW GRANTSとロール、MariaDB SHOW GRANTS、MySQL旧native認証の廃止、PostgreSQL psqlのロール一覧、PostgreSQLロール、Oracle DBA_USERS。