はじめに
この記事はUdon Advent Calendar 2025 - Adventarの8日目の記事です。
データベース内のデータ
以前の記事で自宅に建てたデータベースとDiscord Botを連携させ、スクレイピング結果がデータベースに保存されるようにしました。
しばらくBotを動かしているとそれなりのレコードがデータベースに蓄積してくるのですが、実際にこれらのデータの量がどれくらいなのかを調べるということがしたいときがよくあります。
なので、その方法を調べてみました。
データベースのサイズを確認
まずはデータベースごとにサイズを見てみましょう。以下のSQLを実行します。
SELECT
table_schema, sum(data_length+index_length) /1024 /1024 AS MB
FROM
information_schema.tables
GROUP BY
table_schema
ORDER BY
sum(data_length+index_length) DESC;
table_schemaは各データベースの名前、sum(data_length+index_length)というのがそれぞれのデータベース内のデータとインデックスのサイズの合計(バイト単位)です。それを1024^2で割る事でMBにしています。単位を変えたい場合は1024で割る回数を変えると良さそうです。
information_schema.tablesというのは各テーブルの情報が入ったテーブルですね。そこから上述のデータを取り出し、table_schemaごとにデータ量の降順で集計しているわけです。
実行すると以下のような感じになります。自分の環境での実行結果なので、一応データベース名は仮名としてあります。
+--------------------+------------+
| TABLE_SCHEMA | MB |
+--------------------+------------+
| mysql | 2.60937500 |
| db_1 | 2.10937500 |
| db_2 | 0.10937500 |
| db_3 | 0.09375000 |
| db_4 | 0.01562500 |
| db_5 | 0.01562500 |
| db_6 | 0.01562500 |
| sys | 0.01562500 |
| information_schema | 0.00000000 |
| performance_schema | 0.00000000 |
+--------------------+------------+
10 rows in set (0.24 sec)
やってみると、意外とデータ量が小さいことが分かりました。とりあえずすぐにはストレージが枯渇することはなさそうです。
テーブルごとにサイズを確認
今度はデータベース内のテーブルごとの集計をしてみます。上で一番容量が大きかったdb1に対してやってみましょう。
SQLは以下の通りです。
SELECT
table_name, engine, table_rows, avg_row_length,
floor((data_length+index_length)/1024) AS all_kb,
floor((data_length)/1024) AS data_kb,
floor((index_length)/1024) AS index_kb
FROM
information_schema.tables
WHERE
table_schema=database()
ORDER BY
(data_length+index_length) DESC;
テーブル名、使ってるエンジン、レコード数、1レコードあたりのデータ量(バイト)、テーブル内の総容量、データ量、インデックス容量を集計します。
情報の取得元は先ほどと同様にinformation_schema.tablesですが、table_schema=database()で現在のデータベース内のテーブルを集計したいということを指定しています。
また、今回もデータ量の降順で集計します。
実行すると以下のようになりました。テーブル名は仮名です。
+--------------------+--------+------------+----------------+--------+---------+----------+
| TABLE_NAME | ENGINE | TABLE_ROWS | AVG_ROW_LENGTH | all_kb | data_kb | index_kb |
+--------------------+--------+------------+----------------+--------+---------+----------+
| table_1 | InnoDB | 5323 | 298 | 1552 | 1552 | 0 |
| table_2 | InnoDB | 1663 | 325 | 528 | 528 | 0 |
| table_3 | InnoDB | 58 | 282 | 16 | 16 | 0 |
| table_4 | InnoDB | 37 | 442 | 16 | 16 | 0 |
| table_5 | InnoDB | 30 | 546 | 16 | 16 | 0 |
| table_6 | InnoDB | 75 | 218 | 16 | 16 | 0 |
| table_7 | InnoDB | 30 | 546 | 16 | 16 | 0 |
+--------------------+--------+------------+----------------+--------+---------+----------+
7 rows in set (0.07 sec)
レコード数の多いテーブルほど多くのデータを持っているということが分かりましたが、1レコードあたりのデータ量は結構ばらつきがあるようです。
総容量がデータ量に等しくなっているので、全くインデックスを張っていない素人設定だということも一目瞭然です()。
おわりに
割と簡単にデータベース内のデータ量を計測できることが分かりました。
データが多くて記憶媒体がパンクしないかな、と気になる場合はたまにこれらのSQLを実行してチェックすると良さそうです。
また、このSQLを定期実行して統計を記録したりというのも面白いかもしれませんね。今度これをやってみたいなと思います。
それではまた、明日の記事でお会いしましょう。