MySQL「Table is marked as crashed」エラーとphpMyAdminによるテーブル修復方法

MySQL「Table is marked as crashed」エラーは、主にMyISAMストレージエンジンを使用するテーブルが破損しており、MySQLが安全に読み取れない状態を示します。最も迅速な解決策は、データベースのバックアップを取得した後、phpMyAdminで該当テーブルを選択しテーブルの修復機能を実行することです。しかし、このエラーは単なる警告ではなく、サーバーの突然停止やディスク容量不足、不適切なクエリ、激しい書き込みトラフィック、古いMySQL構成などが原因で再発することもあります。本記事では、エラーの原因、phpMyAdminによる安全な修復手順、処理前のバックアップ確認、そして再発防止策を段階的に解説します。

あなたのサイトがWordPress、OpenCart、独自PHPアプリ、フォーラムソフトなどを使っている場合でも、MySQLテーブルが破損すると訪問者はホワイトスクリーン、500エラー、接続タイムアウト、管理画面での予期せぬデータベースエラーなど、さまざまな障害を目にすることがあります。特にECサイトでは、注文・商品・セッション・カートテーブルが影響を受けると数分の停止でも売上損失につながります。そのため、修復時にはデータ保護と原因究明の両方が重要です。信頼できるホスティング基盤、定期的なバックアップ、適切なデータベースエンジン選択はリスクを大幅に軽減します。管理しやすくモニタリング可能なインフラを求めるなら Hostragons ウェブホスティング、高負荷なプロジェクトには Hostragons VPSサーバー も検討できます。

Table is marked as crashed エラーとは？

Table is marked as crashed エラーは、MySQLサーバーがテーブルを破損状態として認識し、該当テーブルへの読み書きに問題が発生していることを示します。エラーメッセージは以下のような形で表示されます：Table './database/table_name' is marked as crashed and should be repaired や Incorrect key file for table など。これはテーブルファイルやインデックス、整合性に問題がある場合に出現します。

このエラーは主にMyISAMテーブルで頻発します。MyISAMは古く高速な読み込みに特化したストレージエンジンですが、クラッシュ時の復元能力はInnoDBほど強くありません。サーバーが突然停止したり、ディスク書き込みが途中で終了したり、MySQLサービスが正常に終了しない場合、MyISAMテーブルは容易に破損します。一方、InnoDBはトランザクションログやクラッシュリカバリ機能により堅牢ですが、InnoDBでもテーブルスペースやディスク、ログ、データディクショナリの問題で類似の障害が起きることがあります。

エラーの主な原因

phpMyAdminで修復するだけでは根本原因を特定できない場合、同じ問題が数時間・数日以内に再発することもあります。以下は現場でよく見られる主な原因です：

• サーバーの突然停止：停電やハードウェアリセット、OSクラッシュ時にMySQLが書き込み中だった場合、テーブルが破損することがあります。
• ディスク容量不足：MySQLが一時ファイルやインデックス、テーブル更新を書き込めないとデータ整合性が崩れます。ディスク使用率が90%を超えると危険です。
• MySQLサービスの強制終了：kill -9などの強制停止は、特に書き込み中のMyISAMテーブルにダメージを与えます。
• 激しい書き込みトラフィック：ログやカウンター、セッション、検索テーブルなど常時更新されるテーブルがMyISAMの場合、破損リスクが高まります。
• 不良なプラグインやテーマ：WordPress等では粗悪なプラグインが過剰なクエリを発行し、テーブルロックや破損を引き起こすことがあります。
• ハードウェアやファイルシステム障害：ディスクのバッドセクターやI/Oエラー、破損したファイルシステムがデータベースファイルに影響します。
• 古いMySQLバージョン：アップデートされていないバージョンではパフォーマンスやロック、復旧動作が弱い場合があります。

修復前の重要なセキュリティステップ

データベースの修復処理はほとんどの場合安全ですが、破損したテーブルで操作する際はデータ損失のリスクが完全にゼロではありません。特に本番環境（公開サイト）で作業する場合は、まずバックアップが最優先です。

1. 現在のデータベースをバックアップする

phpMyAdminで修復を始める前に、データベースのスナップショットをエクスポートしましょう。テーブルが破損していても、読み取れるデータはバックアップ可能です。phpMyAdminでデータベース選択後、エクスポートタブから、可能なら詳細設定でSQL形式を選択しバックアップを取得します。大規模データベースではタイムアウトすることもあるため、ホスティングのバックアップツールやSSHからのmysqldumpコマンドの方が確実です。バックアップポリシーがない場合は ホスティングバックアップソリューション で対策を検討しましょう。

2. 破損したテーブルを特定する

エラーメッセージには通常テーブル名が記載されています。例えばWordPressでは wp_options、wp_posts、wp_comments、wp_actionscheduler_actions などが該当することがあります。独自アプリではログやPHPエラー、MySQLエラーログなどからテーブル名を確認できます。対象テーブルを特定することで、無駄な操作を避けられます。

3. サイトを一時メンテナンスモードにする

修復中に新たな書き込みが発生すると処理が失敗したりデータ矛盾が起きる恐れがあります。アクセスの多いサイトでは2～5分間のメンテナンスモードが安全です。WordPressなら専用プラグイン、独自アプリなら簡易メンテページやWebサーバーのリダイレクトでユーザー操作を停止できます。安全な訪問者体験のため、メンテナンスページもSSL対応が望ましいです。SSL証明書に問題がある場合は SSL証明書 を検討してください。

phpMyAdminによるMySQLテーブルの修復手順

phpMyAdminはコマンドライン知識がないユーザーでも簡単にMySQLテーブルを修復できます。以下の手順は一般的なcPanelやPleskなどのホスティングパネルでも共通です。

ステップ1：ホスティングパネルからphpMyAdminにログイン

ホスティングコントロールパネルにログインし、データベースセクションでphpMyAdminリンクをクリックします。複数のホスティングアカウントやドメインを管理している場合、処理対象が正しいか注意しましょう。誤ったデータベースを操作すると直接ダメージはないものの、時間の無駄やテスト環境の修復につながることがあります。ドメインとホスティングの組み合わせが混乱している場合は ドメイン管理 も参考にしてください。

ステップ2：正しいデータベースを選択

左側メニューからサイトが使用しているデータベースを選びます。WordPressなら wp-config.php ファイルのDB_NAME行で確認できます。独自PHPプロジェクトではconfig.phpや.env、database.phpファイルなどに記載されています。同一サーバーに複数サイトがある場合、この確認は非常に重要です。

ステップ3：破損テーブルを選択

データベースを開くとテーブル一覧が表示されます。エラーメッセージに記載されたテーブルを探し、左側のチェックボックスを選択します。複数テーブルに同じエラーが出る場合は全て選択可能ですが、まずは最も重要なテーブルから始める方が安全です。テーブルがMyISAMか判断したい場合は、一覧のタイプやエンジン欄を確認しましょう。

ステップ4：テーブルの修復オプションを実行

テーブルを選択したら、ページ下部のプルダウンメニューからテーブルの修復を選びます。phpMyAdminは裏で REPAIR TABLE table_name コマンドを実行します。処理が完了すると成功・警告・失敗の結果が表示されます。成功なら status OK と表示されます。大きなテーブルでは数秒でなく数分かかることもあるので、完了までページを更新したりブラウザを閉じたりしないよう注意しましょう。

ステップ5：テーブルチェックとサイト動作確認

修復後、同じメニューからテーブルのチェックを実行できます。その後、サイトのトップページ・管理画面・検索機能・商品一覧・ログイン機能などをテストしましょう。WordPressなら管理画面でパーマリンクを再保存し、キャッシュクリアやエラーログ確認も良い習慣です。

phpMyAdminの修復関連オプションの意味

phpMyAdminには修復だけでなく、テーブルメンテナンス関連の様々な機能があります。各オプションの目的を理解し、誤用に注意しましょう。

まとめると、Table is marked as crashed エラーにはテーブルの修復が直接的な対処法です。最適化や分析は有益なメンテナンスですが、破損テーブルの復旧には単独では不十分です。

InnoDBテーブルの場合はどう違う？

phpMyAdminでInnoDBテーブルを修復する場合、テーブルの修復は期待通り動かないことが多いです。これはInnoDBがMyISAMのような単純なファイル修復の仕組みを採用していないためです。InnoDBはトランザクションログ、redo/undoログ、テーブルスペース構造でデータ整合性を守ります。そのため、InnoDB障害はMySQLログ確認やディスク状態チェック、バックアップからのリストア、高度なリカバリモード利用などが主な対策となります。

エラーがMyISAMテーブルの場合はphpMyAdmin修復が有効ですが、InnoDBで corrupt、tablespace、cannot open table などのメッセージが出る場合は、まずバックアップを取得しサーバーログを調査しましょう。この時点でホスティング業者のサポートを利用するのが安全です。特にECなど重要データの場合、自己判断の修復よりプロの対応が望ましいです。

修復が失敗した場合の対処法

phpMyAdminによるテーブル修復は必ず成功するわけではありません。テーブルサイズが巨大、深刻なファイル破損、ディスク障害、権限不足などで処理が中断することも。以下の手順を参考にしてください：

• バックアップからのリストア：最も確実なのは障害発生前の最新バックアップを復元すること。リストア前に現在の破損データベースを別ファイルとして保存しましょう。
• SSHによるmyisamchk利用：MyISAMテーブルの場合、サーバーアクセスがあればmyisamchkツールで修復可能。MySQLサービスを停止またはテーブルアクセスを遮断して行います。
• REPAIR TABLEコマンド：phpMyAdminのSQLタブからREPAIR TABLE table_name; コマンドを実行できます。大規模テーブルならQUICKやEXTENDEDオプションも検討を。
• ディスク・inodeチェック：ディスク容量やinodeが不足すると修復失敗します。不要なバックアップやログ、一時ファイルを削除してください。
• サーバーエラーログ確認：MySQLエラーログ、Webサーバーログ、PHPエラーログは原因特定に不可欠です。

共有ホスティングの場合、SSHやサービス停止権限がないことが多いです。その場合は、エラーメッセージ・テーブル名・発生時刻・最後のバックアップ日をサポートに伝えると迅速な対応が期待できます。

再発防止策は？

一度の修復で問題が一時的に解消されても、恒久的な解決にはインフラやメンテナンスの徹底が必要です。以下の対策でMySQLテーブル破損リスクを大幅に軽減できます。

MyISAMテーブルからInnoDBへの移行を検討

現代のWebアプリではInnoDBがより安全かつ堅牢です。行レベルロックやトランザクション、クラッシュ後の復旧機能がMyISAMより優れています。移行はALTER TABLE table_name ENGINE=InnoDB; のコマンドで可能ですが、本番環境では事前テストと完全バックアップが必須です。一部の旧システムは全文インデックスやMyISAM特有の動作に依存していることもあります。

定期的・復元可能なバックアップを維持

バックアップは「取得するだけ」でなく「復元できる」ことが重要です。日次バックアップ・週次フルバックアップ・重要更新前の手動バックアップが理想的です。最低でも7日分のバックアップ保存は中小サイトなら十分なスタートです。ECサイトでは注文損失防止のため、より頻繁なバックアップやbinlog復旧も推奨されます。

ディスク使用率やリソース監視を徹底

ディスク使用率が85～90％に達したらアラートを発生させましょう。MySQLは一時テーブルやログ、インデックス処理に空き容量が必要です。CPU・RAM・I/O待機時間も定期的に監視し、常にリソース上限に達するサイトは障害を起こしやすいです。トラフィックが成長したら共有プランから強化パッケージへの移行も検討してください。法人ホスティング や 高性能ホスティング も参考になります。

プラグイン・テーマ・ソフトウェア更新の管理

古いソフトはセキュリティリスクだけでなく、非効率なクエリでデータベース負荷を高めます。WordPressなら不要プラグインの削除、ログテーブルの整理、不明なプラグインの使用回避が基本です。更新前にステージング環境でテストし、本番で予期せぬテーブル・インデックス障害を防ぎましょう。

サーバーの正しいシャットダウンとメンテナンス計画

VPSや専用サーバーを管理している場合、MySQLサービスの強制終了は避けてください。メンテナンス前にサービスを順序立てて停止し、更新はアクセスが少ない時間帯に実施、再起動後はログを確認しましょう。計画的なメンテナンスは高トラフィックDBの破損リスクを低減します。

WordPressサイト向けの特記事項

WordPressはMySQLエラーを「データベース接続確立エラー」として表示することが多いですが、エラーログには破損テーブルの詳細が記載されます。特に影響を受けやすいテーブルはwp_options、wp_posts、wp_postmeta、wp_comments、各種プラグインのタイマーやログテーブルです。wp_optionsが破損するとサイト設定が読めなくなり、wp_postsなら記事一覧が表示されません。プラグインのログテーブルが破損すると管理画面が重くなることも。

WordPressには独自のDB修復機能もあります。wp-config.phpに一時的に define('WP_ALLOW_REPAIR', true); を追加し、/wp-admin/maint/repair.php から修復できます。ただし処理後は必ずこの行を削除し、修復画面への不正アクセスを防ぎましょう。phpMyAdminの方法は、どのテーブルを操作しているか明確なためより管理しやすいです。WordPressに最適化されたインフラを求めるなら WordPressホスティング をご覧ください。

プロのサポートが必要なケース

MySQLエラーは全て自己解決できるわけではありません。以下の状況ではプロフェッショナルな支援を求めるのが安全です：

• 破損テーブルが注文・決済・会員・財務データを含む場合
• 修復後もエラーが継続する、またはテーブルが消失した場合
• データベースサイズが数GB以上でphpMyAdminがタイムアウトする場合
• InnoDBテーブルスペースやredoログのエラーが出ている場合
• ディスク障害、I/Oエラー、ファイルシステム警告がある場合
• 直近のクリーンなバックアップが存在しない場合

サポート依頼時はエラーメッセージ全文、影響を受けたDB・テーブル名、発生時刻、直前の更新・移行履歴、バックアップ日などを伝えると解決までの時間が大幅短縮されます。

緊急時のチェックリスト

急ぎの場合は以下の順番で対応しましょう：

• エラーメッセージから破損テーブル名を確認する
• 現状のデータベースをバックアップする
• サイトを一時的にメンテナンスモードにする
• phpMyAdminで正しいデータベースを選択する
• 該当テーブルを選択しテーブルの修復を実行する
• テーブルチェックとサイト機能の検証を行う
• ディスク・リソース・バックアップ・テーブルエンジンの再確認で再発リスクを下げる

よくある質問

MySQL「Table is marked as crashed」エラーはデータ損失を意味しますか？

必ずしもデータ損失とは限りません。多くのMyISAMテーブルはphpMyAdminのテーブル修復で復旧可能ですが、深刻な破損の場合一部レコードが失われることも。修復前のバックアップ取得が重要です。

phpMyAdminによるテーブル修復は安全ですか？

基本的に安全ですが、本番DBでのメンテナンスにはリスクが伴います。事前バックアップ、対象テーブルの確認、可能ならメンテナンスモードへの切替で安全性が高まります。重要テーブルや大規模DBならプロの支援を推奨します。

InnoDBテーブルにもテーブル修復を使うべきですか？

InnoDBテーブルはMyISAMと異なり、REPAIR TABLEでは修復できません。InnoDBの障害時はMySQLログやディスク状態確認、必要ならバックアップからの復元が正しいアプローチです。無理な修復はデータ損失リスクを高めます。

このエラーが頻発する原因は？

エラーが再発する場合、根本原因が未解決のことが多いです。ディスク容量不足、サービスの突然停止、激しい書き込み、破損プラグイン、古いMySQL、MyISAM継続使用などが主な理由です。原因特定が恒久対策の鍵です。

修復前にホスティング会社へ相談すべきですか？

簡単なMyISAMテーブル障害ならバックアップ取得後phpMyAdminで修復可能ですが、重要データ、バックアップ無し、大規模DB、InnoDB障害の場合はホスティングサポートの利用が安全です。

まとめ

MySQL「Table is marked as crashed」エラーは主にMyISAMテーブルで発生し、phpMyAdminによる修復で大半は復旧できます。正しいアプローチは、まずバックアップ取得→破損テーブル特定→phpMyAdmin修復→原因除去です。定期バックアップ、十分なサーバーリソース、InnoDB利用、最新ソフトウェア基盤で再発リスクを低減できます。同様の障害が頻発する場合はインフラ再評価や適切なホスティング選びのため、Hostragonsリソースやサポートチームへの相談をおすすめします。