MySQLテーブルは存在しませんが、存在します
1146: Table '<database>.<table>' doesn't existテーブルが実際に存在する場合のエラー？
5台のサーバーで同じコードを使用していますが、最近レンタルした1台のサーバーだけがこのエラーを表示しているため、何らかの設定または設定エラーの可能性があります。コマンドラインからSQLステートメントを正常に実行できます。もちろん、コマンドラインからもテーブルを見ることができます。接続を確立しても接続エラーは発生しません（mysqliを使用しています）。
任意の助けをいただければ幸いです。
正確なクエリ：
$sql = "SELECT DISTINCT(mm_dic_Word) AS Word FROM spider.mm_dictionary WHERE mm_dic_deleted=0";
基本的に、私が経験していた問題は、パスワードハッシュの長さが異なるためだと思います。私の場合、新しいサーバーを入手し、そのサーバーで完全なmysqlダンプを行い、パスワードとユーザー情報も転送しました。新しいサーバーはすでに16文字の長さのハッシュを持つルートユーザーで初期化されましたが、私の古いサーバーは新しい32文字のハッシュ長を使用していました。
My.confにアクセスして、古いパスワード設定を0に設定する必要がありました（データベースを更新しようとするたびに、新しい更新の長さは16文字になりました）。その後、コマンドUPDATE mysql.user SET password=PASSWORD('password here');を使用してすべてのパスワードが同じになるように更新してから、特権をフラッシュしました。
明らかに、すべてのユーザーに同じパスワードを設定するのは非常に悪い考えなので、機能していることを確認した後、それらを1つずつ変更しました。
ブログエントリを入力しましたが、このソリューションに出くわす前に、私がやった他のいくつかの機能が動作しませんでした こちら ただし、上記の解決策は完了していると思いますが、エラーを再現しようとしていないため、100％確信が持てません。
これは私に起こったばかりで、しばらくしてブログ記事で答えを見つけたので、それをここにも掲載したいと考えました。
MySQLデータディレクトリを/var/lib/mysqlから/path/to/new/dirにコピーし、データベースフォルダー（つまり、mysql、wpdb、ecommerceなど）のみをコピーする場合）また、innodbテーブルがある場合、innodbテーブルは「show tables」に表示されますが、それらのクエリ（selectおよびdescribe）はエラーMysql error: table db.tableName doesn't existで失敗します。 dbディレクトリに.frmファイルが表示され、なぜだろうかと思うでしょう。
Innodbテーブルの場合、ib*ファイル（私の場合はibdata1、ib_logfile0、およびib_logfile1）をコピーすることが重要です。それらを確実にコピーして転送を行ったら、すべてが期待どおりに機能しました。
My.cnfファイルに「innodb_file_per_table」が含まれている場合、.ibdファイルはdbディレクトリに存在しますが、ib *ファイルが必要です。
この場合、mysqlcheckを使用するのが適切です。必要であれば、テーブルの健全性の問題を破棄し、修復できます。
1台のサーバーがLinuxボックスである可能性がありますか？ MysqlはLinuxでは大文字と小文字を区別しますが、Windowsでは区別しません。
これは、大文字を使用してテーブルを選択しようとしていて、テーブル名が小文字であったときに起こりました。
したがって、この質問を解決するために、my.cnfファイルに「lower_case_table_names = 1」を追加しました。
私はかつてこのような行動をしました。後に、使用したJDBCドライバーがクエリを小文字に変更したため、コードで正しい大文字と小文字を使用しているにもかかわらず、データベース（大文字と小文字が混在）にアクセスできないことがわかりました。
そのデータベース/テーブルを表示する権限を持っていないユーザーとしてログインしている場合、おそらくその結果が得られます。 mysqliを使用しているのと同じログインをコマンドラインで使用していますか？
InnoDBテーブルとMyISAMテーブルを一緒に持つことに関連している可能性があります。データベースファイルをコピーすると、MyISAMは問題なく、InnoDBは表示されますが機能しません。
Mysql 5.1とxfsファイルシステムを備えたcentos 6.4システムでこれを見てきました。
表は「表の表示」で表示されますが、選択または説明は、説明したように既存のメッセージではなく表で失敗します。ファイルは、私が期待する場所です。
システムは数か月間正常に動作していましたが、/ etc/my.cnfを変更してmysqldサービスを再起動し、table_cacheを256ではなく512に設定した後、横になりました。
Arcconfによると、RAIDコントローラーはすべてが正常であると考えています。 xfs_checkは何も検出しません。 IPMIのシステムイベントリストは明確です。 dmesgは、接続の追跡とパッケージのドロップに関するiptablesからの苦情を示しているので、DOSになった可能性がありますが、サーバー上で実際に外で実行しているものはないため、mysqlデータの整合性にどのように影響するかわかりませんか？
最終的にスレーブをマスターに昇格させてシステムをリロードしましたが、エラーの原因は何なのか、centos 6.4でのxfsの選択がまだ安定した選択なのか、犯人がmysql 5.1なのか疑問に思っています。
ああ、実行中のシステムを変更しないでください:)
Mac OS X？停止、まだ何もコピーしないでください...
私はこの問題をマーベリックで数回経験しました。 MySQLはもう含まれていませんが、私のインストールは、MAMPなどではなく、Snow Leopardで期待するものと基本的に同じです。
あるコンピューターから別のコンピューターに移行した後、この問題が発生しました。これは、コマンドラインで開始するのではなく、mysqldを開始するMySQLコントロールパネルの結果です。 （移行時に、このやや時代遅れのコントロールパネルは、起動時に起動しないように指示したことを忘れます。）
私のシステムのプロセス（トップまたはアクティビティモニター）を見てください。所有者がrootである場合、起動によって起動され、正常に動作しません。正しいプロセスの所有者は_mysqlになります。
時々、私は両方のプロセスを並べて実行しています！
奇妙なことに、コマンドライン経由でmysqlを使用するなど、すべてを行うことができます。ただし、innodbテーブルがリストされていても、クエリ時に存在しないエラーが生成されます。
これは所有権の問題のようで、他のシステムにも当てはまる場合があります。