MySQL無制限レンタルサーバーおすすめ比較｜上限の正体と失敗しない選び方

「MySQL無制限」と書かれているレンタルサーバーを探していると、こんな疑問や不安が湧いてきませんか？

「“無制限”って本当に上限ゼロ？あとから制限されない？」
「DBの作成数が多いのは魅力だけど、容量や負荷は大丈夫？」
「バックアップがあると言われても、DBだけ復元できるのか不安…」
「WordPressを複数サイト運営する予定。検証用も含めるとDBが増えそう」
「安いプランにしたいけど、トラブル時の対応やサポートで後悔したくない」

実は、レンタルサーバーの「MySQL無制限」は、“何が無制限なのか”がサービスによって違うのがややこしいポイントです。
多くの場合、無制限になりやすいのは DB作成数やテーブル数で、実運用で先に壁になるのは 1DB容量・総ストレージ・inode（ファイル数）・負荷制限（同時接続やクエリ）だったりします。

さらに厄介なのが、DBは「消したら戻る」と思いがちですが、実際は 削除＝即消失になりやすいこと。
だからこそ、比較では「無制限の言葉」だけでなく、復元のしやすさ（バックアップ頻度・保存期間・復元単位）まで含めて見ないと、後悔の原因になります。

この記事では、初心者でも判断できるように

• 「MySQL無制限」の上限の正体（どこで詰まる？）
• 失敗しないための比較軸（DB数・容量・復元・安定性）
• 用途別（WordPress／複数サイト／法人運用）の選び方の最短ルート

を、できるだけ噛み砕いて解説します。
読み終えるころには、「結局どれを選べばいいか」だけでなく、契約前に見るべきページ（仕様・規約・免責）まで含めて、自分で判断できる状態を目指します。

おすすめ比較のセクションへはこちらからジャンプできます。

まず理解する：MySQLとデータベースの基本

データベースは何を保存する仕組み？

データベース（DB）は、“あとから探して・並べ替えて・更新しやすい形”で情報を保存する仕組みです。
単なるファイル保存（例：メモ帳、CSV）と違い、大量のデータを素早く扱うための工夫が詰まっています。

たとえばWebサイトでは、ページの見た目（HTML/CSS）とは別に、裏側でこんな情報をDBに保存します。

• 👤 ユーザー情報（ID、メール、権限、ログイン履歴 など）
• 📝 記事データ（タイトル、本文、公開日、カテゴリ、タグ）
• 💬 コメント（投稿者、本文、承認状態）
• 🛒 注文情報（購入者、注文内容、決済状況、配送状況）
• ⚙️ 設定情報（サイト名、テーマ設定、プラグイン設定）

ポイントは「検索や更新が前提」ということ。
「特定ユーザーの注文履歴だけを抽出」「最新の10件を表示」「在庫が0のものを一覧」など、条件を付けて高速に取り出せます。

データベースの中身は“表（テーブル）”で考えるとわかりやすい

多くのDBは、Excelの表に似た テーブル でデータを管理します。

用語	イメージ	例
テーブル	シート（表）	users / posts / orders
行（レコード）	1件のデータ	1人のユーザー情報
列（カラム）	項目	email / created_at
インデックス	目次	「メールで素早く探す」

さらに、DBは次のような“実務上の便利機能”も持っています。

• 同時アクセスに強い（複数人が同時に操作しても整合性を保つ）
• 壊れにくい設計（途中で落ちても復旧しやすい仕組み）
• 権限管理ができる（見せていい人・ダメな人を制御）
• バックアップや復元がしやすい（運用に重要）

MySQLとMariaDBの違い（互換性・向き不向き）

結論から言うと、初心者がレンタルサーバーで使う範囲では
MySQLとMariaDBは「ほぼ同じ感覚で扱える」ことが多いです。

なぜなら、MariaDBはもともとMySQLから派生した（フォークした）DBで、MySQL互換として作られてきた背景があるからです。
そのため、レンタルサーバーでは「MySQLが使える」と書かれていても、実体がMariaDBなことも珍しくありません。

ざっくり比較（初心者向け）

• MySQL
  • “MySQL本家”としての安心感がある
  • 大規模サービスでも広く利用され、情報量が多い
• MariaDB
  • MySQL互換として採用されることが多い
  • レンタルサーバー側の標準DBになっているケースもある

“違い”が問題になるのはどんなとき？

普段のWordPress運用程度なら大きな差が出にくい一方で、次のようなケースでは差が出ることがあります。

• DBのバージョン差が大きい
  • 使いたい機能が「そのバージョンでは未対応」なことがある
• 特定の機能に依存している
  • 例：JSONの扱い、レプリケーション、ストレージエンジン、細かいSQL仕様 など
• 移行（引っ越し）を頻繁にする
  • 旧環境→新環境で挙動が微妙に変わることがある

初心者が迷ったら、まずはここだけ押さえると十分です。

• ✅ 「MySQL or MariaDB」よりも、バージョンとバックアップのほうが重要になりやすい
• ✅ WordPress用途なら、一般に MySQL互換DB（MariaDB含む）で問題ないことが多い
• ✅ ただし、特殊なアプリや開発用途は 要件（機能・バージョン）を先に確認する

どんなサイトで差が出る？（WordPress／会員制／EC／開発環境）

「MySQL無制限」を気にする人は、多くの場合 “DBの数・容量・負荷”が増えやすい運用を想定しています。
ここでは、サイトタイプ別に“DBに何が起きるか”をイメージできるように整理します。

WordPressサイトでのDB負荷の特徴

WordPressは、記事本文だけでなく、設定や関連データもDBにどんどん溜まります。

• 記事・固定ページ・下書き・リビジョン
• コメント
• ユーザー
• プラグインが作る追加テーブル
• オプション（設定値）やログ系データ

特に影響が出やすいのは次のパターンです。

• プラグインを増やしすぎてテーブルやデータが肥大化
• アクセス増で同時にDBへ問い合わせが集中
• リビジョンやログが蓄積してDBが太る

👉 つまりWordPressは「最初は軽いが、運用で太りやすい」タイプです。

会員制サイト（ログイン・権限・課金）がある場合

会員制になると、DBが扱う情報の種類が増え、更新頻度も上がります。

• ユーザーの状態（有効/退会/権限）
• 会員ランク、契約状況、決済履歴
• ログイン履歴、セッション関連
• メール配信やポイントなどの履歴

このタイプは、“ユーザーごとに読み書きが発生する”ため、
アクセス増＝DB負荷増に直結しやすいです。

ECサイト（ネットショップ）でのDB負荷の特徴

ECは、DBにとって「間違えると困るデータ（取引）」を扱う代表です。

• 注文、決済、在庫、配送ステータス
• クーポン、価格、カート状態
• 返品・キャンセル履歴

ECは特に、安定性とバックアップが重要になります。
“無制限”という言葉よりも、

• 障害時に戻せるか
• 負荷が上がったときに耐えられるか

が結果的に重要になりがちです。

開発環境・検証環境（ステージング）がある場合

開発・検証を回す人は、DBを複数作ったり、複製したりすることが多いです。

• 本番DBのコピーでテストしたい
• サイトごとにDBを分けたい
• ステージング／本番で分離したい

この場合は「無制限」が効きやすい一方で、次の点に注意が必要です。

• 同じデータを複製すると容量が一気に増える
• バックアップ対象も増える
• 整理しないと“不要DBの放置”が起きやすい

「MySQL無制限」の意味を分解する（勘違いしやすい点）

「MySQL無制限」と書かれていると、容量も性能も上限なしに見えがちです。
でも実際は、レンタルサーバーの“無制限”は 特定の項目だけを指すことが多く、別のところに上限が隠れています。

ここでは初心者がつまずきやすいポイントを、誤解が起きる順に整理します。

“無制限”と書かれやすい項目（作成数・テーブル数など）

レンタルサーバーで「無制限」と表現されやすいのは、主に次のような“数”の項目です。

• データベース作成数（DBの個数）
• テーブル数
• レコード数（行数）
• ユーザー数（DBユーザーの発行数）

ただし、ここで大事なのは次の点です。

• “無制限”＝制限が完全にゼロとは限らない
• 実際には「常識的な範囲で」という前提（フェアユース）が付くことがある
• 「無制限」と言いながら、別ページや約款に “目安”や“制限条件” があることもある

初心者がやりがちな誤解
「DBをいくらでも作れる」＝「いくらでもデータを入れられる」
→ これは 別物 です。次の見出しが重要になります。

実際に上限が出やすい項目（1DB容量／総ストレージ／inode等）

“無制限”の宣伝文句と衝突しやすいのが、次の「現実的な上限」です。

1つのDBに対する上限（1DB容量）

サーバーによっては、DB 1個あたりの容量上限が設定されていることがあります。

• 例：1DBあたり◯GBまで
• 例：プランごとに上限が違う

WordPressでも、画像は基本ファイルに保存されますが、運用が長いとDBは増えます。

• リビジョン（履歴）
• プラグインが作るログ・キャッシュ
• 予約投稿・自動下書き
• ECや会員系なら注文・会員データ

つまり、“DBの個数が無制限”でも、1個が膨らむと詰まることがあります。

アカウント全体の上限（総ストレージ）

“DBは無制限”でも、サーバーのディスク容量は有限です。
多くの場合、DBもサイトデータもメールも、同じストレージ枠を共有します。

• Webファイル（画像・テーマ・プラグイン）
• DBの実体（データファイル）
• メール（受信箱に溜まった添付など）
• バックアップ領域（サービス仕様による）

そのため、実務では DBよりメールが原因で容量が尽きるケースもあります。

inode（アイノード）制限

inodeはざっくり言うと、ファイルやディレクトリの“個数”上限です。
容量が余っていても、ファイル数が多すぎると制限に当たることがあります。

• キャッシュファイルが大量に増える
• バックアップを世代保存しすぎる
• ECや会員制で画像・PDFが増える
• 開発環境でビルド成果物が増える

覚え方

• 容量：重さの上限
• inode：個数の上限

どちらも“無制限”ではないことが多いので、公式の仕様ページで確認するのが安全です。

“無制限”を見抜くための早見表

表現（よくある書き方）	実際に確認すべき場所	具体的に見るポイント
MySQL無制限	仕様ページ / 料金表の注記	DB作成数・1DB容量・上限条件
容量無制限	約款 / フェアユース	実質上限、過度利用の扱い
大容量対応	プラン比較表	DBとストレージの内訳・増設可否
バックアップあり	バックアップ仕様	頻度・保持期間・復元方法・対象範囲
高速・安定	技術仕様 / 障害情報	DB周りの制限（接続数・負荷制限）

高負荷・同時接続・クエリ制限がボトルネックになるケース

容量や作成数よりも、実際にトラブルになりやすいのが “負荷の上限” です。
これは「無制限」という言葉では見えにくい部分です。

ボトルネックになりやすい例

• アクセスが増えて 同時にDBへ問い合わせが集中
• 重い検索（絞り込み・並び替え）を多用
• プラグインが大量のSQLを発行している
• ECの注文処理・在庫更新など「書き込み」が多い
• バッチ処理（集計）をピーク時間に回している

サーバー側で起きがちな制限（表に出にくい）

• 同時接続数の上限（接続しすぎるとエラー）
• クエリ実行時間の上限（重い処理が途中で止まる）
• CPU/メモリの利用制限（共用サーバー特有）
• 特定の処理（大量INSERTなど）が抑制される

初心者向けの結論
「DBが無制限」より、まずは “普通に動き続けるか” が重要です。
将来アクセスが増えそうなら、DB周りの運用がラクなサーバー（復元や移行がしやすい等）を優先すると失敗が減ります。

規約・フェアユースの考え方（過度利用で制限される可能性）

レンタルサーバーの“無制限”には、ほぼ必ず「公平に使う」前提があります。
これがフェアユース（公平利用）です。

フェアユースで問題になりやすい行為の例

• 明らかにバックアップ置き場として使う（巨大ファイル保管）
• 共有サーバーで高負荷処理を常時回す
• 自動生成ファイルを膨大に蓄積する
• DBを大量に作って放置し続ける（管理不能）
• 不正利用や迷惑行為に該当する運用

サーバー側から見ると、極端な利用は他ユーザーにも影響するため、

• 一時停止
• 制限の適用
• 上位プラン誘導
• 最悪は契約解除

という対応があり得ます。

対策として初心者ができること

• 仕様ページだけでなく、利用規約・禁止事項も確認
• 「無制限」の対象がどれか、“無制限の範囲”を言語化してから契約
• 迷ったらサポートに「この使い方は問題ないか」を事前確認

削除のリスク：消したDBは基本戻らない前提で考える

データベースは削除すると、原則として 元に戻せません。
ここは初心者が一度はハマりやすいポイントです。

「削除＝終わり」になりやすい理由

• 管理画面からDBを削除すると、即時に実体が消えることが多い
• ゴミ箱のような概念がない
• バックアップがあっても「削除前の状態」が残っていない場合がある

重要：バックアップが“あれば安心”とは限らない

バックアップにも種類があり、仕様で差が出ます。

• 自動バックアップ：頻度・保持期間・対象範囲がサービスごとに違う
• 手動バックアップ：自分の操作が必要（ただし確実性が高い）

特に注意したいのが、次のようなケースです。

• 自動バックアップはあるが 復元は有料または手順が複雑
• 復元できるのは サーバー全体で、DBだけ戻せない
• バックアップ対象外の領域がある（仕様を要確認）
• 保存期間が短く、気づいた時には世代が消えている

初心者向けの現実的な運用ルール

• DBを触る前に、必ずエクスポート（書き出し）して保管
  • 例：phpMyAdmin等でSQLを書き出す
• 重要作業の前後は、手動バックアップを1世代残す
• 「削除」ではなく、まずは リネーム・退避で様子を見る（可能な範囲で）

MySQL“無制限”が効くのはどんな人？

「MySQL無制限」は、“データベースをどれだけ増やす・育てる可能性があるか”で価値が変わります。
ここでは、初心者でも判断しやすいように「効く人／効きにくい人」を具体的に整理します。

複数サイト運営でDBが増えがちな人（検証・ステージング含む）

複数サイトを運営すると、DBは「サイト数 × 1個」だけで終わりません。
気づくとDBが増えていく典型パターンがあります。

DBが増えやすい例

• WordPressを複数立ち上げる（本番サイトが増える）
• 既存サイトの引っ越し・複製をする（移行作業中に“仮DB”が増える）
• テーマやプラグインの検証用サイトを作る（検証環境）
• 本番とは別にステージング環境を持つ（更新前チェック）
• 外注やチーム運用で「触っていい環境」を分ける（権限やリスク分散）

このタイプの人にとっては、DBの作成数に上限があると

• 「検証用に作りたいのに作れない」
• 「古いDBを消すのが怖くて整理できない」
• 「無理に同じDBに混ぜて、あとで管理が破綻する」

といった“運用ストレス”が出やすくなります。

“無制限”が活きるポイント

• DBを増やす場面で、余計な制約に邪魔されにくい
• 「本番・検証・予備」を分けやすく、安全に試せる
• サイトが増えても、DBの都合で設計を曲げにくい

ただし注意
DBが作れる＝安全、ではありません。
増えたDBを放置すると事故が起きやすいので、次のような運用が現実的です。

• DB名に用途を入れる（例：siteA_prod / siteA_stage）
• 使っていないDBを“消す前”にエクスポートだけ取る
• いつ・誰が・何のために作ったDBかメモを残す

将来の拡張を見越して余裕を持ちたい人（アクセス増・機能追加）

「今は小さいサイトだけど、伸びたら困りたくない」
この考え方はとても合理的です。特に、次のような拡張はDBに効いてきます。

伸びたときにDBが重くなりやすい要因

• 記事・固定ページ・リビジョンが積み上がる（長期運用）
• 検索・絞り込み・ランキング表示が増える（表示ロジックが複雑化）
• 会員機能・予約機能・問い合わせ管理などの追加（データが増える）
• EC化（注文・在庫・顧客情報が増える）
• 外部ツール連携（CRM、MA、分析、在庫管理など）

この段階で詰まりやすいのは、DBの“数”よりも 「負荷」「復元」「移行」 のほうです。
ただ、DB数が柔軟に増やせると、設計の選択肢が広がります。

“無制限”が活きる例

• 機能別にDBを分ける（分割する設計を選べる）
• 検証用DBを作って安全に試す（本番への影響を減らす）
• 移行用の一時DBを作りやすい（引っ越し作業がラク）

初心者向けの判断基準（目安）

次のどれかに当てはまるなら、将来を見て“無制限系”の恩恵を受けやすいです。

• 今後サイトを増やす予定がある
• 会員・予約・ECの追加可能性がある
• 検証環境を持ちたい（または持つべき運用になりそう）
• 移行やリライトを頻繁にする（作業用DBが増える）

小規模運用なら“無制限”より重視すべき指標もある

一方で、サイトが1つだけ・機能もシンプルなら、
「MySQL無制限」は“優先度が下がる”ことがあります。

理由は単純で、DBが増えにくい運用では、上限に当たりにくいからです。
その場合は「無制限かどうか」より、次の指標のほうが満足度に直結しやすいです。

小規模運用で重視したいチェック項目

• 自動バックアップの内容（頻度・保持期間・復元方法）
• 復元のしやすさ（管理画面で戻せるか／手順が難しいか）
• 表示速度と安定性（アクセス増に耐えられるか）
• サポートの質（困ったときに解決できる導線があるか）
• セキュリティ基本機能（WAF、SSL、権限周り）
• 管理画面の使いやすさ（初心者ほど効く）

特に重要なのがバックアップです。
DBは「削除」や「不整合」が起きたとき、ファイルより復旧が難しくなりがちなので、“戻せる仕組み”があるかは最優先級になりやすいです。

迷ったときの簡易診断

あなたの状況	“無制限”の優先度	まず見るべきポイント
サイトを複数運営する／増やす予定	高い	DB作成数・管理性・バックアップ
ステージングや検証をしたい	高い	DBを分けやすいか・復元手順
会員・予約・ECなどを追加予定	中〜高	負荷耐性・復元・DBバージョン
1サイトでブログ中心（小規模）	低〜中	バックアップ・速度・サポート

結論

• “無制限”が効くのは、DBを増やす運用（複数サイト・検証・拡張）の人
• 小規模なら、バックアップと復元のしやすさを先に重視したほうが失敗しにくい

失敗しない選び方：確認すべきチェック項目

「MySQL無制限」と書かれていても、“どこが無制限で、どこに上限があるか”はサービスごとに違います。
ここでは初心者でも見落としにくいように、契約前に確認すべきポイントを「何を見るべきか」「なぜ重要か」「どう判断するか」で整理します。

DBの作成可能数（アカウント単位／ドメイン単位の違い）

最初に確認したいのが「DBをいくつ作れるか」。ただし、“数”そのものより単位が重要です。

よくある単位の違い

• アカウント単位：契約（サーバー）全体で〇個まで
  → 複数ドメイン運用だと、早く上限に当たりやすい
• ドメイン単位：ドメインごとに〇個まで
  → サイトを分けても管理しやすい反面、ドメイン追加で増える場合も
• プラン単位：プランを上げると上限が大きく変わる
  → 後から拡張できるかがポイント

チェックのコツ（初心者向け）

• 仕様表に「DB数：無制限」とあっても、注記で
  “目安”や“過度利用の制限”が書かれていないか確認
• WordPressを複数立ち上げるなら、DBが増える前提で見積もる
  （本番＋検証＋移行作業用など）

判断の目安

• 1サイト運用：DB数は“そこまで重要じゃない”ことも多い
• 複数サイト／検証環境あり：DB数と単位が効いてくる ✅

1つのDBに割り当てられる容量と、総量の上限

「DBが無制限」でも、実際に詰まりやすいのは容量（サイズ）です。

見るべき上限は2つ

1. 1DBあたりの上限（例：1つのDBは〇GBまで、など）
2. アカウント全体の上限（サーバー全体のディスク容量・上限条件）

さらに、DBとは別軸で効いてくるのが inode（ファイル数） です。

• ディスク容量が余っていても
  ファイル数が多すぎると制限に当たる場合があります

初心者が特に注意すべき“増えやすい原因”

• WordPressのリビジョン（編集履歴）
• プラグインのログ、統計、キャッシュ
• EC・会員サイトの注文履歴やユーザー情報の蓄積
• 自動バックアップの世代を自分でも溜め込む（手動保存含む）

ミニ表：上限の考え方

何の上限？	影響が出る例	対策の方向性
1DB容量	DBが肥大して保存できない	DB整理・設計見直し・上位プラン
総ストレージ	Web/メール/DBが一緒に圧迫	不要データ削除・運用ルール
inode	キャッシュ/バックアップが大量	生成物の整理・世代管理

MySQL/MariaDBの種類・バージョン・文字コード対応

初心者は「MySQLかMariaDBか」より、バージョンと文字コードのほうがトラブルになりがちです。

確認したいポイント

• DBエンジン：MySQL / MariaDB（互換性は高いが差はある）
• バージョン：古いと使えない機能や挙動差が出る
• 文字コード：日本語サイトなら実質ここが最重要のひとつ

文字化けを避ける基本（超重要）

• 推奨は utf8mb4（絵文字や一部文字も安全に扱える）
• 仕様ページに「utf8mb4対応」「照合順序（collation）」の記載があるか確認

こんな人は要注意（差が出やすい）

• 既存サイトを引っ越しする（旧環境とのズレ）
• プラグインやテーマが特定のバージョン前提
• 開発用途でSQLの互換性にシビア

自動バックアップの有無（頻度・保存期間・世代数）

DB運用で一番怖いのは、“戻せない”ことです。
自動バックアップがあっても、内容次第で安心度は大きく変わります。

確認すべき4点

• 頻度：毎日？数時間ごと？
• 保存期間：何日分残る？
• 世代数：複数世代残る？（上書きだけだと弱い）
• 対象範囲：DBだけ？サーバー全体？メールは？除外は？

注意点

• “バックアップあり”でも、復元は有料／申請が必要な場合がある
• 自動バックアップとは別に、重要作業の前は手動エクスポートが堅い ✅

復元のしやすさ（管理画面で戻せるか／手順の難易度）

同じ「バックアップあり」でも、復元が難しいと実戦では使えません。

復元手段は主に3タイプ

1. 管理画面でワンクリック復元（初心者向き・事故が減る）
2. サポートに依頼して復元（安心だが時間と手間がかかる）
3. 自分で復元（SQLインポート等）（自由度高いがミスしやすい）

初心者におすすめの確認方法

• マニュアルに「復元手順」が画像付きで載っているか
• 復元単位が「DBだけ」か「サーバー全体」か
  → DBだけ戻せないと、他の変更まで巻き戻りがち

外部からの接続可否（リモート接続）と安全な運用条件

「自宅PCや別サーバーからDBに接続できるか？」は用途で重要度が変わります。

外部接続が必要になりやすいケース

• 開発端末から直接DBを操作したい
• 別サーバーのアプリからDBに接続したい
• 移行・検証で外部ツールを使いたい

ただし、外部接続はセキュリティリスクも増えます。
許可されている場合でも、次の条件を満たせるか確認してください。

• 接続元IPの制限ができる（できないなら難易度が上がる）
• 強いパスワードと、不要ユーザーの削除
• 権限を最小化（管理者権限を常用しない）
• 通信の保護（TLS等）が仕様上どうなっているか

初心者で「外部接続がよく分からない」なら、
まずは “不要ならOFFでいい機能” と考えるのが安全です。

安定性の見方（負荷耐性・ディスクI/O・ネットワーク品質）

DBは「容量」より「負荷」で詰まりやすいです。
特に共用サーバーでは、同時接続や重いクエリで限界が来ることがあります。

初心者が見やすい“安定性チェック”

• 公式サイトに 稼働率（SLA） や障害情報の掲載がある
• 速度・混雑に関する説明が具体的（CPU/IO/転送など）
• DB以外も含めた運用機能が整っている（キャッシュ、WAF等）

体感で差が出る例

• 管理画面が重い（混雑しやすい）
• 夜間や特定時間に急に遅くなる
• WordPressの管理画面で保存が失敗する
  → DB負荷や制限の可能性

サポート品質（問い合わせ導線・対応時間・ドキュメント）

初心者ほど「詰まったときの解決速度」が成果に直結します。

チェックポイント

• 問い合わせ手段：チャット／メール／電話（どれがあるか）
• 対応時間：平日のみか、夜間・土日もあるか
• 公式マニュアルの検索性：用語が分からなくても辿り着けるか

見落としがちな罠

• “24時間”でも返信は後日、など運用実態が違うケース
• DB関連（復元・移行）は別窓口・別料金になることがある

セキュリティ（WAF／権限分離／TLS／IP制限など）

DBは個人情報や顧客情報が入ることもあるため、セキュリティは最重要級です。

最低限チェックしたい項目

• WAF（Web攻撃の防御）
• TLS/SSL（通信の暗号化）
• 管理画面の保護（2段階認証の有無など）
• 権限分離（他ユーザーの影響を受けにくい設計か）
• IP制限（管理画面／DB接続／SSH等、可能な範囲で）

初心者向けの結論

• “無制限”より、事故を防ぐ仕組みが整っているかを優先
• DBを外部公開しない運用（必要時だけ限定）だと安全性が上がる ✅

商用利用の注意点（免責範囲・禁止事項・障害対応の範囲）

ビジネス用途（広告収益含む）なら、規約と障害対応の線引きが重要です。
“無制限”表記の裏には、だいたい規約があります。

確認すべきポイント

• 禁止事項（過度な負荷、バックアップ置き場利用、常時高負荷処理など）
• 免責範囲（障害時の補償、データ消失時の責任範囲）
• 復旧の範囲（復元してくれるのか、自己責任なのか）
• メンテナンス方針（事前告知、時間帯、影響）

初心者でもできる“安全な読み方”

• 仕様ページ → 注記 → 利用規約 → FAQ の順に読む
• 重要項目はスクショやメモで保存しておく（後で揉めない）

コピペ用：契約前チェックシート

最後に、比較するときに使える“短いチェックシート”です（そのままメモに貼れます）。

• [ ] DB作成数の単位：アカウント単位／ドメイン単位／プラン単位
• [ ] 1DB容量の上限：有無／目安／注記
• [ ] 総ストレージ＆inode：上限と過度利用条件
• [ ] DB種類とバージョン：MySQL/MariaDB、utf8mb4対応
• [ ] 自動バックアップ：頻度／保存期間／世代数／対象範囲
• [ ] 復元方法：管理画面で可能？DBだけ戻せる？費用は？
• [ ] 外部接続：可否／IP制限／安全に運用できる条件
• [ ] 安定性：障害情報の公開、混雑時の挙動、SLAの有無
• [ ] サポート：窓口、対応時間、DB系トラブルの解決導線
• [ ] セキュリティ：WAF、TLS、2FA、権限分離、IP制限
• [ ] 規約：禁止事項、免責、障害時の対応範囲

比較表の作り方：スペックを正しく読み解くコツ

レンタルサーバーの「MySQL無制限」は、“どの項目が無制限なのか”がサービスごとに違うため、比較表を作ると一気に判断しやすくなります。

ここでは、初心者でも迷いにくいように

• 何を列（比較軸）にするか
• どうやって“無制限”表記を見抜くか
• 料金以外のコストをどう見積もるか

を、実務で使える形に落とし込みます。

“無制限”表記を鵜呑みにしないための比較軸（DB数・容量・復元）

まず結論：比較表は「DBの使い勝手」＋「戻せるか」で作る

「無制限」の正体は、だいたい次の3カテゴリに分解できます。

• 増やせるか：DBの作成数（上限・単位）
• 溜められるか：容量（1DB・総量・関連上限）
• 戻せるか：バックアップと復元（手間・費用・単位）

この3つが揃って初めて、運用がラクになります。

比較表の“基本列”テンプレ（まずこれだけでOK）

下の表は「MySQL無制限」を判断するのに効く列だけを厳選しています。
（値は各社の公式の料金表・仕様表・機能一覧・利用規約で埋める前提です）

比較軸	書く内容（例）	なぜ重要？
DB作成数	無制限 / ◯個 / プランで変動	複数サイトや検証で差が出る
上限の単位	アカウント単位 / ドメイン単位	“無制限”でも実質上限になりやすい
1DB容量	上限あり/なし、目安の有無	DB肥大で詰まる典型ポイント
総ストレージ	◯GB、増設可否	DBだけでなく全体で詰まる
inode等の制限	あり/なし（目安）	容量が余っても止まることがある
DB種別	MySQL / MariaDB	互換性の前提を把握する
DBバージョン	例：MySQL 8系など	移行・互換・機能差に直結
文字コード	utf8mb4対応など	文字化け・絵文字の事故回避
自動バックアップ	頻度・保持期間・世代数	“戻れる期間”が決まる
復元手段	管理画面 / 依頼 / 自力	いざという時の復旧速度
復元単位	DBだけ / サーバー全体	余計な巻き戻しを防ぐ
復元コスト	無料/有料/回数制限	実務の運用コストに直結
外部接続	可否・制限（IP制限等）	開発/移行の自由度と安全性
サポート	窓口・時間・範囲	初心者の詰まり解消に効く

“無制限”を見抜くコツ：表に「注記列」を作る

比較表で最も強いのは、スペックの数字よりも 注記（条件） です。
同じ「無制限」でも、条件次第で体感が変わります。

おすすめは、表に小さく「注記」列を追加すること。

• 無制限の条件（フェアユース、過度利用の扱い）
• 例外（バックアップ対象外、復元は申請のみ 等）
• “別ページに書いてある制限”（よくある見落とし）

例（テンプレ）：

サービス	DB作成数	1DB容量	自動バックアップ	復元	注記（重要）
A社	無制限	記載なし	毎日・◯日	管理画面	※過度利用は制限の可能性、復元は回数制限 など
B社	◯個	◯GB	なし	自力	※バックアップは自己責任 など

“無制限”の比較は、この注記列があるだけで精度が一気に上がります。

情報の集め方：公式ページを「4点セット」で見る

埋めるときは、1ページだけ見て判断しないのがコツです。

• 料金表（プラン比較）
• 機能一覧（DB・バックアップ・復元）
• 仕様/制限（inode、DB上限、同時接続など）
• 利用規約・禁止事項（フェアユース、過度利用）

同じ項目が別ページに分散していることが多いので、出典メモ（URLや更新日）も一緒に控えると後で迷いません。

料金だけで選ばない：運用コスト（復旧・移行・保守）まで含める

“月額の安さ”より、事故が起きたときの総コストが効く

DB周りは、問題が起きると 時間（＝コスト） が一気に増えます。
そこで比較表に「運用コスト列」を足すと、長期で失敗しにくくなります。

運用コストに入れるべき項目（初心者向け）

見落としやすいけど差が出るものを挙げます。

• 復元のコスト
  • 復元が無料か有料か
  • 依頼が必要か（待ち時間が発生する）
  • DBだけ戻せるか（全体復元だと巻き戻しが増える）
• 移行のコスト
  • DBのエクスポート/インポートがやりやすいか
  • バージョン差で不具合が出そうか
  • 外部接続やツール利用が可能か
• 保守のコスト
  • 自動バックアップの安心度（頻度・保持期間）
  • 障害情報の公開、メンテ方針
  • サポートの対応時間と品質

“総コスト”をざっくり計算する簡易式

比較のためのラフな目安として、こう考えると判断がブレにくいです。

• 総コスト ≒ 月額料金 +（トラブル時の復旧時間 × あなたの時給換算）+（移行/保守の手間）

たとえば月額が少し高くても、

• 復元が管理画面でできる
• 自動バックアップが手厚い
• サポートが早い

なら、事故のたびに消える時間が減って結果的に得になりやすいです。

初心者におすすめの“選び方の優先順位”

「MySQL無制限」を探している人向けに、迷いにくい順番に並べるとこうです。

1. 復元できるか（復元の単位・手段・費用）
2. 容量が詰まらないか（1DB/総量/inode）
3. 増やせるか（DB数と単位）
4. 移行しやすいか（外部接続・バージョン・文字コード）
5. サポートと規約が明確か（フェアユースの透明性）

“無制限”の言葉に引っ張られず、「戻せる」「詰まらない」を中心に表を作ると、初心者でも失敗しづらくなります。

MySQLを“実質無制限”で使いやすいレンタルサーバー（用途別）

ここでいう「実質無制限」は、DBの“作成数”が多い（または無制限）だけでなく、次の条件まで含めて「運用しやすい」状態を指します。

• バックアップが標準で用意され、復元が現実的（管理画面で戻せる／手順が重すぎない）
• DB容量が「無制限」に見えても、総ストレージ・inode・負荷制限で詰まらない
• 規約・フェアユースの範囲で、複数サイト／検証環境を回しやすい

WordPress中心で堅実に運用したい人向け

先に“DBまわり”だけをざっくり俯瞰すると、こんな感じです（※細部はプランや仕様変更があり得るので、申込前に最新を確認してください）。

サービス	DB作成数の傾向	容量で詰まりやすい所	バックアップ／復元の考え方
エックスサーバー	作成数は多い（実質無制限系）	1DB容量・総ストレージ・負荷	自動バックアップ＋復元手段が用意されやすい
シンレンタルサーバー	作成数は多い（実質無制限系）	1DB容量・総ストレージ・負荷	自動バックアップ＋復元手段が用意されやすい
ConoHa WING	作成数は多い（実質無制限系）	総ストレージ・負荷	自動バックアップ／復元（対象・手順を確認）
ロリポップ！	プランで差が大きい（上位で無制限）	総ストレージ・ファイル上限	上位プランは自動バックアップ無料、他はオプション前提も
さくらのレンタルサーバ	プランで作成数が決まる	DB容量（目安）・テーブル数	DBを“何で”バックアップするかを事前設計

エックスサーバー

こんな人に向く

• WordPressを複数運営（本番＋ステージング＋検証）して、DBが増えがちな人
• 「DBは増えるけど、運用はなるべく簡単にしたい」タイプ

DB運用のポイント

• “無制限”でも、DB容量や負荷の上限は別物です。まずは
  • 1DBの容量目安
  • 負荷が増えたときの制限（同時接続・リソース）
    をセットで見るのが安全です。

落とし穴回避 ✅

• 重要DBは「自動バックアップ任せ」だけにしない
  • 例：週1でSQLダンプを外部保管、月1で世代を長めに残す

エックスサーバー公式サイト

シンレンタルサーバー

こんな人に向く

• WordPress中心で、DBを増やしながらもコストを抑えたい人
• “多サイト運営”を見据えて、DB作成数に余裕が欲しい人

DB運用のポイント

• DB作成数が多いタイプでも、結局は
  • 総ストレージ
  • DB容量（目安）
  • バックアップの復元導線
    が整っているほど「実質無制限」としてラクになります。

落とし穴回避 ✅

• テスト用DBを増やしすぎると、整理コストが膨らみます
  • DB命名規則（site_env_date など）を決めておくと管理が楽

シンレンタルサーバー公式サイト

ConoHa WING

こんな人に向く

• WordPressを伸ばしていく前提で「DB作成数の不安」を先に消したい人
• バックアップ／復元の仕組みを理解して、運用でカバーできる人

DB運用のポイント

• “DB無制限”でも、高負荷・同時接続・重いクエリがボトルネックになることがあります。
  • 例：会員制でログイン状態のページが多い／検索・絞り込みが重いEC

落とし穴回避 ✅

• アクセス増を見越すなら、DBだけでなく
  • キャッシュ（ページキャッシュ／オブジェクトキャッシュ）
  • 画像最適化
  • プラグイン整理
    まで含めて“DBに負荷を寄せない設計”にする

ConoHa WING 公式サイト

ロリポップ！

こんな人に向く

• 予算を抑えつつ、上位プランで“DB無制限”の運用をしたい人
• サポートや管理画面のわかりやすさも欲しい人

DB運用のポイント

• プラン差が大きいのが特徴です。
  • 下位：MySQL作成数が有限
  • 上位：MySQL作成数が無制限
• 自動バックアップも、無料で付くプラン／オプション前提が分かれます。

落とし穴回避 ✅

• “無制限にするために上位へ”が必要なら、
  （月額差）×（運用年数）で現実的かを先に計算するとブレません 💡

ロリポップ！公式サイト

さくらのレンタルサーバ

こんな人に向く

• 長期で堅実に運用し、プラン設計（DB数・容量）をきっちり決めたい人
• DBのバックアップを「自分の運用」で担保できる人

DB運用のポイント

• DB作成数はプランで決まり、DB容量にも目安があります。
• さらに、テーブル数の目安が示されているため、データ構造が増えやすいサイトは要注意です。

落とし穴回避 ✅

• 「スナップショットがある＝DBも安心」とは限りません。
  • DBがバックアップ対象かどうか
  • どこまで復元できるか
    を契約前に必ず確認しましょう。

さくらのレンタルサーバ公式サイト

法人運用・複数案件で管理やサポートを重視したい人向け

Xserverビジネス

こんな人に向く

• クライアント案件・社内サイトなどで「事故らない」を最優先したい人
• DB復元の導線（管理画面・手順）を整えておきたい人

DB運用のポイント

• “DB作成数”だけでなく、復旧の速さが価値になります。
  • 障害時に「誰が、どこから、何を、どの手順で戻すか」を決めやすい構成が◎

XServerビジネス公式サイト

CPIレンタルサーバー（シェアード系プラン）

こんな人に向く

• 仕様書・運用要件を見ながら、法人として“管理できる形”を取りたい人
• 監査・社内稟議で、仕様の根拠が必要なケース

DB運用のポイント

• “無制限”とされる項目があっても、フェアユース／免責／障害対応範囲がセットで効いてきます。
• DBの「設定数」「容量」「バックアップ方法」は、公開仕様の該当欄を確認してから判断が安全です。

CPIレンタルサーバー公式サイト

ヘテムル

こんな人に向く

• ある程度の規模で、安定運用とサポートを重視したい人
• DB数が増えがちな運用（複数サイト・検証）を想定している人

DB運用のポイント

• DB作成数が多い設計でも、結局は
  • 復元のしやすさ
  • 障害時の切り分けのしやすさ
    が“実質無制限”の体感を左右します。

ヘテムル公式サイト

コスパ重視／要件がハマると強い選択肢

このカテゴリは「刺さる人には刺さる」一方で、“無制限の内訳”がサービスごとに違うため、先に確認軸を固定すると失敗が減ります。

• DB作成数（本当に無制限か／上位だけか）
• DB容量（1DB上限・総量・ストレージ共有）
• バックアップ（自動の有無／復元の手間）
• 負荷制限（同時接続・クエリ制限・CPU/IO）
• inode／ファイル上限（画像・キャッシュで詰まりやすい）

mixhost

向く人

• DB作成数を気にせず増やしたい人（ただし運用条件は要確認）

注意点

• DBそのものより、inode（ファイル数）や総ストレージで先に詰まることがあります。
  • 画像やバックアップを置きっぱなしにしない運用が大事

mixhost 公式サイト

ColorfulBox

向く人

• DBを増やしながら、ストレージの範囲で柔軟に使いたい人
• “DB数だけ無制限”ではなく、実容量の見通しを立てたい人

ポイント

• DB容量・数は「契約プランのSSD枠内」で管理する考え方なので、見積もりがしやすいです。

ColorfulBox 公式サイト

ラッコサーバー

向く人

• 小〜中規模の複数サイト運営で、DBを増やしやすい構成を探している人

ポイント

• DB作成数が多い設計でも、バックアップと復元をどうするかは別途確認が安全です。

ラッコサーバー公式サイト

コアサーバー

向く人

• コスパ重視でDBを増やしたいが、技術的な注意点も読める人

注意点

• “無制限”でも、負荷制限（例：同時接続など）が実運用の天井になります。
  • 会員制やECなど、DBアクセスが集中するサイトは要検討

CORESERVER 公式サイト

ギガレンタルサーバー

向く人

• とにかく低価格志向で、仕様を自己責任で読み解ける人

確認ポイント

• 「DBが使える」ことと「DBを安心して運用できる」ことは別です。
  • DB数・容量
  • バックアップ／復元
  • 採用ソフトウェアの更新状況
    を必ず確認しましょう。

お名前.comレンタルサーバー（SD-12）

向く人

• DB作成数が多く必要で、1DB容量の上限も把握したうえで運用したい人

注意点

• 「DB無制限」でも、1DBあたりの容量上限があると設計が変わります。
  • 例：メディアがDBに溜まる系の仕組み、巨大ログ保存など

お名前.com レンタルサーバー公式サイト

Quicca Plus

向く人

• DB数が「少数でも足りる」前提で、月額を抑えたい人

注意点

• DB作成数がプランで決まるタイプは、後から増えると移行が発生しがちです。
  • 将来の増加（検証DB・追加サイト）を見込むなら要注意

Quicca Plus 公式サイト

レンタルサーバー【クイッカ】

向く人

• プラン選定をきちんと行い、DB数の要件を満たせる人

ポイント

• 上位プランでDBが“無制限相当”になるタイプなら、
  「今どのプランが必要か」だけを見誤らないことが重要です。

エックスツーサーバー（例：スタンダード系）

注意点

• 同名・類似名のサービスがある場合、提供会社と公式仕様の一致をまず確認しましょう。
• 公式に「DB数」「容量」「バックアップ」「復元手順」が明記されていないなら、
  “無制限”を前提に選ぶのはおすすめしません。

「無限」（サービス名として挙がっている場合の確認ポイント）

サービス名に「無限／無制限」が入っていても、見るべきは名前ではなく中身です。

• MySQLのバージョンが古くないか（セキュリティ面に直結）
• DBバックアップの仕組み（自動か、手動か、復元手順は明確か）
• 規約・禁止事項（フェアユース、過度利用の扱い）
• 障害時の情報公開・連絡体制

運用・移行でつまずかないための実務知識（追加）

「MySQL無制限」を選んでも、実際に困るのは 移行・速度低下・トラブル対応の場面です。
ここでは、初心者でも手順を追えるように「現場で効くポイント」を絞ってまとめます。

DBの移行方法（エクスポート／インポートの基本）

DB移行は、ざっくり言うと “取り出す（エクスポート）→入れる（インポート）” です。
ただし、失敗の多くは「手順」ではなく 前提条件のズレで起きます。

まず押さえる移行の型（おすすめ順）

1）WordPress移行ツール（初心者向け）

• メリット：手順が簡単、DBとファイルをまとめて扱える
• デメリット：大容量だと失敗しやすい／細かい制御が難しい

2）phpMyAdmin（管理画面で操作）

• メリット：レンタルサーバーで使えることが多い
• デメリット：インポート上限（ファイルサイズ、実行時間）に引っかかりやすい

3）コマンド（WP-CLI / mysqldump）（中級者寄り）

• メリット：大きいDBでも安定しやすい、再現性が高い
• デメリット：SSHやコマンド操作が必要

失敗を減らす「移行前の5チェック」✅

• DBの文字コード：utf8mb4 が使えるか（旧環境が utf8 だと差が出ることも）
• 照合順序（collation）：新旧で違いが大きいとエラーになる場合あり
• DBサイズ：エクスポートファイルが大きいほど、インポート制限に当たりやすい
• 権限：接続ユーザーに「作成」「挿入」「更新」などがあるか
• 停止時間の設計：完全停止／差分同期／一時メンテ表示、どれで行くか決める

phpMyAdminでの基本手順（最小で迷わない流れ）

エクスポート（旧サーバー）

1. phpMyAdminで対象DBを選ぶ
2. エクスポート → 方式は「カスタム」推奨
3. 圧縮は gzip（容量が小さくなりやすい）
4. 出力したファイルをPCへ保存

インポート（新サーバー）

1. 新サーバーでDBを新規作成（DB名・ユーザー・パスを控える）
2. phpMyAdminで新DBを選ぶ
3. インポート → ファイルを選択して実行
4. 文字コードや照合順序の警告が出たら、そこで止めて確認

ありがちな詰まりポイント

• アップロード上限でファイルが送れない
• 実行時間制限で途中で止まる
• 文字コード／照合順序の不一致でエラー

その場合は、次のどれかが現実的です。

• 分割してインポート（大きなSQLを小分けにする）
• 圧縮して再試行（gzip）
• コマンド移行に切り替える（可能なら一番安定）

コマンド移行の“超ざっくり例”（SSHが使える場合）

• エクスポート：mysqldump でSQLを作る
• インポート：mysql コマンドで流し込む

DBが大きいサイトほど、GUIよりコマンドの方が成功率が上がりやすいです。

速度が落ちる典型パターン（肥大化・インデックス不足・ログ蓄積）

「無制限っぽいから大丈夫」と放置すると、DBは静かに重くなります。
初心者がハマりやすい“典型”を、原因→症状→対策でまとめます。

1）データ肥大化（増えすぎ）

原因例

• WordPressのリビジョン、下書き、自動保存が蓄積
• プラグインがログやキャッシュをDBに溜める
• EC/会員サイトで注文・ユーザー・履歴が増える

症状

• 管理画面の表示が遅い
• 記事更新の保存に時間がかかる
• バックアップに時間がかかる

対策

• 不要なリビジョン削除（プラグインやWP-CLIで整理）
• ログ系プラグインの設定見直し（保存期間・件数上限）
• 「DBにキャッシュを溜める設計」を減らす（キャッシュの置き場所を再検討）

2）インデックス不足（探すのが遅い）

原因例

• 検索・絞り込みを多用するのに、適切なインデックスがない
• プラグインが重いクエリを投げている

症状

• 特定ページだけ極端に遅い
• ピーク時に落ちやすい（同時接続が増えると顕著）

対策（初心者ができる範囲）

• まずはプラグインを疑う（停止→改善で特定）
• キャッシュ（ページキャッシュ）を導入してDBへの問い合わせ回数を減らす
• 無理にSQLをいじらず、「クエリを減らす」設計に寄せるのが安全

3）ログ／一時データの蓄積（気づきにくい）

原因例

• 統計・アクセス解析・セキュリティ・フォーム系がDBに履歴を保存
• wp_options に自動読み込み（autoload）されるデータが増える

症状

• サイト全体がじわじわ遅くなる
• 特にトップや管理画面が重い

対策

• ログの保存期間を短くする、上限を付ける
• 不要プラグインの削除（停止ではなく削除でテーブルが残る場合に注意）
• DBを触る前に必ずバックアップ（削除操作は戻せない前提）

トラブル時の切り分け（容量／権限／接続数／文字化け）

トラブル対応は「当てずっぽう」だと長引きます。
以下の順で切り分けると、初心者でも迷いにくいです。

1）容量・上限系（まずここ）

よくあるサイン

• バックアップが失敗する
• DBの書き込みでエラーが出る
• 管理画面で保存できない

見るべきポイント

• サーバー全体のストレージ使用量
• DBサイズ（可能なら）
• inode（ファイル数）上限の有無

対処の方向性

• 不要なバックアップ・キャッシュ・ログを整理
• メールが溜まっている場合は添付や迷惑メールの掃除も効くことがあります

2）権限系（接続できるのに操作できない）

よくあるサイン

• “Access denied” 系のエラー
• インポート中に「権限がない」エラー

見るべきポイント

• DBユーザーが正しいDBに紐づいているか
• 権限（SELECT/INSERT/UPDATE/CREATE…）が足りているか

対処の方向性

• いったん「正しいDB・正しいユーザー・正しい権限」を作り直す方が早いケースが多いです

3）接続数・負荷系（混雑で落ちる）

よくあるサイン

• “Too many connections”
• 時間帯によって遅い／落ちる
• ECや会員系でピーク時に顕著

見るべきポイント

• キャッシュが効いているか（未キャッシュでDB直撃していないか）
• 重い処理が同時に走っていないか（バックアップ、集計、クローン等）
• プラグイン追加後に発生していないか

対処の方向性

• キャッシュ導入／見直し
• 重い処理は深夜にずらす
• プラグインの整理（特定→代替）

4）文字化け（移行後に多い）

よくあるサイン

• 日本語が「????」になる
• 絵文字が消える／保存できない

見るべきポイント

• 文字コードが utf8mb4 か
• 照合順序（collation）が新旧で大きく違わないか
• WordPressなら wp-config.php のDB設定（定義）も確認対象

対処の方向性

• “部分的に直す”より、文字コードと照合順序を揃えてから再インポートが安全なことが多いです

定期メンテの考え方（不要データ整理・最適化・バックアップ検証）

「MySQL無制限」でも、メンテをしないと 遅くなる／復元できない／移行で詰まるが起きます。
初心者向けに、やることを“最小セット”に落とします。

月1でやると効く“4点メンテ”✅

1. バックアップが取れているか確認
   • 「取れているつもり」になりやすいので、ログや結果を一度見る
2. 復元テストを小さくやる
   • 本番に戻す必要はありません
   • 例：検証環境にインポートして「開けるか」だけ確認
   • 復元の成功体験があるだけで、事故時の対応が速くなります
3. 不要データを整理（特にログ・リビジョン）
   • まずは「増え続ける系」を対象にするのがコスパ良いです
4. プラグイン棚卸し
   • DBを重くする原因の上位はプラグインになりやすいです
   • 「停止中のまま放置」もデータが残るので、必要性を見直します

やりすぎ注意：最適化は“目的”を決めてから

「最適化」には響きがありますが、むやみにやると事故の元です。

• 何を改善したいのか（表示速度？バックアップ時間？管理画面？）
• 何を削除するのか（ログ？キャッシュ？履歴？）
• 失敗したら戻せるのか（バックアップがあるか）

この3つが揃ってから触るのが安全です。

契約前の最終確認

「MySQL無制限」と書かれていても、本当に安心して運用できるかは、最後に読むべきページ（規約・仕様・FAQ）で決まります。
ここでは初心者でも迷わないように、契約直前に見るポイントを“文言ベース”で整理します。

公式の規約・仕様ページで見るべき文言（上限・禁止事項・免責）

まず結論です。契約前に確認したいのは、スペック表よりも 「注記」「規約の条文」「制限の説明」です。
特に「無制限」の周辺には、たいてい条件が隠れています。

1) 上限に関する文言（“無制限”を現実に戻す部分）

仕様ページや注記で、次のような表現を探してください。

• 「上限」「目安」「推奨」「過度利用」
  • 例：“過度な利用が認められる場合は制限する”
• 「リソース」「負荷」「同時接続」「実行時間」
  • DB容量ではなく、処理の上限が実質の天井になることがあります
• 「ディスク容量」「ファイル数（inode）」「バックアップ領域」
  • DB以外（メール・キャッシュ・バックアップ）が原因で詰まることも多いです

チェックのコツ
「MySQL無制限」と書かれたページだけで判断せず、同じサイト内の

• 「仕様・制限」
• 「FAQ」
• 「禁止事項」
• 「公平利用（フェアユース）」

まで横断して読むのが安全です。

2) 禁止事項・フェアユース（止められる条件の核心）

次のような文言がある場合、運用の仕方次第で制限対象になります。

• バックアップ用途・保管庫用途の禁止
• 常時高負荷／大量アクセスを前提とした使い方の禁止
• 自動生成ファイルの大量作成、ログ蓄積の放置
• “他者の利用に支障を与える行為” の禁止（かなり広い）

初心者向けの判断基準
禁止事項が広いこと自体は普通ですが、重要なのは

• どの状態になったら制限されるのか（例：負荷、通信量、同時接続、ファイル数など）
• 事前通知があるか（突然止まるのか）
• 改善の猶予があるか

が読み取れるかどうかです。

3) 免責（“データが消えたとき”の責任範囲）

免責は難しく見えますが、初心者はここだけ拾えばOKです。

• 「データ消失に対する責任を負わない」
• 「逸失利益（機会損失）を補償しない」
• 「損害賠償は月額料金を上限」（または上限の記載）

これは「冷たい」というより、レンタルサーバーの一般的な前提です。
だからこそ “バックアップは誰が担保するか” が次の見出しの主役になります。

障害時の復旧範囲（バックアップは誰の責任か）

同じ「自動バックアップあり」でも、安心度はピンキリです。
契約前に、次の3点を言葉で説明できる状態にしておくと失敗しにくいです。

1) バックアップの責任者は誰か

• サービス側がバックアップを提供しても、規約上は
  「復元を保証しない」「データ保全は利用者責任」
  となっていることが多いです。

現実的な結論
自動バックアップは“保険”としてありがたいですが、重要サイトほど
自分でもバックアップ（外部保管）を持つのが安全です。

2) 復旧の範囲（どこまで戻せるか）

確認したいのは「バックアップがあるか」ではなく、次の具体です。

• 復元単位：DBだけ戻せる？ サーバー全体？
• 復元方法：管理画面で可能？ 依頼が必要？
• 復元のコスト：無料？ 有料？ 回数制限は？
• 保持期間：何日分戻せる？ 何世代残る？

事故の多いパターン
「復元はできるが“全体復元のみ”で、他の変更まで巻き戻る」
→ 復元単位は必ず確認したいポイントです。

3) 障害時に“何をしてくれるか”の線引き

障害対応ページやサポート規約で、次を確認します。

• 障害告知の方法（ステータスページ、SNS、メールなど）
• 調査・復旧の優先順位（共用は「全体復旧が優先」になりやすい）
• 個別データ復旧への対応（原則不可の場合もある）

おすすめの実務
契約前に「DBを誤って削除した場合、復元は可能か？条件は？」を
サポートに文章で問い合わせして、回答を保存しておくと安心です。

ビジネス利用で問題になりやすい制限（大量アクセス・大量書き込み等）

ビジネス（広告収益・集客含む）では、「容量」より“負荷”と“継続性”が問題になりがちです。

よくある“引っかかりポイント”

• 大量アクセス
  • SNS拡散、メディア掲載、キャンペーンで急増
• 大量書き込み
  • 会員登録、注文、予約、コメント、ログ保存
• 重い処理
  • 検索・絞り込み、ランキング集計、外部API連携、バッチ処理

これらは「DB無制限」とは別軸で、次の制限に当たりやすいです。

• 同時接続数の上限
• クエリ実行時間の上限
• CPU/メモリ/IOの制限（共用サーバーで顕著）
• 一時的なアクセス制御（負荷軽減措置）

事故を減らすための“契約前チェック”3点セット

1. 高負荷時の扱いが明記されているか
   • 制限の条件、通知、回復手順があるか
2. キャッシュ・CDNなど“逃がす手段”が取りやすいか
   • すべてがDB直撃だと、無制限でも耐えられません
3. プランアップの導線が現実的か
   • 「伸びたら上位へ」がスムーズにできると、機会損失が減ります

コピペ用：契約前の最終確認シート

• [ ] 「無制限」の対象は何か（DB数／テーブル数／その他）
• [ ] 1DB容量・総ストレージ・inode等の上限（注記含む）
• [ ] フェアユース／過度利用の条件（どの状態で制限される？）
• [ ] バックアップの頻度・保持期間・世代数
• [ ] 復元の単位（DBのみ？全体？）と手順、費用、回数制限
• [ ] 免責（データ消失・損害賠償の上限）
• [ ] 大量アクセス／大量書き込み時の制限と対応
• [ ] 障害情報の公開方法、サポート窓口と対応時間
• [ ] 契約時点の仕様ページを保存（PDF/スクショ）しておく

よくある質問

そもそもデータベースとは？

データベース（DB）は、ひとことで言うと 「整理されたデータ置き場」 です。
Excelの表を“巨大化して、検索・更新を速く安全にしたもの”に近いイメージです。

WebサイトでDBに入る代表例

• WordPressの記事本文、タイトル、カテゴリ、タグ
• ユーザー情報（会員制サイト）
• 注文データ（EC）
• コメント、フォームの送信内容
• 設定値（プラグインの設定、サイト設定）

ポイント

• 画像やテーマファイルは「ファイル」に保存されることが多い
• 文章・設定・履歴など“構造化データ”はDBに保存されることが多い

サーバーとデータベースは何が違う？

初心者が混乱しやすいので、役割を分けて考えるとスッキリします。

• サーバー：サイト全体が動く“場所”（ファイルもDBも動かす土台）
• データベース：サーバーの中で動く“部品”（データを管理する仕組み）

たとえばWordPressなら、

• サーバー：WordPress本体、画像、テーマ、PHPを動かす
• DB：記事・設定・ユーザー・履歴を保存して、必要なときに取り出す

という分担です。

よくある誤解

• 「DB＝別サービス」ではなく、多くの場合は サーバーの機能として提供されています。

MySQLとMariaDBは結局どちらを選べばいい？

結論はシンプルです。

• ほとんどの初心者：どちらでもOK（WordPress運用では体感差が出にくい）
• ただし、次の条件があるなら“確認したほうがいい”です。

どちらでもOKになりやすいケース

• WordPress（ブログ・企業サイト）
• 小〜中規模の会員サイト
• 一般的なプラグイン中心の運用

確認したいケース（差が出やすい）

• アプリ開発で 特定のバージョンや機能が必要
• 既存サイト移行で、旧環境と 文字コード／照合順序を揃えたい
• 特定ツールが「MySQL◯系推奨」など明記している

初心者が見るべき優先順位

1. バージョンが新しめか（古すぎないか）
2. utf8mb4対応か（文字化け事故を避ける）
3. バックアップと復元が現実的か（DB種類より大事）

自宅PCなど外部端末からDBに接続できる？

可能かどうかはサーバーによります。結論はこうです。

• 許可しているサーバー：外部接続（リモート接続）できる
• 制限しているサーバー：セキュリティのため外部接続不可（管理画面のみ）

外部接続ができる場合でも、運用は慎重にするのが鉄則です。

安全に運用するための条件 ✅

• 接続元IPを限定できる（IP制限が理想）
• 強いパスワード、不要ユーザーの削除
• 権限は最小化（管理者権限を常用しない）
• 使わないときは接続を閉じる（常時開放しない）

初心者のおすすめ

• 外部接続が“必須”でないなら、まずは 管理画面（phpMyAdminなど）で十分です。

“無制限”なら本当に上限ゼロなの？

上限ゼロ、ではないことがほとんどです。
「無制限」は、たいてい “特定項目が無制限（または非常に多い）” という意味です。

無制限と書かれやすい項目（数系）

• DB作成数
• テーブル数
• レコード数

実際に上限が出やすい項目（現実の天井）

• 1DBあたりの容量
• サーバー全体のストレージ（DB・ファイル・メールが共有）
• inode（ファイル数）
• 同時接続・クエリ負荷・CPU/IOなどのリソース

覚え方

• “作れる”＝無制限でも
• “溜められる／動かせる”は別制限で止まることがある

無料で使えるMySQL環境はある？

あります。学習や検証に便利です。
ただし無料は「試用向け」と割り切るのが安全です。

無料枠で起きがちな制約

• 広告表示
• 停止・制限のリスク（SLAが弱い）
• DB容量や作成数が小さめ
• 自動バックアップが弱い／復元が自力になりやすい
• サポートが限定的

使い方のおすすめ

• まず無料で「DBが触れる」「WordPressが動く」を試す
• 本番運用は、バックアップや復元が整った 有料プランに移行する

DBを削除したら復元できる？

原則、できない前提で考えるのが安全です。
DBは「ゴミ箱」みたいな仕組みがないことが多く、削除＝即消去になりがちです。

復元できるかどうかは、結局

• 自動バックアップがあるか
• どれくらいの期間（世代）残るか
• 復元ができる範囲（DBだけ／全体）
• 復元の方法（管理画面／依頼／自力）

次第です。

初心者向けの現実的なルール ✅

• DBを触る前に、必ず エクスポート（SQLダンプ）を手元に残す
• 重要作業前後は、世代を分けて保存（上書きしない）

サイト数が増えるとDBはどう増える？（WordPress運用の目安）

基本はこう考えると分かりやすいです。

• WordPressサイト1つにつき、通常 DBは1つ（1サイト＝1DBが基本）
• ただし運用が増えると、DBは“サイト数以上”に増えます

DBが増える典型パターン

• 本番サイト：1DB
• ステージング（更新前チェック）：+1DB
• 検証サイト（テーマ・プラグイン試験）：+1DB
• 移行作業用（引っ越し途中の仮）：+1DB
• 外注・チーム用の安全な作業環境：+α

つまり、

• 3サイト運営でも、状況によっては 6〜10DBくらいになることがあります。

“無制限”が効いてくるのはこんな人

• 複数サイトを回す（ブログ運営者・アフィリエイト運用）
• 事故を避けるために検証環境を作る
• 引っ越しやリライト、機能追加を頻繁に行う

まとめ：MySQL無制限で後悔しない結論

優先すべきは「DB数」より「容量・復元・安定性」

「MySQL無制限」という言葉は魅力的ですが、実務で困りやすいのは “DBが作れない”より“DBが守れない／重くて動かない” ほうです。

初心者が後悔しないために、優先順位を整理するとこうなります。

• 容量：DB単体・サーバー全体（ストレージ）・inode（ファイル数）の“天井”
• 復元：バックアップがあるかより、「DBだけ戻せるか」「管理画面で戻せるか」
• 安定性：アクセス増・同時接続・重い処理に耐えられるか（負荷制限の設計）

つまり、「DB数は多いけど、復元が弱い」より、
「DB数は十分で、復元と安定性が強い」ほうが長期的に安心です。

“無制限”を現実的に捉える合言葉

• 無制限＝上限ゼロではない（規約・負荷・ストレージで止まる）
• 増やせる（作成数）より、戻せる（復元）が重要
• 伸びたときに詰まるのは「DB数」より負荷・容量・運用事故

最低限ここだけ見ればOKの3点セット

比較・契約前に、次の3つを言葉で説明できる状態にすると失敗が減ります。

1. DBの上限の種類
   • DB作成数の単位（アカウント単位／ドメイン単位）
   • 1DB容量／総ストレージ／inodeの制限の有無
2. バックアップと復元の現実性
   • 自動バックアップの頻度・保存期間
   • 復元単位（DBだけ／全体）
   • 復元方法（管理画面／依頼／自力）と費用
3. 高負荷時の扱い
   • 大量アクセス・大量書き込み・重いクエリが来たときにどうなるか
   • フェアユースや禁止事項にどこまで書いてあるか

迷ったときの選び方（用途別の最短ルート）

「結局どれを選ぶべき？」となったら、まずは運用の未来を3タイプに分けると早いです。
（“今”だけでなく、“増えた後”を想定するのがコツです）

ルート1：WordPress中心で1〜2サイトを堅実に運用したい

最短ルートはこれです。

• 復元が簡単（できれば管理画面でDB復元）
• 自動バックアップが標準
• サポートとマニュアルが充実

このタイプは、DB数が無制限でも使い切らないことが多いので、「戻せる安心」＞「作成数の多さ」で選ぶのが正解になりやすいです。

やること（迷ったら）

• まず「自動バックアップの保存期間」と「DBだけ復元できるか」を見て、候補を半分に絞る

ルート2：複数サイト運用・検証環境込みでDBが増えがち

このタイプは、DB数の余裕が“効きやすい”です。
ただし、増やすほど事故率も上がるので、次を重視すると安定します。

• DB作成数だけでなく、管理しやすさ（命名・権限・画面の分かりやすさ）
• 移行のしやすさ（エクスポート／インポートの上限、ツールの使いやすさ）
• バックアップを「自動＋手動（外部保管）」で二重化できるか

やること（迷ったら）

• 「本番・検証・移行用」を分ける前提で、DBを3〜5個使う想定で仕様をチェックする
• そして 復元が重い（申請が必要／有料／全体復元のみ） なら候補から外す

ルート3：法人運用・会員制・ECなど“書き込みが多い”ビジネス用途

ここで重要なのは、DB数よりも “高負荷時に落ちない設計”です。

• 大量アクセスに対する方針（制限・迂回策・復旧フロー）
• WAFや権限分離などのセキュリティ基盤
• 障害情報の公開、サポート窓口、復旧の範囲
• 必要なら、共用サーバーだけでなく VPS／マネージドDB も視野に入れる

やること（迷ったら）

• 規約で「大量アクセス」「大量書き込み」「継続的高負荷」の扱いを確認
• さらに、バックアップが“ある”ではなく 復元手順が現実的かで選ぶ

最後に：決めきれない人のための結論

迷ったら、選択基準をこう固定するとブレません。

• いちばん大事：復元が簡単なこと（できればDB単位で）
• 次に大事：容量の天井が読みやすいこと（1DB／総ストレージ／inode）
• 最後に見る：DB作成数（無制限か、十分に多いか）

そして、運用で差がつくのはここです。

• バックアップが取れているかではなく、戻せるかを一度試したことがあるか
  → これだけで、事故が起きた時のダメージが激減します。

---

そして、最後に一番重要な実務の話です。
どんなに“無制限”と書かれていても、バックアップを取っていなければ、事故は取り返せません。
逆に言えば、バックアップを取り、復元を一度でも試しておけば、多くのトラブルは「慌てずに戻す」だけで被害を最小化できます。

「無制限」という言葉に振り回されず、
容量・復元・安定性の3点セットで、あなたの用途に合うサーバーを選んでください。