MySQLバージョン確認の完全ガイド｜サーバとクライアントを3分で確定する方法│はりぼう記

「MySQLに繋がらない」「ローカルでは動くのに本番だけ失敗する」――そんなとき、最初にやるべきは“いま使っているMySQLのバージョンを確定すること”です。ところが、mysql --versionで出てきた数字を見て「これがサーバのバージョンだ」と思い込むと、原因調査が遠回りになりがちです。なぜなら、MySQLには接続先のサーバと、手元の**クライアント（mysqlコマンド）**があり、それぞれ別のバージョンを持つからです。

本記事では、接続できる・できないの状況に合わせて、3分でサーバ版とクライアント版を取り違えずに確定する手順を、比較表とチェックリスト付きで整理します。Dockerや複数インストールで環境が混在していても迷わない判定フロー、認証方式の違いなど“バージョン差が実害になるポイント”までまとめているので、読み終えた瞬間に「次に何を確認すべきか」がはっきりします。

※本コンテンツは「記事制作ポリシー」に基づき、正確かつ信頼性の高い情報提供を心がけております。万が一、内容に誤りや誤解を招く表現がございましたら、お手数ですが「お問い合わせ」よりご一報ください。速やかに確認・修正いたします。

1 MySQLバージョン確認が必要になる場面
- 1.1 互換性と不具合切り分けで最初に見るべき理由
  - 1.1.1 最短で確定したい場合（接続できる／できないの分岐）
- 1.2 MySQL 8系の認証変更などバージョン差の代表例
2 MySQLバージョン確認で最短の答えを出す方法
3 MySQLバージョン確認でサーバとクライアントを区別する
4 MySQLバージョン確認を詳しく行うコマンド
5 MySQLバージョン確認で困るときのトラブルシューティング
6 MySQLバージョン確認のよくある質問
7 MySQLバージョン確認の比較表とチェックリスト
8 参考にした情報源

MySQLバージョン確認が必要になる場面

互換性と不具合切り分けで最初に見るべき理由

MySQLのバージョンは、アプリの動作・接続の成否・SQLの互換性に直結します。たとえば次のような場面では、原因調査の最初に「いま動いているMySQLは何系か」を確定させるだけで、遠回りを避けられます。

ローカルでは動くのに、本番でだけSQLが失敗する
フレームワークやDBドライバを更新したら、急に接続できなくなった
監査・棚卸しで「どの環境がどのバージョンか」を一覧化したい
脆弱性対応やアップグレードで、現状把握が必要になった

ここで重要なのは、MySQLには「サーバ」と「クライアント」があり、それぞれが別々にバージョンを持つことです。手元の mysql コマンドが新しくても、接続先サーバが古いことはよくあります。逆に、サーバは新しいのに手元のクライアントやコネクタが古く、そこで詰まることもあります。

まずは、次の“最短分岐”で、あなたの状況に合う手順を選んでください。

最短で確定したい場合（接続できる／できないの分岐）

MySQLサーバに接続できる場合

サーバ版：接続後に SELECT VERSION();
クライアント版：接続前（または別端末でも）に mysql --version
→ この2つが揃えば、ほぼ確定です。

MySQLサーバに接続できない場合

まずクライアント版だけでも mysql --version で確定
サーバ版は、Dockerイメージタグ、構成管理、運用資料から“暫定確認”
接続が復旧したら、必ず SELECT VERSION(); で確定する
→ “暫定”と“確定”を分けるのが事故防止になります。

MySQL 8系の認証変更などバージョン差の代表例

「バージョン確認が必要になる典型例」として、認証方式の違いがあります。MySQL 8.0.4から、MySQLサーバのデフォルト認証プラグインが mysql_native_password から caching_sha2_password に変更されました。
この変更自体は安全性の観点では自然な流れですが、環境によっては“接続できない”という形で表面化します。

さらに、クライアントライブラリ（例：コネクタや libmysqlclient）側の対応状況によっては互換性の差が出ます。アップグレードに関する公式ドキュメントでも、caching_sha2_password とクライアント側の互換性に触れられています。

つまり、「接続できない＝パスワードが間違い」と決めつける前に、サーバとクライアントのバージョンを分けて確認することが最短ルートになります。

MySQLバージョン確認で最短の答えを出す方法

接続前にmysqlクライアントのバージョンを確認する

接続前に分かるのは、あなたが実行している mysql（コマンドラインクライアント） の情報です。MySQL公式ドキュメントでも、mysqlクライアントには --version オプションがあり「バージョン情報を表示して終了」すると明記されています。

まずは最短で次のどちらかを実行します。

mysql --version
mysql -V

どちらも同じ目的で使われます（環境により片方が通りやすい場合があります）。

ここが落とし穴：表示に“2つの数”が出ることがある

環境によっては、次のように2つの数が表示されることがあります（例の形です）。

mysql Ver 14.xx Distrib 8.0.xx, for Linux ...

このとき、どちらを「MySQLのバージョン」と読むべきかで混乱しがちです。実務上は、次の考え方が安全です。

ここで出るのは基本的に“クライアント側の情報”
どの数字の読み方が気になっても、接続後に SELECT VERSION(); でサーバ版を確定すれば、取り違えがなくなる
もし「サーバ版だけ知りたい」のに接続できないなら、まず接続性の回復（認証・ホスト・ポート）を優先し、復旧後に確定する

加えて、端末に複数のmysqlが入っていると、あなたが想定していないmysqlを叩いていることがあります（Homebrew、XAMPP、WSL、Docker、社内配布ツールなど）。その場合は、後述の「判定フロー」とチェックリストが効きます。

接続後にMySQLサーバのバージョンを確認する

サーバのバージョンは、接続してサーバに聞くのが最も確実です。最短は以下です。

SELECT VERSION();

この1行で、接続先MySQLサーバが返すバージョンを確定できます。「いま自分が見ているバージョンがサーバのものかどうか」で迷う余地がありません。

もし権限が弱い環境でも、サーバへ接続できていれば、後述する SHOW VARIABLES は「権限不要（接続できることのみが必要）」と公式に明記されています。
そのため、監査や棚卸しで「最小権限でバージョンだけ見たい」場合にも選択肢になります。

結果を読み間違えないための要点

バージョン確認で最も多いミスは、「見ている値が server なのか client なのか」を混同することです。ここだけは固定で覚えてください。

mysql --version / mysql -V
→ クライアント（あなたの端末上のmysqlコマンド）
SELECT VERSION();
→ サーバ（接続先のMySQL）

この2つを同時にメモしておけば、調査・相談・エスカレーションも一気に楽になります。たとえば障害対応で「サーバは8.0系、クライアントは5.7系」などと整理できるだけで、原因候補が絞れます。

MySQLバージョン確認でサーバとクライアントを区別する

mysql –versionが示すもの

mysql --version が示すのは、あなたが実行している mysqlクライアント です。ここで意識したいのは、次の3点です。

同じ端末でも、mysqlが複数入っていることがある
PATHの順序で、起動されるmysqlが変わる
DockerやWSLなど“別世界”のmysqlを見ている可能性がある

たとえば「ローカルでMySQLを入れたつもり」でも、実際にはIDEが同梱しているクライアントを使っていたり、WSL側のmysqlとWindows側のmysqlが別物だったりします。

この問題は、次のように“どの実体を叩いているか”を特定すると収束します。

macOS / Linux：which mysql
Windows：where mysql

この結果が「想定しているインストール元」かどうかを見てください。想定と違うなら、次のいずれかが原因であることが多いです。

PATHの順番が違う
以前入れた古いmysqlが残っている
ターミナルの種類（PowerShell、WSL、Git Bashなど）が違う
Dockerコンテナ内で確認すべきなのに、ホスト側で確認している

SELECT VERSION()が示すもの

SELECT VERSION(); は、接続先MySQLサーバが返す値です。ポイントは次のとおりです。

どの端末から接続しても、同じサーバなら同じ値が返る
ローカルだと思っていても、実際には別ホスト（別コンテナ、別RDS等）に繋いでいると値が変わる
したがって、挙動差が出たときは「どこに繋いでいるか」を確定させる意味でも有効

逆に、サーバに接続できない状況では SELECT VERSION(); は使えません。そこで「接続できないときの暫定手段」と「復旧後の確定」という二段構えが必要になります（後述します）。

Dockerや複数環境で混乱しない判定フロー

混在環境での誤読を減らすには、次の順序で“確定”していくのが効果的です。調査のたびにこの順序に戻ると、迷いが発生しにくくなります。

判定フロー（迷ったらこれ）

ステップ1：いま叩いているmysqlの実体を確定

which mysql（Windowsはwhere mysql）
表示されたパスをメモする
想定と違えば、PATHやシェル環境（WSL/PowerShell）を見直す

ステップ2：クライアント版を確定

mysql --version（またはmysql -V）

ステップ3：接続先（ホスト/ポート/ソケット）を確定

-h（ホスト）、-P（ポート）の指定を確認
ローカル接続でも、ソケット接続とTCP接続で対象が変わることがあります
Dockerの場合は、ホスト名（サービス名）やポートマッピングを再確認

ステップ4：サーバ版を確定

接続後に SELECT VERSION();
追加で SHOW VARIABLES LIKE 'version%'; も併用すると盤石です（権限不要・接続できればOK）

MySQLバージョン確認を詳しく行うコマンド

mysqlのstatusで接続先情報も確認する

SELECT VERSION(); は最短ですが、トラブルシューティングでは「どこに繋がっているか」も同時に見たいことがあります。そんなときは、mysqlクライアント上で status（または \s）を実行すると、接続情報がまとまって表示されます。

この方法が向く場面

どのホストに繋いでいるか曖昧
ソケット接続なのかTCPなのか確認したい
“ローカルのつもりが別環境だった”事故を避けたい

status はSQLではなくmysqlクライアントのコマンドですが、現場ではかなり役に立ちます。バージョン確認を「点」で終わらせず、「接続の文脈」まで押さえたいときに使ってください。

mysqladmin versionでまとめて確認する

より管理寄りの確認がしたい場合は mysqladmin が候補です。MySQL公式ドキュメントでも mysqladmin は「MySQL Server 管理プログラム」として位置づけられています。

代表的な使い方は次のとおりです（接続先に応じて -h などを指定します）。

mysqladmin version：サーバに関する情報をまとめて表示
mysqladmin status：状態を簡潔に表示
mysqladmin variables：変数を表示（SHOW VARIABLES相当の見方ができる）

ポイント

mysqladmin は“サーバに問い合わせる系”なので、接続できることが前提です
本番環境では実行権限・実行場所が制限されることがあります（運用ルールに従ってください）

SHOW VARIABLESでversion系を確認する

SQLで確認したい、かつバージョン関連情報をまとめて見たい場合は、次の形が便利です。

SHOW VARIABLES LIKE 'version%';

公式ドキュメントでは、SHOW VARIABLES は「どの権限も必要ありません。必要なのはサーバーに接続できることのみ」と明記されています。
そのため、最小権限のユーザーでも、接続さえできれば確認できる可能性が高いのが利点です。

よく見る変数の例（環境により表示は変わります）

version：サーバのバージョン
version_comment：ディストリビューション等のコメント
version_compile_os：ビルドOS
version_compile_machine：アーキテクチャ

SELECT VERSION(); と SHOW VARIABLES LIKE 'version%'; を併用すると、問い合わせ先がサーバであることを二重に確認でき、調査メモとしても強くなります。

MySQLバージョン確認で困るときのトラブルシューティング

接続できないときに確認できる範囲

接続できないときは、サーバ側へ問い合わせる方法（SELECT VERSION()、SHOW VARIABLES、mysqladmin）が使えません。そのため、できることを切り分けて考えます。

接続できないときに“確定できる”もの

クライアント（手元のmysqlコマンド）のバージョン
- mysql --version

これは確定できます。まずはこれをメモしてください。障害対応では「クライアントが古い/新しい」だけでも重要な情報になります。

接続できないときに“暫定確認”できるもの（確定ではない）

Docker（Compose含む）なら、MySQLコンテナのイメージタグ
- 例：mysql:8.0、mysql:8.4 など
- ただしタグが曖昧（latest）だったり、独自ビルドだったりすると断定できません
構成管理（IaC、Ansibleなど）や運用資料に記載のバージョン
マネージドDB（RDS等）なら管理画面のエンジンバージョン表示
- ただしフェイルオーバーやブルーグリーン等で実際の接続先が変わる運用では、最終的に“接続して確認”が必要です

どう進めると安全か

まず「接続復旧」自体の原因（ホスト/ポート/認証/ネットワーク）を切り分け
復旧したら SELECT VERSION(); でサーバ版を確定
そのうえで、必要に応じてアップグレードや互換性の議論へ進む

「暫定確認」を“確定情報”として扱うと、修正が二度手間になるので注意してください。

クライアントが古くて認証で失敗する場合

認証でつまずくとき、実は「サーバ側の認証方式」と「クライアント/コネクタ側の対応」が噛み合っていないことがあります。

MySQL 8.0.4 からデフォルト認証が caching_sha2_password に変更
アップグレード関連の公式ドキュメントでも、caching_sha2_password とクライアント側互換性に触れています

典型的な症状

パスワードは合っているはずなのに接続できない
認証プラグインに関するエラーが出る
古いアプリや古いコネクタだけが接続できない

まず確認する順番（最短）

mysql --version でクライアント版を確定
（接続できるなら）SELECT VERSION(); でサーバ版を確定
サーバが8.0系で、クライアントやコネクタが古い場合は「互換性問題」を疑う
以後は運用方針に沿って、クライアント更新・コネクタ更新・認証方式の運用方針を検討

このとき大事なのは、「認証方式を下げる」判断はセキュリティ方針とセットで行うことです。記事では一般論として“切り分け”まで扱い、具体の変更は組織のルールに従ってください。

どのmysqlを叩いているか分からない場合（PATH/複数インストール）

「mysql --version の結果が思ったものと違う」「同じコマンドなのに人によって結果が違う」場合、原因の多くは“別のmysqlを叩いている”ことです。

すぐ効くチェックリスト（取り違え防止）

which mysql / where mysql を実行し、実体パスを確認した
WSLとWindows、Dockerとホストなど、実行している環境（世界）が一致している
PATHの順序（優先順位）が想定どおり
IDEやGUIツールが内蔵クライアントを使っていないか確認した
同僚と比較する場合、同じシェル（PowerShell/WSL/bash）で実行している
mysql のフルパス指定で実行して比較した（必要な場合）

事故を減らすコツ

調査メモには必ず次をセットで残す
- which mysql（実体）
- mysql --version（クライアント版）
- 接続文字列（ホスト/ポート/ソケット）
- SELECT VERSION();（サーバ版）

これだけで、再現性が大きく上がり、相談の往復も減ります。

MySQLバージョン確認のよくある質問

MariaDBでも同じコマンドで良いか

多くの場合、同じコマンドで確認できます。mysql --version や SELECT VERSION(); はMariaDBでも動作することが多いです。ただし表示文字列に「MariaDB」と付く場合があり、MySQLとは別系統の互換性差があることもあります。

運用上は次の方針が安全です。

“MySQLとしての互換性”を議論するなら、まず「MySQLかMariaDBか」を明確にする
バージョン文字列に注釈が付く場合は、そのままメモに残す
互換性問題が疑われるなら、公式ドキュメントまたは採用ディストリビューションの公式情報に当たる

WorkbenchやphpMyAdminなどGUIでも確認できるか

GUIでも確認できます。多くのGUIツールは「サーバ情報」や「接続情報」の画面にバージョンを表示します。ただし、GUIは内部的にどの接続先を見ているかが分かりにくいことがあります。

確実にしたい場合は、GUIのSQL実行画面で次を実行してください。

SELECT VERSION();

これなら「サーバが返した値」であることが明確です。GUIの表示と一致するかも含めて確認できるため、混在環境の事故を減らせます。

バージョン確認だけなら権限は必要か

結論として、接続できるなら権限が要らない確認手段があります。MySQL公式ドキュメントで、SHOW VARIABLES は「どの権限も必要ありません。必要なのはサーバーに接続できることのみ」と明記されています。

そのため、最小権限のユーザーでも「バージョン関連の変数（version%）」を見られる可能性があります。ただし、組織の権限設計や設定によって状況が変わることもあるため、試す際は運用ルールに従ってください。

MySQLバージョン確認の比較表とチェックリスト

状況別に選ぶ：最短で迷わない確認手段（比較表）

いまの状況	推奨する確認手段	分かること	注意点
サーバに接続できる	`SELECT VERSION();`	サーバのバージョン（確定）	接続先を間違えると別サーバを見てしまう
サーバに接続できる（補強）	`SHOW VARIABLES LIKE 'version%';`	サーバのversion関連情報（確定）	接続できることが前提。権限は原則不要
接続できない	`mysql --version`	クライアントのバージョン（確定）	サーバ版は分からない
接続できない（暫定）	Docker/IaC/管理画面で確認	サーバ版の“候補”（暫定）	`latest`運用などは断定不可。復旧後に確定が必要
混在環境で混乱	`which/where mysql` + 上記	叩いている実体＋両者の版	PATH/WSL/Dockerの世界違いに注意

コマンド別：server/client取り違え防止（比較表）

コマンド/方法	対象	必要条件	何が分かる	推奨度
`mysql --version` / `mysql -V`	client	端末で実行できる	mysqlクライアントの版	高
`SELECT VERSION();`	server	サーバに接続できる	接続先サーバの版	最優先
`SHOW VARIABLES LIKE 'version%';`	server	サーバに接続できる	version関連変数（OS等も含む）	高
`status` / `\s`（mysql内）	context	サーバに接続できる	接続先・状態（文脈）	中
`mysqladmin version`	server/context	サーバに接続できる	版・状態情報をまとめて	中（運用制約に注意）
GUI表示（Workbench等）	server（多い）	GUIで接続できる	画面表示の版	中（SQLで裏取り推奨）

混在環境の最終チェックリスト（保存推奨）

which mysql / where mysql で実体を確認した
mysql --version をメモした（クライアント版）
接続コマンドのホスト/ポート/ソケットを見直した
接続後に SELECT VERSION(); を実行した（サーバ版）
必要なら SHOW VARIABLES LIKE 'version%'; も取得した
認証エラー時は「サーバ8.0系×古いクライアント/コネクタ」の可能性を疑った

参考にした情報源

MySQL公式リファレンスマニュアル（8.0/日本語）：https://dev.mysql.com/doc/refman/8.0/ja/
MySQL公式：mysqlクライアントオプション（–version）：https://dev.mysql.com/doc/refman/8.0/ja/mysql-command-options.html
MySQL公式：SHOW VARIABLES ステートメント（権限不要の明記）：https://dev.mysql.com/doc/refman/8.0/ja/show-variables.html
MySQL公式ブログ：MySQL 8.0.4のデフォルト認証変更（caching_sha2_password）：https://dev.mysql.com/blog-archive/mysql-8-0-4-new-default-authentication-plugin-caching_sha2_password/
MySQL公式：アップグレード時の互換性（caching_sha2_passwordとクライアント互換性言及）：https://dev.mysql.com/doc/refman/8.0/ja/upgrading-from-previous-series.html