データベース管理者（DBA）やバックエンドエンジニアとして働いていると、開発中や運用中に「現在のデータベースに存在するテーブルの一覧を知りたい」「特定のカラムを持つテーブルはどれか」「テーブルごとの行数やサイズを迅速に把握したい」という場面に頻繁に遭遇します。
特に大規模なシステムや、複数のマイクロサービスが絡み合う環境では、ドキュメントが常に最新であるとは限りません。このような状況で最も信頼できる唯一の情報源（Single Source of Truth）は、データベース自身が保持しているメタデータです。今回は、PostgreSQLやMySQLといった主要なRDBMSにおいて、実務で即戦力となるテーブル情報の取得テクニックを解説します。
なぜメタデータの直接クエリが必要なのか
GUIツール（DBeaverやpgAdmin、MySQL Workbenchなど）を使えば、マウス操作でテーブルの一覧を見ることは可能です。しかし、実務において以下のような要件が発生したとき、GUIでの手動操作は限界を迎えます。
1. 数百あるテーブルの中から、特定のカラム名を含むテーブルを全て抽出したい。
2. 運用保守のタスクとして、データベース全体のテーブル数や各テーブルのレコード数を定期的にレポート化したい。
3. スキーマ変更の履歴を追跡するために、DDLの断片を自動的に収集したい。
これらのタスクを自動化し、スクリプトやCI/CDパイプラインに組み込むためには、システムカタログや情報スキーマ（INFORMATION_SCHEMA）を直接照会するスキルが不可欠です。
PostgreSQLにおける情報取得の要：information_schemaとpg_catalog
PostgreSQLでは、標準的なinformation_schemaと、PostgreSQL固有のシステムカタログであるpg_catalogの両方を活用します。
まず、基本的なテーブル一覧を取得するクエリです。
— ユーザー定義のテーブルのみを取得する
SELECT table_name
FROM information_schema.tables
WHERE table_schema = ‘public’
ORDER BY table_name;
これだけではテーブル名しか分かりません。実務では「テーブルのサイズ」や「行数」も重要になります。特にテーブルサイズは容量監視の観点から必須です。
— テーブルのサイズと行数の見積もりを取得する
SELECT
relname AS table_name,
n_live_tup AS estimated_row_count,
pg_size_pretty(pg_total_relation_size(relid)) AS total_size
FROM pg_stat_user_tables
ORDER BY pg_total_relation_size(relid) DESC;
このクエリでは、pg_stat_user_tablesという統計情報ビューを活用しています。n_live_tupは統計情報に基づく見積もり値ですが、高速に取得できるため、定期的な監視スクリプトには最適です。
MySQLにおける情報取得：INFORMATION_SCHEMAの活用
MySQLにおいても、INFORMATION_SCHEMAが情報の宝庫です。特にtablesテーブルとcolumnsテーブルは頻繁に使用します。
例えば、特定のカラム名「user_id」が含まれているテーブルを全データベースから検索したい場合は、以下のように記述します。
— 特定のカラム名を持つテーブルを検索する
SELECT
table_schema,
table_name
FROM information_schema.columns
WHERE column_name = ‘user_id’
ORDER BY table_schema, table_name;
また、MySQLではテーブルの行数やデータサイズを確認するために以下のようなクエリが一般的です。
— テーブルの行数とデータサイズを確認する
SELECT
table_name,
table_rows,
data_length / 1024 / 1024 AS data_size_mb,
index_length / 1024 / 1024 AS index_size_mb
FROM information_schema.tables
WHERE table_schema = ‘your_database_name’
ORDER BY data_length DESC;
ここで注意が必要なのは、MySQLのtable_rowsはストレージエンジン（InnoDBなど）によっては「概算値」であるという点です。正確な行数が必要な場合はCOUNT()を発行する必要がありますが、運用監視レベルであればこの情報で十分なケースが大半です。
メタデータ取得を応用した実務テクニック
単に情報を取得するだけでなく、これらを組み合わせて「テーブルの設計書」を自動生成したり、移行作業のためのスクリプトを構築したりすることが可能です。
例えば、特定のスキーマにある全テーブルのカラム定義をCSV形式で出力したい場合、以下のようなSQLを構築します。
— カラム定義をCSV出力用に整形する
SELECT
table_name,
column_name,
data_type,
is_nullable,
column_default
FROM information_schema.columns
WHERE table_schema = ‘public’
ORDER BY table_name, ordinal_position;
この結果をpsqlコマンドやmysqlコマンドのオプションでファイルに書き出せば、簡易的なデータ辞書が完成します。
psql -d my_db -t -A -F ‘,’ -c “SELECT … FROM …” > schema_report.csv
このように、SQLの結果を外部コマンドと組み合わせることで、DBAとしての作業効率は劇的に向上します。
インデックス情報の取得とパフォーマンス管理
テーブルそのものの情報だけでなく、インデックスの情報もパフォーマンスチューニングにおいて極めて重要です。使われていないインデックス（Unused Indexes）を特定することは、書き込み性能の向上やディスク容量の節約に直結します。
PostgreSQLの場合、pg_stat_user_indexesを調べることで、インデックスがどれだけ利用されているかを判定できます。
— インデックスの利用状況を確認する
SELECT
relname AS table_name,
indexrelname AS index_name,
idx_scan AS number_of_scans
FROM pg_stat_user_indexes
WHERE idx_scan = 0
AND indexrelname NOT LIKE ‘%_pkey’ — 主キーは除外
ORDER BY relname;
このようなクエリを定期的に実行し、idx_scanが長期間0のままのインデックスを見つけ出し、削除候補としてリストアップする運用フローは、大規模データベースの健全性を保つための「定石」です。
DBAとして知っておくべき注意点
最後に、メタデータクエリを実行する際の注意点をいくつか挙げます。
1. ロックと負荷：INFORMATION_SCHEMAへのクエリは通常、ロックを必要としませんが、統計情報が非常に大きい場合や、頻繁に更新されるデータベースで複雑なJOINを行うと、一時的にCPU負荷が高まる可能性があります。ピークタイムを避けて実行するのが賢明です。
2. 権限管理：システムカタログへのアクセス権限は、環境によっては制限されている場合があります。読み取り専用の監視用ユーザーを作成し、必要な権限を最小限に付与して運用することをお勧めします。
3. 統計情報の鮮度：特にMySQLのtable_rowsやPostgreSQLの統計情報は、ANALYZEコマンドが実行された時点での情報です。データの増減が激しいテーブルでは、表示されている値が最新ではない可能性があることを常に意識してください。
まとめ：メタデータはデータベースの羅針盤
データベースのメタデータを自在に操る力は、トラブルシューティングのスピードを上げ、設計の不備を早期に発見し、運用コストを削減するための強力な武器になります。
今回紹介したクエリは、いずれも基本的なものですが、これらをベースに自分の環境に合わせて条件を組み合わせることで、より高度な分析が可能になります。例えば「特定の命名規則に従っていないテーブルを抽出する」「過去1週間でサイズが急激に増加したテーブルを特定する」といった応用も難しくありません。
GUIツールに頼り切るのではなく、SQLという共通言語でデータベースの内部情報を直接読み解く習慣をつけましょう。それこそが、プロフェッショナルなDBAへの第一歩です。日々の運用業務の中で、ぜひこれらのクエリを試し、自身の環境における「データベースの地図」を広げてみてください。
コメント