本稿は MariaDB / MySQL のユーザー関連 SQL に関する記事です。データベースユーザの作成・確認・変更・削除・権限付与といった、ユーザ管理の操作をまとめます。

子ページから項目を選択してください。

本ページの子ページ

• ユーザー作成 — CREATE USER
• ユーザー名変更 — RENAME USER
• ユーザー一覧の表示 — SELECT ... FROM mysql.user

最初に分ける：接続・アカウント・権限

DBのユーザーは、OSにログインするユーザーやアプリ内の会員とは別です。MySQL/MariaDBでは名前と接続元hostの組を確認してから操作します。作成できたこと、接続できたこと、目的の表を操作できたことはそれぞれ別の成功条件です。

作成の手順はユーザー作成、既存名の変更はユーザー名変更、調査だけならユーザー一覧の表示へ進んでください。この3本が本ページの実際の子ページです。削除や権限の取消を、一覧確認の続きとしてまとめて実行する必要はありません。

1. 接続済みなら、自分の照合先から読む

SELECT VERSION() AS server_version, USER() AS presented_identity,
       CURRENT_USER() AS matched_account, DATABASE() AS current_database;
SHOW GRANTS;

これは接続済みのセッションで実行する読取SQLです。USER()はクライアントが提示した名前等、CURRENT_USER()は権限判定に使うアカウントを調べる手掛かりです。通常の直接接続で比較し、両者が常に同じ文字列だと決めつけません。ストアド処理のDEFINERコンテキストとは区別します。DATABASE()がNULLなら、この接続で既定DBが選択されていません。

SHOW GRANTSは現在のアカウントの権限確認です。ただし、MariaDBの検体では認証ハッシュを含む出力がありました。MySQLの出力と同一だと考えず、結果をそのまま記事・チャット・ログへ転載しないでください。名前/host/権限の組合せ自体も内部情報になり得ます。

2. host欄は接続許可の一条件で、ネットワーク設定ではない

localhostや127.0.0.1というhost欄と、クライアントの接続先指定・socket/TCPの選択を分けます。MariaDBのLinux環境でlocalhostアカウントが照合されるのはUNIX socket経由で、loopbackのTCPと同じではありません。MySQLも名前解決/候補アカウント/接続方式を確認します。単にhost違いのアカウントを二重作成して直す手順にしません。

%はhostの広いパターンであり、認証不要や全表への操作許可を意味しません。ファイアウォール、待受先、TLS、資格情報、より具体的なアカウントの照合も関係します。MySQL8.4ではhostの%/_ wildcardは非推奨です。既存の%をこの調査で一括置換せず、実際の接続元を調べて変更計画を立てます。

3. 権限は必要な対象と操作だけを設計する

読取専用の利用者なら、対象表へのSELECTと、必要な接続条件を先に検討します。CRUD全部、全DBのALL PRIVILEGES、GRANT OPTION、システムDB全体のSELECTは必須ではありません。CREATE USERを実行する管理者の権限と、作成されるアプリ利用者の権限も別です。

通常のCREATE USER/GRANT/REVOKE/RENAME USERの後に「念のため」のFLUSH PRIVILEGESは不要です。grant表の直接更新は勧めません。既存接続の権限がいつ変わるかは権限の種類や製品で異なるため、既存のpoolと再接続の両方を計画して確認します。

4. MySQLとMariaDBを同じ認証設定にそろえない

検体の新規パスワード認証はMySQL8.4.13がcaching_sha2_password、MariaDB11.8.9がmysql_native_passwordでした。これは検体の結果で、全構成の推奨や両者の認証機能の同一性ではありません。MySQLのmysql_native_passwordは8.4で既定無効、9.0で削除されています。古いクライアントのために自動的に戻さず、クライアント更新/接続方式/TLS/対象版を先に調べます。

MariaDB10.4以降のmysql.userは互換viewで、mysql.global_privが実体です。JSONや認証文字列の全量取得を通常の一覧SQLに追加しません。認証plugin、複数認証、期限/ロック/パスワードポリシーも、製品/版/有効なpluginごとに確認します。

このページの早見表を読むとき

以降の既存の早見表は、操作と権限スコープを比較する資料として残しています。作成・更新・削除を上から順に実行するスクリプトではありません。とくに公開パスワード、%やALL、DROPを既存環境へコピーしないでください。新しい実行例は子ページの「隔離検体の作成例」で、読取可能/書込拒否を分けて示します。

ユーザー関連 SQL の早見表

旧例の注意：変更/削除を順次実行する一覧ではありません。%や公開秘密値を既存環境へ追加せず、通常の管理SQL後にFLUSHは不要です。

操作	SQL
ユーザ一覧	SELECT user, host FROM mysql.user;
ユーザ作成	CREATE USER 'app'@'%' IDENTIFIED BY '********';
名前変更	RENAME USER 'old'@'%' TO 'new'@'%';
パスワード変更	ALTER USER 'app'@'%' IDENTIFIED BY '********';
削除	DROP USER 'app'@'%';
権限付与	GRANT SELECT, INSERT, UPDATE, DELETE ON myapp.* TO 'app'@'%';
権限取消	REVOKE INSERT ON myapp.* FROM 'app'@'%';
権限確認	SHOW GRANTS FOR 'app'@'%';
grant表の再読込（通常の管理SQL後は不要）	FLUSH PRIVILEGES;

ユーザー名と host 部分の意味

MySQL / MariaDB のユーザは 'user'@'host' のペアで識別されます。同じ user 名でも host 部分が違えば別のユーザ扱いで、別々の権限・パスワードを持てます。

旧例の注意：hostの表は照合条件の比較です。localhost=常にsocketという全製品共通の規約ではなく、%も認証不要ではありません。

host 指定	意味
'localhost'	ローカル接続の照合条件。接続方式/製品別の規則と区別
'127.0.0.1'	IPv4 loopbackのアドレス。host照合と実際のTCP経路を区別
'%'	広いhostパターン。認証/権限や経路・候補照合は別。誰でも接続可ではない
'10.0.0.%'	IPの文字列パターン。netmask/CIDRの構文と区別
'web01.example.com'	特定の FQDN (DNSが信用できる前提)

権限の階層

旧例の注意：権限のスコープを比較する旧SQLで、ALLやGRANT OPTIONをアプリへまとめて付与しません。

階層	例
グローバル (すべての DB)	GRANT ALL ON *.* TO 'u'@'%';
データベース単位	GRANT SELECT ON myapp.* TO 'u'@'%';
テーブル単位	GRANT SELECT ON myapp.users TO 'u'@'%';
カラム単位	GRANT SELECT (id, name) ON myapp.users TO 'u'@'%';
ルーチン	GRANT EXECUTE ON PROCEDURE myapp.p TO 'u'@'%';

代表的な権限

旧例の注意：権限の名称/対象スコープ/製品差は版別に確認し、全てを必要権限として付与しません。

権限	用途
SELECT	参照
INSERT / UPDATE / DELETE	データ更新
CREATE / ALTER / DROP	DDL
INDEX	インデックス管理
EXECUTE	ストアド呼出
CREATE USER	ユーザ管理
RELOAD	FLUSH 実行
REPLICATION CLIENT / SLAVE	replication関連の個別権限。全管理権限の総称ではない
ALL PRIVILEGES	指定スコープで付与される権限。GRANT OPTION等を一律に含む意味ではない
GRANT OPTION	他人へ権限を付与する権限

典型的なアプリ用ユーザの作成

旧例の注意：公開パスワード/%/DB全体のCRUDを使う旧例です。必要最小限の定型とはしません。末尾の「念のため」のFLUSHは不要で、実行例は子の「隔離検体の作成例」を参照してください。

-- 1. ユーザ作成 CREATE USER 'app'@'%' IDENTIFIED BY 'StrongPass!2026'; -- 2. 必要最小限の権限を付与 GRANT SELECT, INSERT, UPDATE, DELETE ON myapp.* TO 'app'@'%'; -- 3. 確認 SHOW GRANTS FOR 'app'@'%'; -- 4. 反映 (CREATE USER / GRANT 後は自動反映だが、念のため) FLUSH PRIVILEGES;

パスワードに関する近年の変更

• MySQL 8.0 から既定の認証プラグインが caching_sha2_password に変更
• 古いクライアントは対応状況を確認。MySQLのnative方式へ自動変更せず、8.4の既定無効/9.0の削除を考慮
• 保存方式は認証pluginによる。平文秘密値がクライアント履歴やログへ残る条件もあり、一切残らないとは言えない
• 期限/履歴/複雑度は製品/版/有効なpluginとポリシーを個別に確認

運用上の注意

• 本番アプリ用ユーザに GRANT OPTION や ALL PRIVILEGES を渡さない
• 同じ user 名でも host 違いで権限が別。意図しない権限漏れがないかチェック
• % の host は便利だが、可能なら送信元 IP / VPC ネットワークで絞る
• 権限変更は本番反映前に検証環境で動作確認
• replicationの書込先/フィルタ/伝搬を確認し、全構成での自動伝搬を前提にしない
• クラウド (RDS / Aurora) では一部のシステム権限が制限される。サービス固有のロールを利用

関連

• 親カテゴリ: SQL (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。