125

私はすべての中で最も奇妙なエラーを抱えています。

テーブルを作成または変更するときに、「テーブルが既に存在します」というエラーが表示されることがあります。ただし、DROP TABLE は「#1051 - 不明なテーブル」を返します。そのため、作成も削除もできないテーブルを取得しました。

データベースを削除しようとすると、mysqld がクラッシュします。別の名前で別のデータベースを作成すると役立つ場合もあれば、そうでない場合もあります。

私は、すべて InnoDB の 50 個までのテーブルを持つ DB を使用しています。この問題は、別のテーブルで発生します。

Windows、Fedora と Ubuntu、MySQL 5.1 と 5.5 でこれを経験しました。PDO、PHPMyAdmin、またはコマンドラインを使用する場合も同じ動作です。MySQL Workbench を使用してスキーマを管理しています。関連するエラー (エンドラインなど) がいくつかありましたが、どれも私には関係ありませんでした。

いいえ、それはビューではなく、テーブルです。すべての名前は小文字です。

私はグーグルでできることすべてを試しました-テーブルをフラッシュし、.frmファイルをdbからdbに移動し、mysqlログを読みましたが、何も役に立ちませんでしたが、いまいましいもの全体を再インストールしました。

「テーブルの表示」では何も表示されず、「テーブルの説明」では「テーブルが存在しない」と表示され、.frm ファイルはありませんが、「テーブルの作成」は依然としてエラーで終了します (「存在しない場合はテーブルの作成」もエラーで終了します)。データベースを削除すると mysql がクラッシュする

関連するが役に立たない質問:

編集：

mysql> use askyou;
Database changed

mysql> show tables;
Empty set (0.00 sec)

mysql> create table users_has_friends (id int primary key);
ERROR 1050 (42S01): Table '`askyou`.`users_has_friends`' already exists

mysql> drop table users_has_friends;
ERROR 1051 (42S02): Unknown table 'users_has_friends'

そして、すべて同じです。テーブルは存在しませんが、作成できません。

mysql> drop database askyou;
ERROR 2013 (HY000): Lost connection to MySQL server during query

名前の変更、これは私が問題に遭遇した唯一のテーブル/データベースではありません

4

11 に答える 11

24

この問題は、データ ディレクトリにデータ ファイルがなくてもテーブル定義ファイルが存在する場合、またはその逆の場合に発生します。innodb_file_per_table を使用している場合は、データ ディレクトリを調べて.frm、問題のテーブルのファイルと .ibd ファイルの両方があることを確認してください。MYISAM の場合、、、.frmおよび.MYIファイル.MYDがあるはずです。

この問題は通常、孤立したファイルを手動で削除することで解決できます。

于 2012-05-16T16:28:20.440 に答える
14

ここで大雑把な推測をしますが、innodb にはまだテーブルのエントリがテーブルスペース (おそらくibdata. データがまったく必要ない場合、またはバックアップがある場合は、次のことを試してください。

  1. すべてのスキーマを削除します (mysql を除く)
  2. データベースをシャットダウンします
  3. データ ディレクトリ内のすべてのフォルダが適切に削除されていることを確認します (ここでも mysql を除く)。
  4. ibdata とログ ファイルを削除する
  5. データベースを再起動します。テーブルスペースとログを最初から再作成する必要があります。
于 2012-05-28T01:13:45.703 に答える
6

修正は簡単です。少なくとも私が解決したことは、私にとってはうまくいきました。別の MySQL インスタンスにテーブル「zzz」を作成します。zzz は問題のテーブル名です。(つまり、テーブルが schrodinger と呼ばれる場合、どのように記述されていても zzz をそれで置き換えます。) テーブルの定義が何であるかは問題ではありません。これは一時的なダミーです。zzz.frm ファイルを、テーブルがあるサーバー上のデータベース ディレクトリにコピーし、ファイルの所有権と権限が正しいことを確認します。MySQL では、「show tables;」を実行できるようになり、テーブル zzz がそこに表示されます。mysql> テーブル zzz を削除します。...動作するはずです。必要に応じて、ディレクトリ内の zzz.MYD または ZZZ.MYI ファイルをクリアします。

于 2014-09-08T08:56:30.910 に答える
5

これがここでの質問のケースに対する直接的な回答であるとは思えませんが、OS X Lion システムで認識されたこの正確な問題をどのように解決したかを以下に示します。

スケジュールしたいくつかの分析ジョブのテーブルを頻繁に作成/削除します。ある時点で、スクリプトの途中でテーブルが既に存在するというエラーが発生し始めました。通常、サーバーを再起動すると問題は解決しますが、それは面倒な解決方法でした。

次に、ローカル エラー ログ ファイルで次の特定の行に気付きました。

[Warning] Setting lower_case_table_names=2 because file system for /usr/local/mysql/data/ is case insensitive

これにより、テーブルに大文字が含まれている場合、MySQL はだまされて、それらを削除した後でもそれらがまだそこにあると考えるようになるのではないかと考えました。それが事実であることが判明し、テーブル名に小文字のみを使用するように切り替えると、問題は解消されました。

私の場合、設定ミスの結果である可能性がありますが、うまくいけば、このエラーケースが解決策を見つけるために無駄な時間を節約するのに役立ちます.

于 2012-08-04T16:36:59.003 に答える
3

これは古い質問ですが、私はちょうど同じ問題にぶつかり、上部にリンクされている関連する問題の 1 つの答えは、私が必要としていたものであり、ファイル、テーブルの削除、サーバーのシャットダウンなどよりもはるかに抜本的ではありませんでした.

mysqladmin -uxxxxxx -pyyyyy flush-tables
于 2016-07-12T10:16:44.953 に答える
2

このエラー 1051 の在庫があり、データベースのみを削除してこれを再度インポートする場合は、この手順を実行すればすべて問題ありません....

Unix 環境で AS root :

  • rm -rf /var/lib/mysql/YOUR_DATABASE;
  • オプション -> mysql_upgrade --force
  • mysqlcheck -uUSER -pPASS YOUR_DATABASE
  • mysqladmin -uUSER -pPASS ドロップ YOUR_DATABASE
  • mysqladmin -uUSER -pPASS create YOUR_DATABASE
  • mysql -uUSER -pPASS YOUR_DATABASE < IMPORT_FILE

よろしく、クリスタス

于 2013-01-26T14:13:25.737 に答える
1

私の場合、この問題は、mysqlデータディレクトリの所有権をアプリケーションを実行したユーザーに変更することで解決されました。（私の場合は、Jetty Webサーバーを実行しているJavaアプリケーションでした。）

mysqlが実行されていて、他のアプリがそれを適切に使用できたとしても、このアプリには問題がありました。データディレクトリの所有権を変更し、ユーザーのパスワードをリセットした後、すべてが正常に機能しました。

于 2012-08-27T15:24:36.517 に答える
0

ある特定のテーブルでこの問題が発生していました。考えられる解決策を読んで、次のようないくつかの手順を実行しました。

  • 孤立したファイルを検索します。誰も存在しませんでした。
  • execute: show full tables in database;: 問題のあるものは表示されませんでした。
  • 実行: describe table;: 返されtable doesn't existた;
  • 実行: SELECT * FROM information_schema.TABLES WHERE TABLE_NAME='table';: 返されEmpty setた;
  • 上記のクエリを phpMyAdmin で手動で検索します。

そして、これらの手順の後、もう一度チェックしてshow tables;... vualá! 問題のあるテーブルはなくなりました。私はそれを作成して同じ問題のある名前で問題なくドロップすることができ、サーバーを再起動する必要さえありませんでした! 変...

于 2013-09-29T15:51:07.970 に答える
0

私はこの問題を抱えており、上記のように IBD ファイルを削除すると解決することを期待しましたが、違いはありませんでした。MySQL は新しい IBD ファイルを再作成しただけです。私の場合、実際には同じ MySQL インスタンス内の他のデータベースに同様のテーブルがあります。FRM ファイルが見つからなかったので、別のデータベースの同様のテーブルから FRM ファイルをコピーし、MySQL を再起動すると、テーブルが正しく機能しました。

于 2013-03-29T08:16:26.023 に答える
0

テーブルを作成して削除した後、このエラーに遭遇し、再度作成したいと思いました。私の場合、自己完結型のダンプ ファイルがあったので、スキーマを削除して再作成し、ダンプ ファイルを使用してテーブルとデータをインポートしました。

于 2014-02-19T01:55:57.790 に答える