MySQL/MariaDBは，WordPressをはじめ最も広く使われるDBだ．情報量も多く扱いやすいが，デフォルト設定のまま・文字コードを意識せず運用して後で痛い目を見る個人開発者は少なくない．
とくに文字コードの設定ミスによる文字化けとInnoDBのメモリ設定の放置は，後から直すのが大変な定番の落とし穴だ．最初に正しく押さえておけば，長く安定して使える．
この記事は，VPSでMySQL/MariaDBを運用する個人開発者，WordPressや自作アプリのDBを堅実に運用したいエンジニアに向けている．設定・文字コード・インデックス・レプリケーション・バックアップを実務目線で解説する．
読み終えたとき，あなたは文字化けを防ぎ，メモリを活かし，遅いクエリを直し，バックアップで守るMySQL運用ができるようになっている．
なぜMySQL運用の基礎が重要か
MySQLは導入が簡単すぎるがゆえに，設定を詰めないまま本番投入されがちだ．その結果，アクセスが増えてから「遅い」「詰まる」に直面する．
最も深刻なのが文字コードの問題だ．古いutf8(実は3バイトまで)のまま運用すると，絵文字や一部の文字が保存できず，後からutf8mb4へ移行するのは大仕事になる．
またInnoDBのバッファプールはMySQLの性能を決める最重要設定だが，デフォルトは控えめだ．ここを適切にするだけで，読み書きの体感が大きく変わる．
これらを最初に正しく設定することが，「後で泣かない」DB運用の条件になる．
MySQLかMariaDBか ― 互換性と選択
MariaDBはMySQLから派生した互換DBで，多くの場面でドロップイン代替として使える．コマンドもSQLもほぼ共通だ．Linuxディストリビューションの標準パッケージがMariaDBであることも多い．
個人開発ではどちらを選んでも大きな差はない．使うフレームワークやホスティングの推奨に合わせれば良い．本記事の内容は両者にほぼ共通して適用できる．
InnoDBの主要設定 ― メモリチューニングの核
MySQLの性能を最も左右するのがInnoDBバッファプールだ．これはデータとインデックスをメモリにキャッシュする領域で，ここが十分だとディスクアクセスが減り高速化する．
| パラメータ | 役割 | 目安 |
|---|---|---|
| innodb_buffer_pool_size | InnoDBのキャッシュ領域(最重要) | 搭載メモリの50〜70% |
| innodb_log_file_size | 更新ログのサイズ | 数百MB |
| max_connections | 最大同時接続数 | 実需に合わせ控えめに |
| query_cache | (MySQL8で廃止) | 使わない |
innodb_buffer_pool_sizeは，DB専用に近いVPSなら搭載メモリの50〜70%が目安だ．アプリと同居するなら，アプリ・OSの分を残して調整する．設定は/etc/mysql/配下の設定ファイル(my.cnf等)に書き，再起動で反映する．
文字コード ― 必ずutf8mb4にする
これは最初に必ず押さえるべき最重要事項だ．MySQLの古いutf8は実は3バイトまでしか扱えず，絵文字や一部の文字を保存できない．現代ではutf8mb4(真の4バイトUTF-8)を使う．
utf8mb4をデフォルトにする設定
# my.cnf
[mysqld]
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci
-- DB作成時に明示
CREATE DATABASE myapp CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
-- 既存DBの確認
SHOW VARIABLES LIKE 'character_set%';後からutf8→utf8mb4へ移行するのは，全テーブルの変換が必要で大変だ．DB作成の最初の時点でutf8mb4にしておくことが，将来の自分を救う．接続側(アプリ・ドライバ)の文字コードも揃えるのを忘れずに．
インデックスとEXPLAIN ― クエリを速くする
MySQLでも，遅いクエリの特効薬は適切なインデックスだ．そして効果の確認にはEXPLAINを使う．推測ではなく実行計画で判断する．
インデックスとEXPLAIN
CREATE INDEX idx_email ON users(email);
CREATE INDEX idx_user_created ON posts(user_id, created_at);
-- 実行計画を確認(typeがALL=全件走査は要注意)
EXPLAIN SELECT * FROM posts WHERE user_id = 42 ORDER BY created_at DESC;EXPLAINの出力でtype: ALL(フルテーブルスキャン)が出たら，インデックスが効いていない．適切なインデックスを張るとrefやrangeに変わり高速化する．複合インデックスは「WHEREで使う列＋ORDER BYの列」の順序が効果を左右する点も押さえたい．
レプリケーション入門 ― 読み取り分散と冗長化
アクセスが増えてきたら，レプリケーションを検討する段階になる．これはマスター(書き込み)の内容をレプリカ(読み取り)に複製する仕組みで，読み取りを分散したり，冗長化(バックアップ・フェイルオーバー)に使える．
個人開発の初期には不要なことが多いが，「読み取りが多くて1台では詰まる」「DBが落ちたら困る」段階で価値が出る．概念だけでも知っておくと，スケールの判断が早くなる．
| 役割 | 担当 | 用途 |
|---|---|---|
| マスター(primary) | 書き込みを受ける | 更新系の処理 |
| レプリカ(replica) | マスターの複製を保持 | 読み取り分散・バックアップ・予備 |
レプリケーションは非同期が基本で，レプリカへの反映にわずかな遅延がある点に注意する(直後に読むと古い値が返ることがある)．まずは1台で運用し，読み取り負荷が問題になってから導入するのが現実的だ．設定はserver-idとバイナリログ，レプリカ側の接続設定が要点になる．
バックアップ ― mysqldumpを確実に
MySQLのバックアップの基本はmysqldumpだ．定期的にダンプを取り，外部に保管し，リストアできることを確認する．
mysqldumpによるバックアップとリストア
# バックアップ(単一DB)
mysqldump -u root -p --single-transaction myapp | gzip > /backup/myapp-$(date +%F).sql.gz
# 全DB
mysqldump -u root -p --all-databases | gzip > /backup/all.sql.gz
# リストア
gunzip -c /backup/myapp-2026-07-10.sql.gz | mysql -u root -p myapp--single-transactionは，InnoDBでテーブルをロックせずに一貫したバックアップを取るための重要オプションだ．これがないと，バックアップ中の書き込みで不整合が起きうる．大規模になれば物理バックアップツールも選択肢だが，個人開発はmysqldump＋外部保管＋リストア検証で十分なことが多い．
補論：MySQL運用は「メモリの余裕」と「巻き戻し」で安定する
MySQLの性能はバッファプールに依存し，それはメモリの余裕に支えられる．そして文字コード変更やバージョンアップ，my.cnfの調整は，失敗するとデータや稼働に影響する重い作業だ．「戻せる」環境が安心して運用するための前提になる．
高速NVMe・50種類以上のOSテンプレートに対応した国内VPS─シン・VPS─ はNVMe SSDでDBの読み書きが速く，メモリをスケールアップで増やせるため，バッファプールに余裕を持たせた運用がしやすい．スナップショットを取ってから設定変更やアップグレードを行えば，問題があっても即座に巻き戻せる．
WordPressや自作アプリを独自ドメインで公開するなら，取り扱い400種類以上のドメイン取得サービス─ムームードメイン─ でドメインを取得しよう．DBは外部公開せずアプリからのlocalhost接続にし，HTTPSで守られた構成にするのが基本だ．
よくある質問(FAQ)
Q1．MySQLとMariaDBどちらを選ぶべき？
個人開発では大きな差はない．コマンドもSQLもほぼ共通で，多くの場面でMariaDBはMySQLの代替として使える．フレームワークやホスティングの推奨，標準パッケージに合わせれば良い．
Q2．文字コードはなぜutf8ではダメ？
MySQLのutf8は実は3バイトまでで，絵文字や一部の文字を保存できない．必ずutf8mb4を使う．後から移行するのは大変なので，DB作成時に設定するのが鉄則だ．
Q3．最重要のチューニング項目は？
innodb_buffer_pool_sizeだ．データとインデックスをメモリにキャッシュする領域で，DB専用に近い用途なら搭載メモリの50〜70%が目安．これだけで読み書きの体感が変わる．
Q4．レプリケーションは個人開発でも必要？
初期は不要なことが多い．読み取り負荷が1台で捌けなくなる，またはDB障害に備えたい段階で導入を検討する．非同期レプリケーションには反映遅延がある点に注意．
Q5．バックアップで気をつけることは？
mysqldump --single-transactionでロックせず一貫したバックアップを取る．外部に保管し，必ず一度リストアを試す．「取れているが戻せない」が最悪のパターンだ．
Q6．WordPressのDBが重い
インデックスの確認・不要なデータ(リビジョン/トランジェント)の整理・バッファプールの調整が効く．加えてNginx側のキャッシュ(別記事参照)でDBアクセス自体を減らすと劇的に軽くなる．
まとめ ― 最初の設定が長期の安定を決める
MySQL/MariaDB運用の要点は，utf8mb4・InnoDBバッファプール・インデックス・バックアップだ．特に文字コードとメモリ設定は，最初に正しくしておくことが将来の自分を救う．
今日やるべきことは，自分のDBがutf8mb4か確認し，innodb_buffer_pool_sizeをVPSのメモリに合わせて見直すこと．この2つだけで，文字化けと性能の両方の不安が消える．
DBはサービスの土台だ．メモリに余裕があり，スナップショットで戻せるVPSがあれば，設定もアップグレードも安心して行える．