MySQLの初期root認証は、製品・導入元・初期化方法によって異なります。「初回なら必ずログに仮パスワードがある」とは限りません。初期値の確認と、現在の資格情報を失った場合の復旧を分け、まず実際の環境と管理経路を確認します。

初期値と現在の資格情報を区別する

1. MySQLかMariaDBか、版、配布元、ホスト/コンテナ/マネージドDBを確認する。
2. 新規の空データ領域か、既存DBを引き継いでいるか、後からALTER USER等で変更したかを確認する。
3. 認証方式と許可された管理経路を調べる。初期ログ/現在の環境変数/古い設定ファイルを現行の正解と決めつけない。
4. 秘密値の確認が必要な場合も、ログ全文やdocker inspect全文を公開しない。確認と資格情報の変更は別の承認された作業にする。
5. 分からなくてもデータ領域/ボリュームを削除せず、正規の復旧計画へ進む。

Dockerの既存データ領域に対してMYSQL_ROOT_PASSWORDを変更して起動しても、既存アカウントのパスワードは変更されません。環境変数を現在の秘密値の証明と扱わず、安全な保管先と更新履歴を確認します。

一次資料: MySQLの初期化方式、Docker公式MySQLの初期化と既存DB、コンテナのinspect、イメージのhistory。

この記事の要点

初期認証は導入/初期化方式次第。temporary passwordをログへ発行する方式もあるが、全環境共通ではない 確認前に実ログ先と権限を確認。ログには秘密値があるため、出力を公開/転送しない 配布イメージ/管理サービスごとの公式手順と秘密情報保管先を確認し、固定の保存場所を保証しない Docker公式MySQLは空のデータ領域の初期化設定と既存DBを区別する。環境変数/初期化スクリプトを変更しても既存DBが再設定されるわけではない 不明な場合は承認済み管理経路を確認。認証無効化やボリューム削除で初期化し直す手順には進まない 初期セットアップも変更作業。対話ツールの削除/認証変更対象と既存利用への影響を確認して承認する

MySQL root 初期パスワードの確認

MySQLの--initializeはランダムな失効済みパスワードを生成しますが、--initialize-insecureは別動作で、パッケージやコンテナの初期化処理も異なります。後者の使用を推奨する意味ではありません。既存データ領域を初期化し直すのはデータ損失につながるため、確認手順として実行しません。

1. yum / dnf で入れた MySQL 5.7+ / 8.0

下はログに仮パスワードが発行される導入方式の旧例です。全配布物の保存先ではありません。表示された秘密値や例示値を公開/再利用しないでください。mysql_secure_installationの「必須」コメントも一律手順ではなく、削除・資格情報変更の影響を確認する必要があります。

# 初期 temporary password を確認
sudo grep "temporary password" /var/log/mysqld.log

# 出力例
# 2026-05-17T08:12:34.123456Z 1 [Note] A temporary password is generated for root@localhost: xK6!aQwLp&z9

# ログイン
mysql -u root -p
# Enter password: xK6!aQwLp&z9

# 初期セットアップ（必須）
mysql_secure_installation

mysql_secure_installationは以下のような選択肢を扱う変更ツールです。製品/版で動作が異なり、全項目が常に実行される意味でも、既存DBへ無条件に適用する意味でもありません:

• root パスワードの再設定（強度ポリシー有効化）
• 匿名ユーザーの削除
• remote からの root ログインを禁止
• test データベースの削除
• 権限テーブルのリロード

2. apt（Debian / Ubuntu）で入れた MySQL

Debian/Ubuntuでも配布元・製品・版・移行履歴によって設定が異なります。下はdebian-sys-maintを使う旧例で、debian.cnfに現在も有効な資格情報が必ずあるとは限りません。ファイル全体の表示は秘密値を露出し得るため、確認権限と取扱いを確認し、一般的な接続回避策にはしません。

# debian-sys-maint アカウントでログイン
sudo cat /etc/mysql/debian.cnf

# 出力例
# [client]
# host     = localhost
# user     = debian-sys-maint
# password = aB3xy7XYZqW0pLn
# socket   = /var/run/mysqld/mysqld.sock

# このユーザーでログインして root パスワードを変更
sudo mysql --defaults-file=/etc/mysql/debian.cnf

MySQLのauth_socketとMariaDBのunix_socketは別機能です。sudoなら必ず接続できるとは限りません。下のALTER USERは認証方式/パスワードを変える旧例で、確認のために実行しません。mysql_native_passwordへの差し戻しも通常の解決策にしません:

# パスワード不要で root にログイン（同じ OS ユーザーから）
sudo mysql

# パスワード認証へ切り替えたい場合
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'NewStrongPass!';
FLUSH PRIVILEGES;

3. Bitnami / AWS Marketplace / クラウドイメージ

BitnamiやMarketplaceイメージは、対象配布物の公式手順で初期資格情報の扱いを確認します。全イメージが同じ平文ファイルを持つとは限りません。下のRDS CLIは秘密値の参照ではなく、マスターパスワードを変更する旧例です。--apply-immediatelyは保留中の別変更にも影響し得ます。対象/依存先/秘密情報保管方式を確認する別作業なので、そのまま実行しないでください。公式CLIの変更対象と適用条件を照合してください。

# Bitnami の場合
cat /home/bitnami/bitnami_credentials

# 出力例
# Welcome to the Bitnami WordPress
# The default username is 'user' and the application password is 'XXXXXXXXX'
# MySQL root password: ZZZZZZZZZZ

# ログイン
mysql -u root -p

# OCI/GCP のマネージドサービスは管理コンソールで設定
# AWS RDS は作成時に指定したマスタパスワード（後から CLI でリセット可）
aws rds modify-db-instance --db-instance-identifier mydb \
    --master-user-password 'NewPass!' --apply-immediately

4. Docker 公式イメージ

以下はDocker公式MySQLの旧例です。MYSQL_ROOT_PASSWORD以外にもランダム生成等の初期化方式があるため、未指定なら必ず失敗するとは限りません。MariaDBは対象イメージの別ドキュメントで確認します。旧docker run/Composeは固定の例示パスワード・ホストへの3306公開を含むので、そのまま起動しないでください。docker inspect/logsには秘密値が含まれ得ます。

# docker run で指定
docker run -d --name mysql8 \
    -e MYSQL_ROOT_PASSWORD=MyR00tPass! \
    -e MYSQL_DATABASE=appdb \
    -e MYSQL_USER=appuser \
    -e MYSQL_PASSWORD=AppPass! \
    -p 3306:3306 \
    mysql:8.0

# パスワードを忘れた場合は環境変数で確認
docker inspect mysql8 | grep MYSQL_ROOT_PASSWORD

# ランダム生成させる
docker run -d --name mysql8r -e MYSQL_RANDOM_ROOT_PASSWORD=yes mysql:8.0
docker logs mysql8r 2>&1 | grep "GENERATED ROOT PASSWORD"

Docker公式MySQLの初期化スクリプトは空のデータ領域を初期化する時のものです。既存DBでは環境変数やここへのSQL追加でパスワードが更新されるわけではありません。下は新規環境の旧例で、既存ボリュームを消して再実行する手順にはしません:

# docker-compose.yml
services:
  mysql:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: MyR00tPass!
      MYSQL_DATABASE: appdb
    volumes:
      - ./initdb:/docker-entrypoint-initdb.d  # *.sql / *.sh が初回起動時に実行される
      - mysql_data:/var/lib/mysql
    ports:
      - "3306:3306"

volumes:
  mysql_data:

5. パスワードを完全に忘れた場合の復旧

下は認証を無効化する危険な旧例で、一括実行不可です。 ローカル利用者にも全権限を与え得るため、許可された運用担当が公式の版別復旧手順で計画します。killallは別インスタンスまで止め得るので使用せず、対象を正常停止します。シェルとSQLの混在、mysqld_safeの配布差、DB専用OSユーザー/所有権、通常復帰の実効設定を確認する必要があります。

# 1. 停止
sudo systemctl stop mysqld

# 2. skip-grant-tables で起動
sudo mysqld_safe --skip-grant-tables --skip-networking &

# 3. パスワード無しでログイン
mysql -u root

# 4. パスワードリセット (MySQL 8.0)
FLUSH PRIVILEGES;
ALTER USER 'root'@'localhost' IDENTIFIED BY 'NewStrongPass!';
FLUSH PRIVILEGES;
EXIT;

# 5. 通常起動へ戻す
sudo killall mysqld
sudo systemctl start mysqld
mysql -u root -p

確認方法まとめ表

環境	確認方法
MySQL 5.7+ / 8.0（rpm）	導入方式と実ログ先を照合。秘密値の出力を公開しない
MySQL 8.0（apt/Ubuntu）	許可済みOSユーザー・ソケット・実際の認証方式を確認
MariaDB（apt）	製品/配布版の管理接続手順を確認。固定のメンテ用資格情報を仮定しない
Bitnami	対象イメージの公式手順と権限を確認。ファイルをそのまま公開しない
Docker 公式	初期化方式と既存DBを照合。inspect/logsの秘密値を公開しない
AWS RDS	作成時のマスタパスワード（コンソール / CLI でリセット可）
忘れた場合	承認された管理/復旧経路を先に確認。認証無効化を初手にしない

FAQ

Q: /var/log/mysqld.log に temporary password が無い
A: 初期化方式が異なる、出力先/対象インスタンスが違う、ログ保持等が考えられます。まず導入記録と実ログ先を確認し、不在だけで初期化失敗としません。過去ログにも秘密値があり得るため一括表示/公開せず、DB再初期化で探し直しません。

Q: ALTER USER で「Your password does not satisfy the current policy requirements」
A: 実際に有効な検証方式とポリシーを確認し、それに適合する新しい秘密値を用意します。固定8文字で必ず通るとは限らず、LOWへ弱める対処はしません。

Q: パスワードリセット後も Access denied になる
A: User/Hostと接続先・ドライバ・認証方式を照合します。localhostと%は別アカウントなので、原因未確認で両方をリセットしたり、外部向けrootを追加したりしません。

セキュリティの注意

• mysql_secure_installationも変更作業として対象/影響/承認を確認。既存データを自動削除しない
• rootの外部利用を最小化する計画を立てる。既存アカウントを無断削除しない
• アプリ用ユーザーを別途作成し、最小権限のみ付与
• パスワードを Git に commit しない（環境変数 / Secrets Manager 経由）
• docker inspectのコンテナ設定とdocker historyのイメージ履歴を区別する。実行時環境変数/ビルド時ENV/ログ/ファイルの露出を別々に確認し、安全な秘密情報管理を使う

関連手順を選ぶ

rootパスワードの通常変更と復旧、ALTER USERの属性と影響から目的に合うものを選べます。エラーはMySQLエラー一覧の子ページから選んでください。