Menu/Prof
スズキマコト
自由人
元々は楽器屋のギター兄ちゃん。
趣味でプログラミングしてるうちに
本職になってしまった人。

過去に喋っていた言語
c pascal Assembler
perl PHP Python Ruby など
javascriptなどは都度必要に応じて。
最近Mac買ったのでswift勉強してます。

体ぶっ壊して死にかけたので人生RESET中。

MySQL 8.0化せよ?ロリポップ民の実録引っ越し記

Some visuals are licensed via Canva Pro (includes commercial rights).
Usage complies with Canva’s license terms at the time of use.
License policy: canva.com/policies/content-license-agreement

X
     この記事はプロモーションを含みます

WordPressを長年使っていると、「わかってたけど放置してた項目」に、いずれ追いつかれる瞬間がきます。
MySQLバージョンの警告も、まさにそれでした。

「SQLサーバーが古い」と言われても、動いていればつい後回しにしてしまう。
でも、ある日WordPressがハッキリと「MySQL 8.0を推奨」と宣言したことで、いよいよ逃げ場がなくなりました。

しかも使っているのはロリポップの共用サーバー。
root権限は当然なし、「自力でMySQLアップグレード」なんて夢のまた夢…。

――と思っていたら、それは単に「共用サーバーのDB構造をちゃんと理解していなかった」だけの話だったのです。
実は、引っ越しという形でなら、共用サーバーでもMySQL 8.0へ移行できる方法はちゃんと用意されていました。

この記事では、実際にロリポップ環境で試した「MySQL 5.6→8.0への引っ越し手順」を、トラブル込みで実録形式で紹介していきます。
同じように悩んでいる人にとって、ひとつの「安心材料」になればうれしいです。

contents

はじめに:MySQLバージョン警告は以前から気づいていた

WordPressサイトヘルスで表示された「SQLサーバーのバージョンが古い」という警告画面。

正直に言えば、あの警告にはずっと気づいていました。
なんとなくWordPressの「サイトヘルス」を時々確認するのですが、そのたびに「SQLサーバーのバージョンが古い」と出ていたんです。

とはいえ、サイトは普通に動いていたし、「共用サーバーである以上、MySQLのアップグレードはこちらからは操作できないだろう」と思い込んでいた部分もありました。
FreeBSDで長年サーバーを扱ってきたからこそ、「このへんの仕組みは管理者が勝手にやるもの」という常識が染みついてたのかもしれません。

ところが、ある日ついに「WordPressはMySQL 8.0以上を推奨します」という明確な宣言が出たことで、状況が一変。
「ああ、いよいよやるべき日が来たか」と思ったのが、今回の行動のきっかけでした。

そのあと調べていくうちに、「引っ越しという選択肢がある」ことを知り、流れが一気に変わったのです。

MySQL 5.6 のリスク一覧(セキュリティ/互換性)

MySQL 5.6と8.0の違いを表形式で比較した一覧。サポート終了やセキュリティ面の違いが視覚的に整理されている。
じぴ子ちゃん

以下は、MySQL 5.6と8.0の主な違い・リスクポイントを対比で整理した表です。

比較項目MySQL 5.6MySQL 8.0
サポート状況既にサポート終了(2021年2月)現行のLTSバージョン、継続サポート中
セキュリティ脆弱性への対応新しい脆弱性へのパッチ提供なし定期的にセキュリティアップデートあり
PHPとの互換性一部の新しいPHPバージョンで非推奨PHP 8以降とも高い互換性
utf8mb4対応部分対応。照合順序が古いutf8mb4_0900系で正確なUnicode対応
JSONサポートなし(CASTでの無理やり処理)JSON型が標準サポート、関数も豊富
実行計画(EXPLAIN)表示形式が簡易、最適化しにくい詳細な分析が可能、パフォーマンスチューニング向き

MySQL 5.6を使い続ける最大のリスクは、セキュリティパッチが提供されないことです。
仮に脆弱性が発見されたとしても、既にOracleのサポートが終了しているため、対応はユーザー側に委ねられてしまいます。

また、PHPやWordPressのアップデートに伴って「予期しない非互換エラー」が出る可能性も高まります。
将来的に「特に何もしていないのに急にエラーになった」というケースの原因が、実はMySQL 5.6だったという可能性も十分に考えられます。

8.0では、照合順序やJSON型の正式対応、EXPLAINの進化など、現代的なWebアプリに適した機能が数多く追加されています。
古い環境にしがみつくより、早めに移行した方が結果的にラクになる、というのが筆者の実感です。

サイトヘルスの警告表示と“気になる違和感”

WordPressのサイトヘルス画面に表示された、データベースバージョンに関する注意表示。

WordPress 5.2以降、管理画面に「サイトヘルス」機能が追加されてから、ちょくちょく見るようになったこの画面。
そこにたまに出る「データベースサーバーのバージョンが古いようです」という表示、見覚えのある人も多いのではないでしょうか。

この警告は赤文字でもなく、装飾も特にされていないため、パッと見では「深刻さ」が伝わりづらいんです。
そのせいで、「まあいっか」とスルーしてしまう人も少なくありません。筆者もそのひとりでした。

実際、MySQL 5.6のままでも大きなエラーに遭遇したわけではありません。
現状は安定して稼働していたし、目立った不具合もなかった。

でも、サポート終了によるセキュリティの不安や、今後のPHP・WordPressとの互換性を考えると、
「使えてるからこのままでいい」とは言い切れない、そんな潜在的なリスクを抱えている状態ではありました。

「今すぐ壊れるわけじゃないけど、未来のどこかで確実に詰む可能性がある」
そう感じたときが、動くタイミングだったのだと思います。

結論:共用サーバーでもMySQL 8.0に引っ越しできる

ロリポップの管理画面で確認できるMySQLバージョンの設定項目。共用サーバーでも8.0対応DBが選択可能なことを示す。

「共用サーバー=古い環境で我慢するしかない」
そんな思い込みがずっとありました。

root権限なんて当然ないし、MySQLのバージョンを自分で切り替えられるわけもない。
だから、バージョンアップの話題を見るたびに「どうせVPSとか専用サーバーの話でしょ」とスルーしてたんです。

でも実は、ロリポップのハイスピードプランなどでは、新しく作ったデータベースが最初からMySQL 8.0対応になっているのです。
つまり、既存DBをそのままアップグレードすることはできなくても、
「新規に作成 → 引っ越し → 接続先を切り替え」という手順を踏めば、共用サーバーでも十分に移行が可能なんです。

必要なのは、root権限ではなく、仕組みの理解とちょっとの手間だけ。
「制限されている」のではなく、正しく使えばちゃんと手段が用意されている——これが、今回の引っ越しで得た一番大きな気づきでした。

STEP1:旧DBをエクスポート

phpMyAdminのエクスポート画面。MySQL 5.6のデータベースをSQL形式で保存する手順を示す。

まずは、既存のMySQL 5.6データベースをエクスポートして、.sqlファイルとして保存します。
ロリポップではphpMyAdminが使えるので、そこからエクスポートするのが基本です。

ログイン後、左側のDB名を選択して「エクスポート」タブを開きます。
形式は「SQL」を選び、オプションは基本的にデフォルトで問題ありません。

ただし、ひとつだけ要注意ポイントがあります。
そのままエクスポートすると、CREATE DATABASEUSE文が自動的に含まれてしまうケースがあるのです。

この状態のまま、後で新しいDBにインポートしようとすると、次のようなエラーが出ます:

エラー:データベース ‘○○○’ を作成できません。アクセス権限がありません。

共用サーバーでは「DBの作成」は事前に管理画面でしかできないため、
インポート時にSQLファイル内でそれを再実行しようとすると必ずエラーになります

この後のSTEP2で修正方法を紹介しますが、まずはその点を意識して、
「エクスポートは取得して終わりじゃない」ことを押さえておきましょう。

STEP2:SQLファイルを修正する

エクスポートしたSQLファイルをテキストエディターで開いて編集する様子。CREATE文やUSE文の削除が必要。

エクスポートした.sqlファイルは、そのままではインポートに失敗する可能性があります。
特に注意が必要なのが、ファイルの冒頭に含まれている CREATE DATABASEUSEです。

これらはロリポップの共用サーバーでは権限外の操作に該当するため、
そのままインポートすると「アクセス権限がありません」系のエラーになります。

解決方法はシンプルです。
.sqlファイルをテキストエディターで開いて、次のような行を削除します:

CREATE DATABASE IF NOT EXISTS `old_db_name` /*!40100 DEFAULT CHARACTER SET utf8mb4 */;
USE `old_db_name`;

冒頭2~30行にこれらが含まれていないか、確認して削除しましょう。

文字コード・改行コードにも注意

特にWindowsユーザーの場合、メモ帳などで不用意に開くと文字化けや改行崩れの原因になります。
推奨される設定は以下の通りです:

  • 文字コード:UTF-8(BOMなし)
  • 改行コード:LF(Unix形式)
BOM(Byte Order Mark)とは?

BOMとは、文字コードの先頭に付加される特殊な目印のことです。
Windows環境ではBOM付きUTF-8が使われることがありますが、MySQLのインポートではBOMなしのUTF-8が推奨されます。

対応エディターの一例:

  • VS Code(Visual Studio Code)
  • Sublime Text
  • Atom
  • 秀丸エディタ(設定変更で対応可)
  • Notepad++(要設定)

次のSTEPでは、この修正済SQLファイルを新しいMySQL 8.0環境にインポートします。
「ちゃんと修正できたか?」が、インポート成功のカギになります。

STEP3:新しいMySQL 8.0 DBにインポート

phpMyAdminで新しいMySQL 8.0データベースを選択し、インポート処理を実行している画面。

修正が済んだ.sqlファイルを、いよいよ新しいMySQL 8.0データベースにインポートします。
これもphpMyAdminから操作できますが、ひとつだけよくある落とし穴があります。

それは、「左のメニューからデータベースを選択しないままインポートしてしまう」という操作ミスです。

この状態でSQLファイルを読み込むと、次のようなエラーになります:

エラー:データベースが選択されていません

これは構文や権限の問題ではなく、単なる操作上のミス。
焦る必要はありません。手順を確認してやり直せばOKです。

正しいインポート手順の確認

  • phpMyAdminにログインする
  • 左側のデータベース名(新しく作った8.0のDB)を必ずクリックして選択
  • 上部メニューから「インポート」タブを開く
  • .sqlファイルを選んで「実行」

この手順通りに行えば、「データベースが選択されていません」系のエラーは発生しません。
もし出た場合は、まず「DBを選び忘れてないか?」を確認しましょう。

STEP4:wp-config.phpを新しいDBに書き換える

FTPクライアント上でwp-config.phpを開いて編集している様子。データベース接続情報の書き換え手順を示す。

新しいデータベースへのインポートが完了したら、WordPressがそれを参照できるようにする必要があります。
そのために編集するのが、サイト直下にある設定ファイルwp-config.phpです。

書き換えるのは、主に次の4項目です:

define( 'DB_NAME', '新しいデータベース名' );
define( 'DB_USER', '新しいユーザー名' );
define( 'DB_PASSWORD', '新しいパスワード' );
define( 'DB_HOST', 'ホスト名' );

ホスト名の見落としに注意!

ここで最も見落とされがちなのが「ホスト名」です。
多くのサーバーでは localhost が一般的ですが、ロリポップではプランごとに異なるホスト名が指定されていることがあります。

これは、管理画面の「データベース情報」などから確認可能です。
うっかり localhost のままにしていると、接続エラーで真っ白な画面になることもあるので要注意です。

FTPクライアントで作業するのが本来のスタイル

ロリポップでは「WEB FTP」でも wp-config.php の編集は可能です。
ただし、今後のメンテナンスやバックアップのことを考えると、FTPクライアントを使ってファイルを一度ローカルにダウンロードし、編集後にアップロードするのが正攻法です。

ちょっと面倒に感じるかもしれませんが、ファイル操作の基本を体験できる良い機会なので、ぜひFTPクライアントを使って作業してみてください。

編集が済んだらファイルを上書き保存し、ブラウザでサイトを再読み込み。
うまくいっていれば、新しいデーターベースで今まで通りページが表示されるはずです。

STEP5:サイトヘルスを確認 → 大成功

MySQLバージョン警告が消えたWordPressサイトヘルス画面。移行成功を示す証拠として表示。

wp-config.phpの書き換えが済んだら、いよいよ動作確認です。
ブラウザで自分のWordPressサイトを開いて、普段通りに表示されていればまず成功

次に、「ツール」→「サイトヘルス」をチェックしてみましょう。
あの見慣れた(でも気が重かった)警告文、

データベースサーバーのバージョンが古いようです

きれいに消えていれば、完全勝利です。

もちろん、やっていること自体は地味な引っ越し作業かもしれません。
でも、セキュリティと互換性の面から見れば、今後のトラブルを未然に防ぐ意味で非常に効果的な一手です。

「MySQLバージョンの警告、放置してたけどそろそろ動こうかな…」
そんな気持ちを後押しできたなら、この記録も少しは役に立てたかもしれません。

まとめ:共用サーバーでも“理解すれば”対応できる

WordPress管理画面の安定稼働状態。MySQL 8.0環境へ移行した後の安心感を象徴するイメージ。

将来的に必ずトラブルの原因になりうる旧バージョンを使い続けることの潜在的なリスクを、いま摘み取っておく。
この作業の最大の意義は、まさにそこにあります。

今回ご紹介した手順は、特別な裏技や高度なテクニックではありません。
すべて、共用サーバーでも正しく用意されている機能と仕組みを、正しく理解して、順番通りに実行しただけです。

MySQL 5.6のままでも動くには動くけれど、
サポート切れ・非推奨構文・互換性の壁といった“目に見えにくいリスク”を、今のうちにひとつずつ減らしておく。
その価値は十分にあると、実際に移行してみて強く感じました。

「共用サーバーだから何もできない」と思っていたあの頃の自分に、
「大丈夫、引っ越しという手があるよ」と教えてあげたくなる、そんな体験でした。

この記録が、同じように迷っている方の参考になれば幸いです。

よくある質問(FAQ)

ロリポップの共用サーバーでもMySQL 8.0は使えますか?

はい、ハイスピードプランなど一部プランでは新規に作成するデータベースがMySQL 8.0に対応しています。
既存DBの直接アップグレードはできませんが、新規DBに引っ越す形で移行可能です。

MySQLのバージョン警告は必ず対応すべきですか?

放置していてもすぐにエラーにはなりませんが、将来的な互換性やセキュリティリスクの観点から早めの対応が推奨されます。

phpMyAdminでエクスポートしたSQLに含まれるCREATE DATABASE文は削除すべき?

はい。共用サーバーではユーザーがDBを作成できないため、CREATE DATABASEUSE文を残したままだとインポート時にエラーになります。

SQLファイルの文字コードはどうすればいい?

UTF-8(BOMなし)で保存する必要があります。
BOMが含まれるとMySQLが解釈エラーを起こす可能性があります。

wp-config.phpの編集はWEB FTPでも大丈夫ですか?

可能ですが、誤操作を避けるためにはFTPクライアントを使用し、ローカルで編集・再アップロードする方法を推奨します。

wp-config.phpのホスト名はlocalhostでいい?

ロリポップではプランによって専用ホスト名が指定されていることがあります。
必ず管理画面の「データベース情報」で確認してください。

インポート時に「データベースが選択されていません」と出る原因は?

phpMyAdminで左側のDBを選択せずにインポートした場合に発生します。
対象のDBをクリックしてから「インポート」タブを開いてください。

MySQL 5.6をこのまま使い続けてもいい?

当面の動作に問題がない場合もありますが、サポート終了により将来的な脆弱性や非互換のリスクが高まります。
早めの移行をおすすめします。

テキストエディターは何を使えばいい?

windowsな方は VS Code、Sublime Text、Atom、Notepad++など、UTF-8(BOMなし)保存と改行コード変更が可能なエディターを推奨します。Macな方はCotEditorとかおすすめ。ちな私の場合はサーバーにsshでログインしてviで直接編集ってのが1番早いんですけどね笑

作業前にバックアップは必要ですか?

はい、SQLファイルの編集やwp-config.phpの書き換えを伴うため、旧DBのエクスポートと設定ファイルのバックアップを事前に取っておくことをおすすめします。

シェアしてくれると喜びます
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

makotoのアバター makoto Blogger&YouTuber

サーバー管理者として17年ほど仕事でサーバー触ってました。
www,mail,dns,sql各鯖をすべてFreeBSDで運用してましたが現世ではかなりレアなタイプになるみたいですね笑

viやシェルスクリプトとかperlとかgccとかFreeBSDとか実はbashよりtcshが好きとか時々寝ぼけるのは
その名残でしょう。

今まで縁の下の力持ち的な他人のためにプログラムを書き他人のためにサーバー構築し他人のためにWEBサイトを創る的な世界から
自分の好きなことに集中できる環境は実に気持ち良いですね。
現役は引退済みなので難しいことはやりませんしやれません。

現在 ほぼ自由人。

contents