2026年6月28日

MySQLのデータ容量確認とディスク管理｜サイズの調べ方と容量を減らす方法

データベースサーバー

MySQL のディスク使用量は、テーブルのデータだけでなく、バイナリログ、InnoDB のシステムテーブルスペース、各種ログなど、SQL からは見えにくいファイルの合計で決まります。容量を正しく管理するには、SQL で見えるサイズとディスク上の実際のファイルの両方を確認し、増えている原因に合った方法で減らすことが大切です。この記事では、データベースとテーブルごとのサイズの調べ方、データディレクトリの中身の見方、バイナリログや不要データを安全に減らす方法、そして容量不足を防ぐ監視の考え方を説明します。

なお、すでにディスクが満杯でサイトが止まっている場合は、まず不要なログなど MySQL 以外のファイルで空きを作り、サービスを復旧させることを優先してください。この記事は、日常的な容量確認と予防の手順を中心にしています。

データベースごとのサイズを確認する

まずは information_schema を使って、データベースごとの使用量を確認します。

SELECT table_schema AS db,
       ROUND(SUM(data_length + index_length) / 1024 / 1024, 1) AS size_mb,
       ROUND(SUM(data_free) / 1024 / 1024, 1) AS free_mb
FROM information_schema.TABLES
GROUP BY table_schema
ORDER BY size_mb DESC;

data_length はデータ本体、index_length はインデックスのサイズです。data_free は、行を削除した後などに生まれた、テーブル内で再利用できる空き領域の目安です。

ここで出る数値は概算です。InnoDB の統計情報は推定値をもとにしているうえ、MySQL 8.0 では information_schema の統計がキャッシュされる仕組み（information_schema_stats_expiry、既定は1日）になっており、大量に削除した直後でも古い値が表示されることがあります。最新の値を見たいときは、対象テーブルに ANALYZE TABLE を実行してから確認してください。

テーブルごとのサイズを確認する

どのデータベースが大きいか分かったら、テーブル単位で内訳を見ます。

SELECT table_name,
       engine,
       table_rows,
       ROUND(data_length  / 1024 / 1024, 1) AS data_mb,
       ROUND(index_length / 1024 / 1024, 1) AS index_mb,
       ROUND(data_free    / 1024 / 1024, 1) AS free_mb
FROM information_schema.TABLES
WHERE table_schema = 'your_database'
ORDER BY data_length + index_length DESC
LIMIT 20;

WordPress なら、WP-CLI の wp db size --tables でもテーブルごとのサイズを一覧できます。WordPress で大きくなりやすいのは次のようなテーブルです。

wp_posts と wp_postmeta：リビジョン（過去の版）が増え続けている
wp_options：期限切れのトランジェントや、アンインストール済みプラグインの設定が残っている
wp_comments と wp_commentmeta：スパムコメントがたまっている
プラグインが作るログ用のテーブル：アクセス記録、セキュリティログ、リダイレクトのログ、Action Scheduler のタスク履歴など

プラグインのログ用テーブルは、そのプラグインの設定画面に保存期間や削除の項目があることが多いので、まずはそちらを確認するのが安全です。

ディスク上のファイルを確認する

SQL で見えるサイズの合計と、ディスクの使用量が大きく違うことがあります。その差は、テーブル以外のファイルです。データディレクトリの場所を確認し、中身を見てください。

SELECT @@datadir;

# データディレクトリの場所は上の結果に合わせる
sudo du -sh /var/lib/mysql
sudo du -sh /var/lib/mysql/* | sort -h | tail -20
df -h
df -i

df -i は inode（ファイル数）の使用率です。容量に余裕があっても inode が尽きると新しいファイルを作れなくなります。

データディレクトリでよく見かける大きなファイルは次のとおりです。

各データベースのディレクトリ内の .ibd ファイル：innodb_file_per_table が有効（MySQL 5.6.6 以降の既定）の場合のテーブルごとのデータ
ibdata1：InnoDB のシステムテーブルスペース。一度大きくなると、通常の操作では小さくならない
binlog.000123 のようなファイル：バイナリログ。MySQL 8.0 では既定で有効になっている
relay-log で始まるファイル：レプリカ（スレーブ）側のリレーログ
undo_001 などの undo テーブルスペース、ibtmp1 などの一時テーブルスペース
スロークエリログ、一般ログ（general log）、エラーログ

特に一般ログは、すべてのクエリを記録するため短時間で巨大になります。調査のために一時的に有効にしたまま、戻し忘れていないか確認してください。

バイナリログを安全に減らす

バイナリログは、レプリケーションや、ある時点までのデータ復元（ポイントインタイムリカバリ）に使われる重要なファイルです。ファイルを rm で直接削除すると、MySQL が管理しているインデックスファイルとの整合性が崩れたり、レプリカが必要なログを読めなくなったりします。削除は SQL で行ってください。

-- 現在のバイナリログの一覧とサイズ
SHOW BINARY LOGS;

-- 7日より前のバイナリログを削除する
PURGE BINARY LOGS BEFORE NOW() - INTERVAL 7 DAY;

レプリカがある場合は、削除する前に各レプリカがどのログまで読み終えたかを確認し、未読のログを消さないようにします。また、バイナリログを使ってバックアップ後の変更を復元する運用をしている場合は、最新のフルバックアップより後のログを残しておく必要があります。

保持期間は自動で管理できます。MySQL 8.0 では binlog_expire_logs_seconds（既定は30日）を使い、古い expire_logs_days は非推奨です。MariaDB では expire_logs_days が使われており、新しいバージョンでは binlog_expire_logs_seconds も使えます（2026年10月現在）。

[mysqld]
# 7日分を保持する例（MySQL 8.0）
binlog_expire_logs_seconds = 604800

テーブルの空き領域をディスクに返す

大量の行を削除しても、InnoDB はファイルを自動では縮めません。空いた領域は同じテーブルの今後の書き込みに再利用されます。ディスクに返したい場合は、テーブルを作り直します。

OPTIMIZE TABLE wp_postmeta;

InnoDB では OPTIMIZE TABLE はテーブルの再作成として処理されます。作業中はテーブルと同じくらいの空き容量が一時的に必要になり、大きなテーブルでは時間もかかります。容量がぎりぎりの状態で実行すると、かえってディスクを使い切る危険があるため、空き容量を確認し、事前にバックアップを取り、アクセスの少ない時間帯に行ってください。

なお、この方法で縮むのはテーブルごとの .ibd ファイルです。ibdata1 を小さくするには、全データをダンプして作り直すといった大がかりな作業が必要になるため、通常は「これ以上増やさない」ことを目標にします。

WordPress で不要なデータを減らす

WordPress のデータを減らす作業は、元に戻せない操作が多いので、データベースのバックアップを取ってから行ってください。

# 期限切れのトランジェントを削除する
wp transient delete --expired

# リビジョンの件数を確認する（削除する前に、まず件数を把握する）
wp post list --post_type=revision --format=count

リビジョンをこれ以上増やしたくない場合は、wp-config.php に define( 'WP_POST_REVISIONS', 5 ); のように保存数の上限を設定できます。既存のリビジョンの削除や、データベースの最適化をまとめて行うプラグインもありますが、実行内容と対象を確認してから使ってください。

容量不足を防ぐ監視

ディスクが満杯になると、MySQL は書き込みができなくなり、テーブルやログの破損につながることもあります。手遅れになる前に気づけるよう、次のような監視を用意しておくと安心です。

ディスク使用率が一定（例として80%）を超えたら通知する
データベースごとのサイズを週1回などの間隔で記録し、増え方を把握する
バイナリログ、スロークエリログ、エラーログの保持期間とローテーションを設定する
バックアップファイルを同じディスクに置きっぱなしにしない

増え方が分かっていれば、「あと何か月で容量が足りなくなるか」を予測でき、ディスクの増設やデータの整理を計画的に行えます。

まとめ

information_schema でデータベースとテーブルごとのサイズを確認する。数値は概算で、MySQL 8.0 では統計がキャッシュされる
SQL のサイズとディスクの使用量の差は、バイナリログ、ibdata1、各種ログなどテーブル以外のファイル
バイナリログは rm ではなく PURGE BINARY LOGS と保持期間の設定で管理する。レプリカと復元用途に注意する
OPTIMIZE TABLE で .ibd を縮められるが、一時的に空き容量が必要。ibdata1 は通常縮まない
WordPress ではリビジョン、トランジェント、プラグインのログを見直し、ディスク使用率の監視を用意する