前任者から引き継いだデータベース環境、あるいは長期間稼働させてきた開発DBで、こういった状況はよく起きます。誰が何のために作ったかわからないテーブルが積み重なっていくのです。
放置されたテストテーブルや移行後の残骸テーブルは、バックアップサイズを無駄に増やし、スキーマ把握を困難にします。かといってむやみにDROPすれば、外部キーやビューが参照していたときに本番アプリが壊れかねません。
この記事では、MariaDBのテーブル一覧を取得してから不要テーブルを安全に削除するまでの手順を解説します。
SHOW TABLESとINFORMATION_SCHEMAの活用方法、外部キー・ビュー・トリガーの依存関係確認、DROP TABLE実行前のバックアップまでカバーします。Rocky Linux 9.4 / Ubuntu 24.04 LTS のMariaDB 10.11 LTSで動作確認済みです。この記事のポイント
・SHOW TABLESとSHOW TABLE STATUSで一覧と行数・サイズを確認できる
・INFORMATION_SCHEMA.KEY_COLUMN_USAGEで外部キー参照を事前に洗い出す
・ビュー・トリガー・ストアドプロシージャの依存確認も必須
・DROP TABLE前にmariadb-dumpでバックアップを必ず取ること
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
テーブル一覧を確認する前の準備
MariaDBでテーブルを操作する前に、作業対象のデータベース名と現在の接続ユーザーの権限を確認しておきましょう。権限が不足しているとSHOW TABLESが空になったり、INFORMATION_SCHEMAのクエリで見えないテーブルが出たりします。複数のデータベースが混在するサーバーでは、どのデータベースを対象にするかを明確にしておかないと誤ったテーブルを削除してしまうリスクがあります。作業前に確認すべき項目は次のとおりです。
・現在接続しているユーザー:
SELECT CURRENT_USER(); で確認する・対象データベース名:
SHOW DATABASES; で一覧を把握する・権限の確認:
SHOW GRANTS FOR CURRENT_USER(); でSELECT・DROP権限を確認する・バックアップの取得:削除前に必ずmariadb-dumpで対象DBをバックアップする
SHOW TABLESでテーブル一覧を確認する
1. MariaDBへ接続する
mariadbコマンドでサーバーへ接続します。ホスト名・ユーザー名・データベース名は環境に合わせて変更してください。# ローカルサーバーへ接続する場合 mariadb -u webapp_user -p webapp_db # または mysql コマンドでも可(互換エイリアス) mysql -u webapp_user -p webapp_db
2. SHOW TABLESでテーブル一覧を表示する
接続後、最もシンプルにテーブル一覧を取得するのがSHOW TABLES;です。MariaDB [webapp_db]> SHOW TABLES; +-----------------------------+ | Tables_in_webapp_db | +-----------------------------+ | bk_users_old | | comments | | migrations | | order_items | | orders | | posts | | sessions | | temp_import_2024 | | users | +-----------------------------+ 9 rows in set (0.001 sec)
bk_users_oldやtemp_import_2024のように、明らかに一時的・移行目的で作られたと思われるテーブルが見えます。ただし名前だけで判断してDROPするのは危険です。続いてサイズと更新日時を確認します。3. SHOW TABLE STATUSで行数・サイズ・最終更新日を確認する
SHOW TABLE STATUS;を実行すると、各テーブルの行数・データサイズ・最終更新日時などを一覧で取得できます。MariaDB [webapp_db]> SHOW TABLE STATUS\G *************************** 1. row *************************** Name: bk_users_old Engine: InnoDB Version: 10 Row_format: Dynamic Rows: 4821 Avg_row_length: 312 Data_length: 1507328 Max_data_length: 0 Index_length: 557056 Data_free: 0 Auto_increment: NULL Create_time: 2023-11-14 09:22:11 Update_time: 2023-11-14 09:22:11 Check_time: NULL Collation: utf8mb4_general_ci ... *************************** 8. row *************************** Name: temp_import_2024 Engine: InnoDB Version: 10 Row_format: Dynamic Rows: 0 Avg_row_length: 0 Data_length: 16384 Max_data_length: 0 Index_length: 0 Data_free: 0 Auto_increment: NULL Create_time: 2024-03-07 14:55:03 Update_time: NULL Check_time: NULL Collation: utf8mb4_general_ci
・bk_users_old:2023年11月14日以降更新なし。旧バックアップテーブルと推測できる
・temp_import_2024:行数0。インポート処理用に作られたと思われる空テーブル
これらが削除候補として浮かび上がります。ただし最終更新日時が古いからといって即座にDROPするのは早計です。次のセクションで依存関係を必ず確認してください。
INFORMATION_SCHEMAで全テーブルを一括棚卸しする
複数のデータベースにまたがって棚卸しをしたい場合や、各テーブルの行数・サイズをSQL形式で取り出したい場合は、INFORMATION_SCHEMAを直接クエリします。-- データベース内の全テーブルを行数・サイズ付きで一覧表示する SELECT TABLE_NAME, TABLE_ROWS, ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) AS size_mb, CREATE_TIME, UPDATE_TIME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'webapp_db' ORDER BY size_mb DESC; +------------------+------------+---------+---------------------+---------------------+ | TABLE_NAME | TABLE_ROWS | size_mb | CREATE_TIME | UPDATE_TIME | +------------------+------------+---------+---------------------+---------------------+ | orders | 182431 | 48.64 | 2022-06-01 08:00:00 | 2026-10-12 23:55:01 | | order_items | 754820 | 34.22 | 2022-06-01 08:00:00 | 2026-10-12 23:55:01 | | posts | 28904 | 12.80 | 2022-06-01 08:00:00 | 2026-10-12 23:48:33 | | users | 15322 | 8.41 | 2022-06-01 08:00:00 | 2026-10-12 23:59:05 | | bk_users_old | 4821 | 1.97 | 2023-11-14 09:22:11 | 2023-11-14 09:22:11 | | sessions | 91204 | 1.44 | 2022-06-01 08:00:00 | 2026-10-12 23:59:07 | | comments | 62118 | 1.22 | 2022-06-01 08:00:00 | 2026-10-12 22:10:55 | | migrations | 47 | 0.03 | 2022-06-01 08:00:00 | 2026-09-30 11:00:00 | | temp_import_2024 | 0 | 0.02 | 2024-03-07 14:55:03 | NULL | +------------------+------------+---------+---------------------+---------------------+
bk_users_oldとtemp_import_2024を削除候補として、次の依存関係確認に進みます。DROP TABLE前の依存関係確認
ここが最も重要な工程です。テーブルを削除する前に、他のテーブルやオブジェクトから参照されていないかを確認してください。依存関係を確認せずにDROPすると、アプリケーションエラーや外部キー制約違反を引き起こします。1. 外部キー(FOREIGN KEY)参照をINFORMATION_SCHEMAで確認する
削除対象テーブルが他のテーブルから外部キーで参照されていないかを確認します。-- bk_users_old を参照している外部キーがあるか確認する SELECT CONSTRAINT_NAME, TABLE_NAME AS 参照元テーブル, COLUMN_NAME AS 参照元カラム, REFERENCED_TABLE_NAME AS 参照先テーブル, REFERENCED_COLUMN_NAME AS 参照先カラム FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_SCHEMA = 'webapp_db' AND REFERENCED_TABLE_NAME = 'bk_users_old'; Empty set (0.001 sec)
Empty setが返ればこのテーブルを参照している外部キーは存在しません。temp_import_2024も同じクエリで確認します(REFERENCED_TABLE_NAMEを差し替えるだけです)。逆に、削除対象テーブル自体が持っている外部キー(他テーブルへの参照)も確認します。
-- bk_users_old が参照先として持っている外部キーを確認する SELECT CONSTRAINT_NAME, COLUMN_NAME, REFERENCED_TABLE_NAME, REFERENCED_COLUMN_NAME FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA = 'webapp_db' AND TABLE_NAME = 'bk_users_old' AND REFERENCED_TABLE_NAME IS NOT NULL; Empty set (0.001 sec)
2. ビュー(VIEW)の参照を確認する
ビューが削除対象テーブルを参照していると、ビューを通じたSELECTがエラーになります。-- bk_users_old を参照しているビューを確認する SELECT TABLE_NAME AS view_name, VIEW_DEFINITION FROM INFORMATION_SCHEMA.VIEWS WHERE TABLE_SCHEMA = 'webapp_db' AND VIEW_DEFINITION LIKE '%bk_users_old%'; Empty set (0.001 sec)
3. トリガーとストアドプロシージャの確認
トリガーやストアドプロシージャが削除対象テーブルを内部で参照している場合があります。-- トリガーの確認 SELECT TRIGGER_NAME, EVENT_MANIPULATION, ACTION_STATEMENT FROM INFORMATION_SCHEMA.TRIGGERS WHERE TRIGGER_SCHEMA = 'webapp_db' AND ACTION_STATEMENT LIKE '%bk_users_old%'; Empty set (0.001 sec) -- ストアドプロシージャ・ファンクションの確認 SELECT ROUTINE_NAME, ROUTINE_TYPE, ROUTINE_DEFINITION FROM INFORMATION_SCHEMA.ROUTINES WHERE ROUTINE_SCHEMA = 'webapp_db' AND ROUTINE_DEFINITION LIKE '%bk_users_old%'; Empty set (0.001 sec)
安全にテーブルを削除する手順
依存関係がないことを確認できたら、削除前にバックアップを取ってからDROPします。1. 削除前にバックアップを取得する
MariaDBのセルフホスト運用では、本番作業前のバックアップは必須です。mariadb-dumpコマンド(旧mysqldump)で対象テーブルを個別にバックアップします。# bk_users_old テーブルをバックアップする mariadb-dump -u webapp_user -p webapp_db bk_users_old \ > /var/backup/mariadb/bk_users_old_$(date +%Y%m%d).sql # temp_import_2024 テーブルをバックアップする mariadb-dump -u webapp_user -p webapp_db temp_import_2024 \ > /var/backup/mariadb/temp_import_2024_$(date +%Y%m%d).sql # バックアップファイルを確認する ls -lh /var/backup/mariadb/ -rw-r--r-- 1 root root 2.1M Oct 13 10:22 bk_users_old_20261013.sql -rw-r--r-- 1 root root 1.4K Oct 13 10:22 temp_import_2024_20261013.sql
2. DROP TABLE IF EXISTSで削除する
DROP TABLE IF EXISTSを使うと、対象テーブルが存在しない場合でもエラーにならず安全です。複数テーブルを一度に削除するときはカンマ区切りで指定します。MariaDB [webapp_db]> DROP TABLE IF EXISTS bk_users_old, temp_import_2024; Query OK, 0 rows affected (0.052 sec) -- 削除後に一覧を確認する MariaDB [webapp_db]> SHOW TABLES; +-----------------------------+ | Tables_in_webapp_db | +-----------------------------+ | comments | | migrations | | order_items | | orders | | posts | | sessions | | users | +-----------------------------+ 7 rows in set (0.001 sec)
よくあるエラーと対処法
「Cannot delete or update a parent row: a foreign key constraint fails」が出た場合
外部キー制約の確認が不十分で、他テーブルから参照されているテーブルをDROPしようとすると以下のエラーが出ます。ERROR 1217 (23000): Cannot delete or update a parent row: a foreign key constraint fails
・手順1:INFORMATION_SCHEMA.KEY_COLUMN_USAGEで参照元テーブルを特定する
・手順2:参照元テーブルの外部キー制約を先に削除する(
ALTER TABLE 参照元テーブル DROP FOREIGN KEY 制約名;)・手順3:または、削除対象テーブル自体が本当に不要かをアプリチームに確認する
・手順4:依存関係を解消してからDROPを再実行する
「View 'webapp_db.v_user_summary' references invalid table」が出た場合
ビューが参照していたテーブルを削除したあとにビューを実行すると発生します。事前のVIEWS確認を必ず行ってください。もし誤って削除してしまった場合は、バックアップからリストアしてビューの整合性を回復します。# バックアップからリストアする mariadb -u root -p webapp_db < /var/backup/mariadb/bk_users_old_20261013.sql
本記事のまとめ
MariaDBのテーブル一覧の確認から安全な削除までの手順をまとめます。| やりたいこと | コマンド・クエリ |
|---|---|
| テーブル一覧を表示する | SHOW TABLES; |
| 行数・サイズ・更新日を確認する | SHOW TABLE STATUS; |
| 全テーブルをSQL形式で棚卸し | SELECT ... FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'DB名'; |
| 外部キー参照を確認する | SELECT ... FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE WHERE REFERENCED_TABLE_NAME = 'テーブル名'; |
| ビューの参照を確認する | SELECT ... FROM INFORMATION_SCHEMA.VIEWS WHERE VIEW_DEFINITION LIKE '%テーブル名%'; |
| トリガーの参照を確認する | SELECT ... FROM INFORMATION_SCHEMA.TRIGGERS WHERE ACTION_STATEMENT LIKE '%テーブル名%'; |
| テーブルをバックアップする | mariadb-dump -u ユーザー -p DB名 テーブル名 > バックアップ.sql |
| テーブルを安全に削除する | DROP TABLE IF EXISTS テーブル名; |
MariaDBの不要テーブル削除で最も重要なのは「依存関係の確認」です。INFORMATION_SCHEMAを使えば外部キー・ビュー・トリガー・ストアドプロシージャの参照をすべてSQLで確認できます。確認が終わったら、バックアップを取得してから
DROP TABLE IF EXISTSを実行するという流れを徹底してください。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、
MariaDB/MySQLのセルフホスト運用(バックアップ・レプリケーション・チューニング)から、本番サーバーのセキュリティ設定まで、実機ハンズオンで体得できるセミナーを開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら
- 前のページへ:MariaDBユーザー一覧からゾンビアカウントを洗い出す|last_passwordなど拡張カラム活用
- この記事の属するカテゴリ:データーベース管理へ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます