エラー：テーブルxxxのテーブルスペースが存在します。インポートする前にテーブルスペースを破棄してください

私はMySQLを初めて使用し、かなり興味深いエラーが発生します。このエラーについては、googleおよびstackoverflow検索でヘルプを見つけることができません。

MacOS 10.8.3でMySQL 5.6.10のローカルサーバーを実行していて、MySQLのNavicat Essentialsを介してデータベースを管理しています。

私が得るエラーは、データベースを数日/数週間実行して管理した後、何かがトリガーされ（不完全に表示され）、Navicat内からクエリを使用して作成したテーブルの一部を削除することです。

これらのテーブルを使用してクエリを実行しようとすると、Navicatは特定のテーブルが存在しないことを警告します。これまでのところ良い-ここで良い部分があります：

以前に存在していた "temp"などの名前のテーブルを作成しようとすると、次のエラーメッセージが表示されます。

Error : Tablespace for table '`database`.`temp`' exists. Please DISCARD the tablespace before IMPORT.

ただし、テーブルを削除しようとした場合、またはこのテーブルのテーブルスペースを破棄しようとした場合は、

DROP TABLE temp;
ALTER TABLE temp DISCARD TABLESPACE;

次のエラーメッセージが表示されます。

Error : Unknown table 'database.temp'
Error : Table 'database.temp' doesn't exist

つまり、テーブルスペースを破棄することをお勧めしますが、破棄しようとするとテーブルが存在しなくなります。DISCARDクエリがチェックしていない別の場所に、このテーブルの残りの種類がある可能性はありますか？そして、誰かがそれをトリガーすることができるアイデアを持っていますか-思われるように完全にランダムに？

私が言ったように、私は主題に新しく、ほとんど無知です。ラップトップを再起動する、つまりローカルのMySQLサーバーをリセットするか、ユーザー権限の権限が関係しているのではないかと思いますが、ここでは仮説を立てています。

ここで少し遅くなりますが、一般的にこの問題は、「innodb_file_per_table」モードで実行しているときに「テーブルスペースがいっぱい」エラーが発生したときに発生します。詳細はここでは触れませんが、データベースサーバーのテーブルスペースはinnodb_data_file_path設定によって定義されており、デフォルトではかなり小さいです。より大きくしても、「テーブルスペースがいっぱい」は、より大きなクエリなどでも発生する可能性があります（テーブルにない「もの」の多くがそこに格納され、ログ、キャッシュなどを元に戻します）。

とにかく、files-per-tableが格納されているOSディレクトリ、デフォルトではOSXの/ var / lib / mysql、homebrew iircを使用した/ usr / local / var / mysqlを見ると、通常のコンパニオンtablename.frmファイルがない孤立したtablename.ibdファイル。その.ibdファイルを安全な一時的な場所（安全のため）に移動すると、問題が解決します。

$ ls /var/lib/mysql

table1.frm
table1.idb
table2.frm
table2.ibd
table3.idb <- problem table, no table3.frm
table4.frm
table4.idb

$ mkdir /tmp/mysql_orphans
$ mv /var/lib/mysql/table3.ibd /tmp/mysql_orphans/

ただし、1つの注意点があります。たとえば、長時間実行されているクエリ、ロックされたテーブルなど、最初から問題を引き起こしているものがクリアされていることを確認してください。そうしないと、2回目の試行時に、孤立した別の.ibdファイルが作成されるだけです。

XamppおよびMampユーザー

MySQLを介してデータベースを（空にした後）インポートするときに同じエラーが発生しました。tablename.ibd他のすべてのファイルが削除されている間、ファイルが残っていることがわかりました。から手動で削除したところmysql/data/database_name、エラーは発生しませんでした。

WAMP [Windows 7 Ultimate x64-bit]ユーザーの場合：

DangerDaveの発言に同意するため、WAMP ユーザーが回答できるようにします。

注：最初に、.. \ WAMP \ Bin \ MySQL \ MySQL [Your MySQL Version] \ Dataフォルダーに移動する必要があります。

これで、すべてのデータベースのフォルダーが表示されます

• 問題のテーブルがあるデータベースのフォルダをダブルクリックして開きます
• ファイルがあるべきではなく[Your offending MySQL table name].frm、代わりにファイルがあるべきです[Your offending MySQL table name].ibd
• 削除します [Your offending MySQL table name].ibd
• 次に、ごみ箱からも削除します
• 次に、データベースでMySQLクエリを実行すると、完了です

あなたが得る場合は.idb、あなたがそれを削除した後、再び再作成し、その後、この回答を読んで。

これが私とどのように機能したか。.idb対応していないファイルがあり、ファイル.frmを削除するたびに.idb、データベースによって再度作成されました。そして、MySQLのドキュメントで1行で解決策を見つけました（テーブルスペースが存在しない部分）

1-他のデータベースディレクトリに一致する.frmファイルを作成し、孤立したテーブルが配置されているデータベースディレクトリにコピーします。

2-元のテーブルに対してDROP TABLEを発行します。これにより、テーブルが正常に削除され、InnoDBは.ibdファイルが見つからなかったことを示すエラーログに警告を出力します。

別のテーブル.frmファイルをコピーして、足りないテーブルの名前を付けてから、通常のドロップテーブルクエリを実行し、できあがりました。正常に機能し、テーブルは正常にドロップされます。

私のシステムは、Windows MariaDB v 10.1.8上のXAMPPです。

私の場合、唯一の解決策は次のとおりです。

1. CREATE TABLE bad_tableENGINE = MyISAM ...
2. rm bad_table.ibd
3. ドロップテーブル bad_table

これは、ログファイルにまったく同じエラーを表示するテーブルがあったときに、fedoraのmariadb 10.2.16で行ったとおりです...

2018-07-11  9:43:58 140323764213504 [Note] InnoDB: The file './database_name/innodb_table.ibd' already exists though the corresponding table did not exist in the InnoDB data dictionary. You can resolve the problem by removing the file.
2018-07-11  9:44:29 140323764213504 [Warning] InnoDB: Tablespace 'database_name/innodb_table' exists in the cache with id 2836 != 2918

あなたのマイレージとエラーは異なる場合がありますが、私が想定する主なものは

...already exists though the corresponding table did not exist in the InnoDB data dictionary...

ドロップテーブルが機能していないだけでなく、テーブルを変更しています...

MariaDB [database_name]> drop table innodb_table;
ERROR 1051 (42S02): Unknown table 'database_name.innodb_table'

MariaDB [database_name]> alter table innodb_table discard tablespace;
ERROR 1146 (42S02): Table 'database_name.innodb_table' doesn't exist

テーブルの作成も次のように失敗します。

MariaDB [database_name]> create table  innodb_table(`id` int(10) unsigned NOT NULL);
ERROR 1813 (HY000): Tablespace for table '`database_name`.`innodb_table`' exists. Please DISCARD the tablespace before IMPORT

これを修正するために、私が最初に行ったのは

create table  innodb_table2(`id` int(10) unsigned NOT NULL);
Query OK, 0 rows affected (0.07 sec)

次に、/ var / lib / mysql / database_nameディレクトリで、ルートとして次のことを行い、innodb_table.ibdの上書きが問題を引き起こしていることを確認しました

cp -a innodb_table2.frm innodb_table.frm
cp -a innodb_table2.ibd innodb_table.ibd
systemctl restart mariadb

mysqlコンソールに戻って、両方のテーブルで正常にドロップコマンドを発行しました

MariaDB [database_name]> drop table innodb_table;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    8
Current database: database_name

Query OK, 0 rows affected (0.08 sec)

MariaDB [database_name]> drop table innodb_table2;
Query OK, 0 rows affected (0.25 sec)

これですべてが正方形になり、1つのテーブルを再作成できます...

MariaDB [database_name]> create table  innodb_table (`id` int(10) unsigned NOT NULL);
Query OK, 0 rows affected (0.08 sec)

編集：私は追加するつもりでした

restorecon -Rv /var/lib/mysql/database_name 

ほとんどすべてのselinuxコンテキストをデータベースから削除する場合でも、データベースをコピーした後にコマンドを実行して、すべてのselinuxコンテキストを本来の方法で取得しますが、代わりに--archiveまたは-aオプションを2つのcpに追加することもできます。コマンドなので、はい、実際にはアーカイブオプションはこれを短くします：

cp innodb_table2.frm innodb_table.frm
cp innodb_table2.ibd innodb_table.ibd
chown mysql:mysql innodb_table.frm innodb_table.ibd
chmod 660 innodb_table.frm innodb_table.ibd
restorecon -Rv /var/lib/mysql/database_name
systemctl restart mariadb

私がより良いと思う次のようにして、すでに作成されたテーブルに設定されているselinuxコンテキストを保持します。

cp -a innodb_table2.frm innodb_table.frm
cp -a innodb_table2.ibd innodb_table.ibd
systemctl restart mariadb

上記のコマンドの長いリストを短いリストに置き換えましたが、短くすることもできます*

私の場合：

最初にtableName.ibdMysqlからデータベースディレクトリを削除し、2回目に実行します。

ALTER TABLE tableName DISCARD TABLESPACE;
DROP TABLE tableName;

ユーザーテーブルを作成しようとしたときに、wampserverで同じエラーを実行しました。users.ibdファイルを見つけ、このファイルを削除した後、migrateコマンドを再度実行すると、正常に機能しました。私のWindowsマシンのファイルはwamp / bin / mysql / mysql5.6.12 / data / myprojectにありました。

解決

ただし、より簡単なオプションはこれです。MySQLを再起動してから、次のように同じ4つの手順を実行します。

1) created a dummy table in the database;
2) discarded its tablespace;
3) moved the .ibd file into the database folder on the system;
4) attached the tablespace back to the table

このようにして、データディクショナリのテーブルスペースIDとファイルが一致します。したがって、表領域のインポートは成功しました。

これにより、リカバリプロセスやファイル転送の際にInnoDBの「問題」を処理する際の信頼性が高まります。

ref

解決策の手順は次のとおりです。

1. データベースのバックアップ（ドロップオプションとデータを含む構造）
2. mysqlエンジンサービスを停止する
3. mysql / data内から手動でデータベースディレクトリを削除する
4. MySQLエンジンを起動します
5. 破損したデータベースとは異なる名前で新しいデータベースを作成する
6. 新しいデータベース内に破損したテーブルの名前で単一のテーブルを作成します（これが秘密です）。まったく同じ構造のテーブルを作成することをお勧めします。
7. データベースの名前を古い破損したデータベースに変更します
8. バックアップを復元すると、テーブルは正常に動作します。

この問題が数回発生しました。大規模なDBがあり、バックアップ/復元（不足しているテーブルが追加されている）を回避したい場合は、数回前後してみてください。

DROP TABLE my_table;

ALTER TABLE my_table DISCARD TABLESPACE;

-そして-

/ var / lib / mysql / my_db /ディレクトリにあるrm my_table.ibd（対応するmy_table.frmのないオーファン）

-その後-

存在しない場合はテーブルを作成my_table（...）

tablename.ibdの削除/移動は確かにうまくいきませんでした。

解決方法

破損した既存のテーブルを削除する予定だったので、phpmyadmin-> database-> export-> selected tables to backup-> export（as .sql）に移動して、他のテーブルのバックアップを取った。

その後、データベース名の横にあるデータベースアイコンを選択して、ドロップしました。新しいデータベースを作成しました。新しいデータベースを選択->インポート->以前にダウンロードしたファイルを選択-> [インポート]をクリックします。これで、古い作業テーブルが作成され、破損したテーブルが削除されました。次に、エラーをスローしていたテーブルを作成します。

破損したテーブルの以前のバックアップがあったようです。

このエラーは、一部の機能を中断したときに発生します。不正な外部キーを使用して以下のクエリを実行するように。

set foreign_key_checks=0

まったく同じ問題がありました。私は醸造を追加しましたmysql@5.6（以前は5.5があった後）。

5.6のbrewのデフォルトinnodb_file_per_table=1は5.5ですが、innodb_file_per_table=0。

既存のibdata1ファイル（結合されたinnodbデータ）には、作成またはドロップしようとしているテーブルへの参照がまだあります。innodb_file_per_table0に戻すか、ibdata1データファイルを削除します（これによりすべてのデータが失われるため、最初にmysqldumpを実行するか、または.sqlダンプを作成してください）。

mysql@5.6私を悩ませた他の醸造のデフォルトはポートの欠如でした、それでネットワークはデフォルトでunixソケットになり、mysqlクライアントは報告を続けました：

ERROR 2013 (HY000): Lost connection to MySQL server at 'sending authentication information', system error: 32

配列に追加<string>--port=3306</string>しました.plistがport=3306、自分で指定することもできますmy.cnf

実行brew services stop mysql@5.6して変更を加えますbrew services start mysql@5.6

テーブルスペースを削除しようとすると、他のエラーが発生する可能性があります。私にとって、次のエラーが発生しました：

DROP TABLESPACE `tablename`

Error Code: 1478. Table storage engine 'InnoDB' does not support the create option 'TABLESPACE or LOGFILE GROUP' 

私の解決策は、データベースを削除することでした。これにより、関連するすべてのテーブルスペースが削除され、テーブルを再度作成できるようになります。

同じテーブルの適切なバージョンの別のサーバーがある場合は、コピー（table_copy）を作成し、問題のサーバーにtable_copyを転送します。次に、問題のあるテーブルを削除し、table_copyの名前をtableに変更します。

私にとっては、/ var / lib / mysql / {db_name}（linux）の下のMYSQL DATAディレクトリに移動し、フォルダー名と同じ{table_name} .ibdファイルをドロップするのに役立ちました。

ローカルホストにある古いDBをwampから直接削除するだけです。すべてのサービスを停止し、wamp / bin / mysql / mysql [version] / dataに移動して、問題のあるDBを見つけました。それを削除して、すべてのサービスをもう一度開始します。データベースを再度作成します。これで、テーブルをインポートできます。

この問題を "解決"するために見つけた方法はかなり面倒ですが、それを処理するスクリプトがあります。

基本的に、ibdata1とib_logfile*ファイルを削除する必要があります（これらには、とりわけ、外部キーのマッピングが含まれています）。これを行う唯一の安全な方法は、すべてのデータベースをエクスポートし、mysqlを停止してファイルを削除し、mysqlを起動してからファイルをインポートすることです。

この問題を解決するのに役立ちますスクリプトがあるhttps://github.com/uberhacker/shrink-ibdata1それは、このスクリプトの述べられた目的が異なっていても、い問題を解決します。

それが私のために働いた唯一の方法は：

1. 同様のテーブルを作成する
2. 新しい同様のテーブルの.frmおよび.idbファイルを、破損したテーブルの名前にコピーします。
3. 権限を修正する
4. MariaDBを再起動します
5. 破損したテーブルを削除する

この問題があり、別のオプションがない場合は、エンジンを「myisam」などの他のエンジンに変更してから、テーブルを作成してみてください。

免責事項： 別のストレージエンジンではサポートされない外部キー制約がある可能性があるため、これは有効な回答ではありません。すべてのストレージエンジンには、データを保存してアクセスするための独自の専門分野があり、これらの点も考慮に入れられます。

インポートする前にテーブルスペースを破棄してください

同じ問題の解決策が下にあります

1. まず、データベース名を削除する必要があります。データベースが削除されていない場合は、私にフローがあります。Windowsシステムの場合、ディレクトリはC：/ xampp / mysql / data / yourdabasefolderになります "yourdabasefolder"を削除します

2. ここでも、新しいデータベースを作成し、古いSQLファイルをインポートする必要があります。仕事になります

ありがとう

MySQLデータディレクトリを見つける必要がありました。

SHOW VARIABLES WHERE Variable_Name LIKE "％dir"

次に、そのデータベースを強制的に削除します。

sudo rm -rf

mysql rootユーザーとして次のクエリを実行できます

drop tablespace `tableName`

ちょっと開発者はあなたの時間を無駄にしないでください。テーブルを含むデータベースを削除し、テーブル全体を再度インポートするだけです。時間を節約する=時間はお金です。乾杯。