通常はMySQLで動かすWordPressを、実はSQLiteで動かす方法があります。その方法とメリットについて書いています。

SQLite について

単独ファイルとして使えるデータベース

データベースは通常、サーバーに接続して扱うことができますが、SQLiteは、Microsoft Office の Access のように、ローカルで単独ファイルとして扱うことのできる形態をしたデータベースです。

SQLiteは貧弱か？

SQLiteは「軽量」であるイメージから、使っていない人からは貧弱だと思われがちですが、大量のクエリに耐えることができ、高速であるという評価が高いデータベースです。

ただ、WordPressで使う場合、複数のユーザーが同時に更新するようなことが生じた際に、壊れる危険性があるとのことです。

SQLiteを使うメリット

SQLiteを使う最大のメリットは、単独ファイルとして扱えることから、バックアップやバージョン管理が気軽にできることだと思います。

XAMPPなどテスト環境で使うには、とても使い勝手が良いです。

単独ファイルなので、サーバー間の「引っ越し」も楽にできます。

WordPressで使う上では、通常MySQL付きのレンタルサーバーは、若干値段が高いため、代わりにSQLiteを使うことで、ランニングコストを抑えられることもメリットです。

DB Browser for SQLite について

sqlitebrowser.org
sqlitebrowser.org

僕はWordPressを介さず、SQLiteを直接、GUI管理ツールで編集してしまうこともあります。

当然リスクは高い行為なのですが、おかげでだいぶWordPressのデータベースの構造が分かってきました。

GUI管理ツールは “DB Browser for SQLite” が最もポピュラーで、オススメです。

SQLite Integration について

SQLite Integration 公式ダウンロードページ
SQLite Integration 公式ダウンロードページ

WordPressでSQLiteを使うためのプラグインですが、一部の設定の保存ができなくなるというバグが発生したせいか、2019年6月にいよいよ公式ダウンロードページもクローズされました。

ですので、この記事を読んでも、実際にWordPressをSQLiteで運用することには、高いリスクがあります。

しかしながら僕自身は、未だに本番環境でも一部使っており、問題が発生したことはありません。

ただ、読者の方はあくまでも、テスト環境での運用に留め、全て自己責任でお願いを申し上げます。

SQLite Integration の使い方

公式ダウンロードページはクローズしていますが、以下のGithubからまだダウンロードができます。

https://github.com/jumpstarter-io/wp-sqlite-integration

.zipをダウンロードし、中身を、”wp-content” 内の “plugins” に移動します（.zipは中身を移動すれば自動的に解凍されます）。

そしてディレクトリ内の “db.php” のコピーを取り、”wp-content” 内にペーストします。

これでWordPressを開くと、「ようこそ」の画面が出てきて、”wp-content” 内に “database” というディレクトリができるので、そこにsqliteが設置されます。

“db.php” によって、データベースに接続するプログラムがオーバーライドされるようなので、”wp-config”は特に変更を加えなくてOKです。

このプラグインは、管理画面から「有効化」しなくても、以上の操作を済ませておけば、勝手に働きます。

SQLite Integration の使い方は以上でした。

SQLiteからMySQLへ「引っ越し」する方法

XAMPPなどを使ってテスト環境を構築した場合、いざ本番環境のMySQLにデータを移すためには、一度SQLiteの中身をSQL文にエクスポートし、それに少し手を加えてから、本番環境の “phpMyAdmin” でSQL文のインポートを行います。

wp_optionsの不要な項目を削除し、SQL文へエクスポートする

データベース内の “wp_options” というテーブルは、WordPressの全般的な設定や、ログイン・ログアウトの記録などを格納しています。

ここで、おそらくログイン時に追加されるレコードなのですが、BLOB形式のデータが含まれている場合があり、後の “phpMyAdmin” でSQL文をインポートするときに、エラーが生じます。

なのでそのようなレコードは、”DB Browser for SQLite” を使って削除し、SQL文へエクスポートしましょう。

“wp_options” 内のレコードは、 “autoload” というフィールドが “no” のレコードなら、全て削除してしまっても問題ありません（おそらく）。

SQL文内のパスを書き換える

SQLiteからエクスポートしたSQL文を、VSCodeのようなエディタで開き、パスを一括変換しましょう。

“localhost/○○○○” を “○○○○.com” などに変えるわけです。

テーブル構造が出来ている状態でインポートを行う

SQLiteからMySQLへデータを移行する場合、本番環境（サーバー環境）で一度WordPressからMySQLに接続しておき、 “phpMyAdmin” に全てのテーブル構造が出来ている状態にしておいてください。

つまりあらかじめデータベースは用意しておき、”wp-config” に接続のための情報を設定して、”db.php”を削除してしまえばOKです。

データベース内は構造だけ残っている状態で、テーブルの中身は空にしておきます。

そして、SQLiteからエクスポートは「データのみ」を選択し、SQL文はレコードを追加する文だけを残します。

このSQL文を “phpMyAdmin” でインポートすれば、SQLiteからMySQLへの引っ越しは完了です。

ユーザーデータのバックアップ

WordPressは1万を越えるファイルで構成されているため、重くて何かと扱い辛いものです。

WordPressの中身は、3つのディレクトリに分けられています。

  • “wp-admin”: 管理画面を構成するプログラム
  • “wp-content”: 翻訳、テーマ、プラグイン、メディアなど、実際のコンテンツ
  • “wp-includes”: APIとなる主要な関数を定義

このうちユーザーのデータは”wp-content”だけなので、ここだけバックアップを取るようにすれば、少しは扱い易くなります。

僕はGitで”wp-content”の差分だけを毎月コミットすることで、バックアップにしています。

データベースもSQLiteを使うことで単なるファイルとして扱えるため、この方法によってWordPressのユーザーデータを、ほぼ完璧にバージョン管理できる訳です。

WordPressでSQLiteが使えなくなる日は来るのか？

まぁ、いつか来るのでしょうね。東京に大震災がやって来る日が確実に予測されているのに似ています。

ただ予測として、WordPressがデータベースにアクセスする部分のプログラムは、ほぼ確立している（と思う）ので、今後さほど変更されないかも知れません。

いずれにしても動きの激しい業界ですから、10年、20年先はWordPress自体どうなっているのか分からないし、自分が同じサイトを運営し続けているかどうかも疑問です。

仮にwebサイトがWordPressのアップデートによって崩れても、一時的に読者に迷惑かけるかも知れませんが、そのときMySQLに移行すれば改善する問題ですし、そういう意味ではアクセスがさほど集中しないサイトなら、リスクと捉えなくても良い気がします。

そんな訳で、僕自身はバックアップが楽という理由を優先して、まだSQLiteを使い続けます。

この記事の内容が、何かの役に立てば幸いです。