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

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

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

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

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

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

>>>Amazonのお得な最新の情報はここ

サーバー管理者歴17年の筆者が選んだレンタルサーバーはここ

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

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

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

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

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

MySQL 5.6 のリスク一覧（セキュリティ／互換性）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

STEP1：旧DBをエクスポート

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

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

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

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

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

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

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

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

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

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

解決方法はシンプルです。
.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形式）

対応エディターの一例：

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

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

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

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

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

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

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

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

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

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

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

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

新しいデータベースへのインポートが完了したら、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クライアントを使って作業してみてください。

あわせて読みたい

FileZillaの使い方ガイド｜FTPクライアントの設定と活用法 FileZillaの使い方ガイド｜FTPクライアントの設定と活用法

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

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

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

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

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

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

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

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

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

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

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

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

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

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

よくある質問（FAQ）