MariaDBテーブル一覧から不要テーブルを特定し安全に削除する手順|DROP前の依存確認

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOME > Linux技術 リナックスマスター.JP(Linuxマスター.JP) > Linuxtips > データーベース管理 > MariaDBテーブル一覧から不要テーブルを特定し安全に削除する手順|DROP前の依存確認
「このMariaDBサーバー、どんなテーブルが残っているのか誰も把握していない。」
前任者から引き継いだデータベース環境、あるいは長期間稼働させてきた開発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でバックアップを必ず取ること


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

テーブル一覧を確認する前の準備

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)

3つの確認すべてでEmpty setが返れば、依存関係はゼロです。削除に進んで問題ありません。

安全にテーブルを削除する手順

依存関係がないことを確認できたら、削除前にバックアップを取ってから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

バックアップが取れたことを確認してから次に進みます。体系的なバックアップ運用と復旧手順を学びたい方はLinux Master Pro Seminarでも丁寧に解説しています。

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)

2テーブルが正常に削除されました。

よくあるエラーと対処法

「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のセルフホスト運用(バックアップ・レプリケーション・チューニング)から、本番サーバーのセキュリティ設定まで、実機ハンズオンで体得できるセミナーを開催しています。

>> Linux Master Pro Seminar の詳細を見る

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。