MySQL> Tableが存在しません。しかし、それは（あるいはそうすべきです）
私はMySQLインストールのdatadirを変更しました、そして、それがうまくいくいくつかのステップに続いて。私が持っていたすべての基地は正しく移動しました。
SHOW TABLESが全てのテーブルを正しく返して各テーブルのファイルがmysqlのdataディレクトリに存在していても、データベースに接続して使用することができます。しかし、そこで何かをSELECTしようとすると、そのテーブルは存在しないということになります。しかし、テーブルは存在します、それはSHOW TABLESステートメントでさえ示します！
SHOW TABLESがファイルの存在をリストしているのはどういうわけかファイルが壊れているかそのようなものであるが、それはそれをチェックしないと思います。だから私はそれらをリストすることはできますがそれらにアクセスすることはできません。
しかし、それは推測にすぎません。私はこれまで見たことがありません。テストのためにデータベースを再起動できません。それを使用する他のすべてのアプリケーションは正常に動作しています。
誰かがそれが何か知っていますか？
例：
mysql> SHOW TABLES;
+-----------------------+
| Tables_in_database |
+-----------------------+
| TABLE_ONE |
| TABLE_TWO |
| TABLE_THREE |
+-----------------------+
mysql> SELECT * FROM TABLE_ONE;
ERROR 1146 (42S02): Table 'database.TABLE_ONE' doesn't exist
万が一誰かがまだ気にかけている：
コマンドを使用してデータベースディレクトリを直接コピーした後に同じ問題が発生しました
cp -r /path/to/my/database /var/lib/mysql/new_database
InnoDBテーブルを使用しているデータベースでこれを行うと、上記の「テーブルが存在しません」というエラーが発生します。
問題は、MySQLデータディレクトリのルートにib*ファイルが必要なことです（例：ibdata1、ib_logfile0およびib_logfile1）。
それらをコピーしたとき、それは私のために働きました。
私はMac OS（MySQL DMGインストール）でMySQLサーバを再起動するだけで問題が解決しました。私は冬眠がそれを引き起こしたと思います。
このエラーは、lower_case_table_namesを1に設定し、その変数のデフォルト値で作成されたテーブルにアクセスしようとしたときにも発生する可能性があります。その場合、前の値に戻すことができ、テーブルを読むことができます。
使用しているテーブル名の大文字と小文字が区別されていない場合にこの問題が発生します。そのため、tableは 'db'と呼ばれますが、select文では 'DB'を使用しました。ケースが同じであることを確認してください。
- mysqldを停止
- バックアップMySQLフォルダ：
cp -a /var/lib/mysql /var/lib/mysql-backup - 古いマシンから
/var/lib/mysqlにデータベースフォルダをコピーします - 古いデータベースからib *（ib_logfile *、ibdata）をオーバーライドする
- mysqldを起動します。
- ダンプデータベース
mysqldump >dbase.mysql- mySQLサービスを停止します
/var/lib/mysqlを削除します。/var/lib/mysql-backupを/var/lib/mysqlに名前変更- mysqldを起動します。
- データベースを作成する
mysqldump < dbase.mysql
クエリを実行してください。
SELECT
i.TABLE_NAME AS table_name,
LENGTH(i.TABLE_NAME) AS table_name_length,
IF(i.TABLE_NAME RLIKE '^[A-Za-z0-9_]+$','YES','NO') AS table_name_is_ascii
FROM
information_schema.`TABLES` i
WHERE
i.TABLE_SCHEMA = 'database'
残念ながら、MySQLではUnicodeと印刷不可能な文字をテーブル名に使用することができます。あるドキュメント/ Webサイトからcreate codeをコピーしてテーブルを作成した場合は、幅がゼロのスペースがどこかにある可能性があります。
私はこの悪夢にちょうど3日を費やしました。理想的には、復元できるバックアップを作成してから、破損したテーブルを単純に削除する必要があります。これらの種類のエラーは、ibdata1が 巨大 （中程度のテーブルでは100GB以上のサイズ）になる可能性があります。
MySqlDumpに頼っているなど、最近のバックアップがない場合は、おそらく過去のある時点でバックアップが黙って失敗したことになります。 mySqlDumpの実行中にロックエラーが発生するため、データベースをエクスポートする必要があります。もちろん、これはできません。
そのため、回避策として、/var/log/mysql/database_name/に移動してtable_nameを削除してください。
それからすぐにテーブルをダンプしてみてください。これをしてもうまくいくはずです。今すぐデータベースを新しいデータベースに復元し、不足しているテーブルを再構築します。次に壊れたデータベースをダンプします。
私たちの場合は、すべてのデータベースでランダムな間隔で常にmysql has gone awayメッセージを受け取っていました。破損したデータベースが削除されると、すべて正常に戻りました。
私は同じ問題を抱えていて、そして私は2-3日の間探しました、しかし、私のための解決策は本当にばかでした。
MySQLを再起動します。
$ Sudo service mysql restart
今すぐテーブルがアクセス可能になります。
OK。これはかなり不合理に聞こえるでしょうが、私をユーモアにします。
私の声明を次のように変更すると、問題が解決しました。
SELECT * FROM `table`
2つの変更を加えました
1。）テーブル名を小文字にしました - わかりました！
2。）特定の引用符を使います= ` ：それはあなたのTABの上のキーです
解決策は不合理に聞こえるが、それはうまくいったし、それは土曜日の夜で、私は午前9時から働いていた - だから私はそれを取るつもりだ:)
がんばろう。
Idb-fileをコピーする前に、SQLクエリを実行してテーブルスペースを破棄します。
ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;
IDBファイルのコピー
ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;
MySqlを再起動します。
ゴーストテーブルにも同様の問題がありました。ありがたいことに、失敗の前からSQLダンプを取っていました。
私の場合、私はしなければなりませんでした：
- MySQLを停止する
- Ib *ファイルを
/var/mysqlからバックアップに移動します。 /var/mysql/{dbname}を削除- MySQLを再起動
- 空のデータベースを再作成
- ダンプファイルを復元する
注：ダンプファイルが必要です。
私は同じ問題を抱えていたMySQLを再インストールしなければならない、それはInnoDBログファイルについてのデータを格納するいくつかの設定ファイル、これらのファイルib_logfile *（上書きされたログファイルです）を上書きします。この問題を解決するために、ib_logfile *ファイルを削除しました。
WAMPをアップグレードしたがデータベースのバックアップがなかったため、この問題が発生しました。
これは私のために働いた：
新しいWAMPをやめる
古いWAMPインストールから必要なデータベースディレクトリとibdata1ファイルをコピーします。
ib_logfile0とib_logfile1を削除しますWAMPを起動
これでデータベースのバックアップを作成できるはずです。しかし、サーバーを再起動した後も問題が残るでしょう。 WAMPを再インストールしてデータベースをインポートしましょう。
理由はわかりませんが、私の場合は、外部キーチェックを無効にして有効にするだけで解決しました
SET FOREIGN_KEY_CHECKS=0;
SET FOREIGN_KEY_CHECKS=1;
私にとってうまくいったのは、テーブルが存在しなくてもテーブルを削除することだけでした。それからテーブルを再作成し、以前に行ったSQLダンプから再作成しました。
テーブル名のメタベースがあるに違いありません、そしてそれは私がそれを落とすまでそこに存在していた可能性が最も高いです。
データベースにmysqldumpを実行します。
mysqldump -u user -ppass dbname > D:\Back-ups\dbname.sqlデータベースを復元する
mysql -u user -ppass dbname < D:\Back-ups\dbname.sql
データベース内のすべてのテーブルが完全に復元されました。お試しください。
SELECT * FROM dbname.tablename;
私の場合は、テーブルにトリガーを定義してから、テーブルに行を挿入しようとしていました。どういうわけかトリガが誤っていたので、insertがエラーを出していました。テーブルは存在しません。
問題は無効な（壊れた？）innodbログファイルで（少なくとも私のものでも他のいくつかでも）行わなければならないようです。一般的に言って、それらは単に作り直される必要があります。
これが解決策です、そのほとんどはmysqlの再起動を必要とします。
- ログファイルを再作成します（ mysqlを削除して再起動します ）
- ログファイルのサイズを変更します （MySql 5.6以降ではファイルが再生成されます）
- 何らかの種類のデータ移行を行っている場合は、正しいファイルを正しく移行し、他の人が既に述べたようにアクセス権を与えていることを確認してください。
- Mysqlが両方の所有者であることを確認してください。
- 他のすべてが失敗した場合は、おそらくデータベースを再作成する必要があります。
MariaDBを新しいコンピュータにインストールし、Mysqlサービスがdataフォルダをdataに変更したのを停止しました - クラッシュしたHD MySql dataフォルダから Mysql\data\table_folders および ibdata1 をコピーするだけmysqlデータフォルダをインストールしました。
ib_logfile0 および ib_logfile1 をスキップしました（そうでない場合、サーバーはサービスを開始しませんでした）
MySQLサービスを開始しました。
その後、サーバーは稼働しています。
これは別のシナリオです（バージョンアップ） ：
私は自分のOS（Mac OS El Captain）を再インストールし、（homebrewを使って）新しいバージョンのmysqlをインストールしました。インストールされたバージョン（5.7）はたまたま以前のバージョンよりも新しいものです。それから、ib *ファイルを含むテーブルをコピーして、サーバーを再起動しました。 mysqlワークベンチでテーブルを見ることができましたが、何かを選択しようとすると、「テーブルが存在しません」と表示されます。
溶液：
- mySQLサーバーを停止します。
mysql.server stopまたはbrew services stop mysql mysqld_safe --user=mysql --datadir=/usr/local/var/mysql/を使用してサーバーを起動します（必要に応じてパスを変更します）。- （別の端末ウィンドウで）
mysql_upgrade -u root -p passwordを実行する - 実行中のサーバーをシャットダウンします
mysqladmin -u root -p password shutdown - サーバーを通常モードで再起動します
mysql.server startまたはbrew services start mysql
関連ドキュメントは here です。
xampp\mysql\data\dbnameにアクセスしてください。
dbname内には、tablename.frmおよびtablename.ibdファイルがあります。
これを削除してmysqlを再起動してからやり直してください。
私の場合はSQLCA.DBParmパラメータでした。
私が使った
SQLCA.DBParm = "Databse = "sle_database.text""
しかしそれはする必要があります
SQLCA.DBParm = "Database='" +sle_database.text+ "'"
説明：
あなたは3つの文字列を組み合わせるつもりです：
1. Database=' - "Database='"
2. (name of the database) - +sle_database.text+
3. ' - "'" (means " ' " without space)
クォータマークにスペースを使用しないでください。私の同僚に感謝します。
今日も同じ問題を乗り越えた。これはMySQLの "識別子の大文字と小文字の区別"の問題です。
対応するデータファイルを確認してください。ファイルシステム上のファイル名は小文字ですが、 "show tables"コマンドにリストされているテーブル名は大文字である可能性が非常に高いです。システム変数 "lower_case_table_names"が0の場合、 "lower_case_table_names"が0の場合は名前の比較で大文字と小文字が区別されるため、クエリは "table not exist"を返します。
古いデータディレクトリからibdata1ファイルのみをコピーします。 ib_logfile1またはib_logfile0ファイルをコピーしないでください。それによりMySQLはもう起動しなくなります。
テーブル名に隠し文字が含まれている可能性があります。あなたがショーテーブルをするとき、それらは現れません。あなたは "SHOW CREATE TABLE TABLE_ONE"をして "TABLE_ONE"をタブ補完してそれが隠された文字を入れるかどうかを見ることができますか。また、あなたはテーブルを落として作り直すことを試みましたか。権限に問題がないこと、隠し文字がないことを確認するためだけに使用してください。
私の場合、エクスポートしたSQLファイルをインポートしたときに、create tableクエリにtableが存在しないなどのエラーが発生していました。
私は自分のデータベース名にアンダースコアがあり、mysqlがその直前にエスケープ文字を入れていることに気づきました。
データベース名のアンダースコアを削除したので、すべてうまくいきました。
それが他の誰かにも役立つことを願っています。
私が思うにもう一つの答えはここで持ち出す価値がある（私はその同じ問題でここに来た、そしてこれが私のための答えであることがわかったので）：
クエリ内のテーブル名が で、データベース内のものとまったく同じ であることを再確認してください。
明らかな初心者向けのものですが、 "user" vs "users" のようなものは人をつまずくことがありますので、ここのリストに載せておくと便利です。 :)
Time Machineバックアップのインポート後も同じ問題が発生します。私の解決策は、MySQLサーバーを停止し、ib *ファイルの読み書き許可を修正することでした。
入力したときにテーブルに文字がありません。次の手順を実行してください。
mysql> show tables;
+-----------------------+
| Tables_in_database |
+-----------------------+
| TABLE_ONE | Double click on TABLE_ONE and copy*
| TABLE_TWO | (*You'd get the correct string)
| TABLE_THREE |
+-----------------------+
mysql> SELECT * paste_your_copied_table;
テーブルがmysqlで表示されている場合、それは存在しています。これでうまくいくはずです。
私のテーブルはどういうわけか' Customers'にリネームされました、すなわち 先行スペース
この意味
a）クエリが壊れた
b）テーブルが私のテーブルのアルファベット順に期待通りに表示されませんでした。これは私の panic の中で私はそれを見ることができなかったことを意味します！
RENAME TABLE ` Customer` TO `Customer`;
私も同じ問題を抱えていましたが、それは隠れたキャラクターや「シュレーディンガーのテーブル」が原因ではありませんでした。問題は（上記のとおり）復元プロセスの後に発生しました。 MySQL管理者バージョン1.2.16を使用しています。復元を実行する必要がある場合は、ターゲットスキーマでORIGINALのチェックを外し、ドロップボックスからデータベースの名前を選択する必要があります。その後問題は修正されました。少なくともそれが私のデータベースの理由でした。
テーブル名にピリオドがあると、SELECT * FROM poorly_named.table;に失敗します。
バッククォートを使用してテーブルSELECT * FROM `poorly_named.table`;を検索します。
私の場合は、datadirの再配置やファイル操作をしなくても可能でした。それはちょうどある晴れの日に起こりました。
奇妙なことに、mysqldumpを使ってテーブルをダンプすることができたので、MySQLは「テーブルが存在しない」と不平を言うことがありましたが、テーブルのスキーマ+データをダンプし、テーブルを削除してその直後にそれを作成し、続いてインポートします。