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 データ ディレクトリを から/var/lib/mysqlにコピーし、データベース フォルダ ( 、、など)/path/to/new/dirのみをコピーし、かつ innodb テーブルがある場合、innodb テーブルは「テーブルの表示」に表示されますが、それらのクエリ (および) は失敗します。 、エラー. db ディレクトリにファイルが表示され、その理由が不思議に思うでしょう。mysqlwpdbecommerceselectdescribeMysql error: table db.tableName doesn't exist.frm
ib*innodb テーブルの場合、ファイルをコピーすることが重要です。私の場合はibdata1、、、ib_logfile0およびib_logfile1. それらを確実にコピーして転送すると、すべてが期待どおりに機能しました。
my.cnf ファイルに「innodb_file_per_table」が含まれている場合、.ibd ファイルは db ディレクトリに存在しますが、依然として ib* ファイルが必要です。
この場合、mysqlcheck を使用するのが適切です。そのため、テーブルの健全性の問題を破棄し、必要に応じて修復することができます。
基本的に、私が経験していた問題は、パスワード ハッシュの長さが異なることが原因だったと思います。私の場合、新しいサーバーを取得し、パスワードとユーザー情報も転送する完全な mysql ダンプを実行しました。新しいサーバーは、16 文字の長さのハッシュを持つ root ユーザーで既に初期化されていましたが、古いサーバーは新しい 32 文字のハッシュ長を使用していました。
my.conf に移動して、古いパスワード設定を 0 に設定する必要がありました (そうしないと、データベースを更新しようとするたびに、新しい更新の長さが 16 文字になりました)。次に、コマンドを使用してすべてのパスワードを同じになるように更新し、UPDATE mysql.user SET password=PASSWORD('password here');特権をフラッシュしました。
明らかに、すべてのユーザーに同じパスワードを使用させるのは非常に悪い考えなので、機能していることを確認してから、1 つずつ変更しました。
この解決策にたどり着く前に、ここで機能しなかった他のいくつかのことを説明するブログエントリを入力しました（これらの変更の1つ以上が私の結果に影響を与えた場合に備えて）しかし、上記は解決策は完全ではありません...しかし、エラーを再現しようとしていないので、100％確実ではありません.
1 つのサーバーが Linux ボックスである可能性はありますか? Mysql では、Linux では大文字と小文字が区別されますが、Windows では区別されません。
私はかつてこのような行動をとったことがあります。後で、使用した JDBC ドライバーがクエリを小文字に変更したことを発見したため、コードは正しい混合文字を使用していましたが、データベース (大文字と小文字が混在していた) にアクセスできませんでした。
これは、mysql 5.1 と xfs ファイルシステムを備えた centos 6.4 システムで確認しました。
テーブルは「テーブルを表示」で表示されますが、説明したようにテーブルが存在しないというメッセージで選択または記述が失敗します。ファイルは、私が期待する場所にあります。
システムは何ヶ月も正常に動作していましたが、/etc/my.cnf を変更して table_cache を 256 ではなく 512 に設定した後にサービス mysqld を再起動した後、横向きになりました。
arcconf によると、RAID コントローラはすべて問題ないと考えています。xfs_check は何も検出しません。IPMI のシステム イベント リストは明確です。dmesg は、接続の追跡とパッケージの削除に関する iptables によるいくつかの苦情を示しているため、DOS を実行した可能性がありますが、実際にはサーバーの外部に面して何も実行されていないため、mysql データの整合性にどのように影響するかわかりません。
スレーブをマスターに昇格させてシステムをリロードすることになりましたが、何がエラーを引き起こしたのか、centos 6.4 での xfs の選択がまだ安定した選択なのか、それとも原因が mysql 5.1 なのか疑問に思っています。
そうそう、実行中のシステムを決して変更しないでください:)
そのデータベース/テーブルを表示する権限を持たないユーザーとしてログインしている場合は、おそらくその結果が得られます。コマンド ラインで mysqli を使用しているのと同じログインを使用していますか?
InnoDB と MyISAM テーブルを一緒に持つことに関連している可能性があります。データベース ファイルをコピーすると、MyISAM は問題なく、InnoDB は表示されますが、機能しません。