MySQL таблица не существует ошибка, но она существует
кто-нибудь знает при каких условиях вы можете получить 1146: Table '<database>.<table>' doesn't exist ошибка, когда ваша таблица действительно существует?
Я использую тот же код на 5 серверах, только один, который я недавно арендовал, показывает эту ошибку, поэтому я подозреваю, что это может быть ошибка настройки или установки. Я могу выполнить свою инструкцию sql из командной строки просто отлично. Очевидно, я могу видеть таблицу и из командной строки. Я не получаю никаких ошибок подключения, когда я устанавливаю соединение (я использую существует, кстати).
любая помощь будет оценили.
точный запрос:
$sql = "SELECT DISTINCT(mm_dic_word) AS word FROM spider.mm_dictionary WHERE mm_dic_deleted=0";
10 ответов
это просто случилось со мной, и через некоторое время я нашел ответ на статью в блоге, и хотел поставить его здесь.
если вы копируете каталог данных MySQL из /var/lib/mysql до /path/to/new/dir, но только копию папки базы данных (т. е. mysql, wpdb, ecommerce и т. д.), И у вас есть таблицы innodb, ваши таблицы innodb будут отображаться в "показать таблицы", но запросы к ним (select и describe) завершаются с ошибкой Mysql error: table db.tableName doesn't exist. Вы увидите .frm файл в каталоге БД, и удивляюсь почему.
для таблиц innodb важно скопировать через ib* файлов, которые в моем случае были ibdata1, ib_logfile0 и ib_logfile1. Как только я сделал передачу, убедившись, что скопировал их, все сработало так, как ожидалось.
если ваш мой.cnf файл содержит "innodb_file_per_table".ibd-файл будет присутствовать в каталоге db, но вам все равно нужны файлы ib*.
использование mysqlcheck было бы в порядке в этом случае-так что вы можете отбросить проблемы здравомыслия таблицы и восстановить их, если neeeded.
может ли быть, что ваш один сервер является Linux box? Mysql чувствителен к регистру в linux, но нечувствителен к windows.
в основном, я считаю, что проблема, которую я испытывал, была связана с разной длиной хэша пароля. В моем случае я получил новый сервер, сделал полный дамп mysql на нем, который также передавал пароли и информацию о пользователе. Новый сервер уже был инициализирован пользователем root с хэшем длины 16char, но мой старый сервер использовал более новые хэш-длины 32 char.
Я должен был пойти в мой.conf установил старые пароли в 0 (другой мудрый каждый раз, когда я пытался обновить база данных, новое обновление было длиной 16 символов). Затем я обновил все пароли, чтобы они были одинаковыми с помощью команды UPDATE mysql.user SET password=PASSWORD('password here');, затем я спустил привилегии.
очевидно, что иметь каждого пользователя с одним и тем же паролем-очень плохая идея, поэтому я изменил их один за другим после того, как подтвердил, что он работает.
Я набрал запись в блоге, которая входит в некоторые другие вещи, которые я сделал, которые не работали здесь, прежде чем я столкнулся с этим решением (на всякий случай один или больше этих изменений повлияло на мой результат) однако я думаю, что вышеупомянутое решение должно быть полным... но я не пытался воспроизвести ошибку, поэтому я не могу быть уверен на 100%.
однажды у меня было такое поведение. Позже я обнаружил, что драйвер JDBC, который я использовал, изменил мой запрос на нижний регистр, поэтому я не мог связаться с моей базой данных (которая использовала смешанные буквы), хотя мой код использовал правильные смешанные буквы.
Если вы вошли в систему как человек, у которого нет разрешения на просмотр этой базы данных/таблицы, вы, вероятно, получите этот результат. Вы используете тот же логин в командной строке, что и через mysqli?
Это может быть связано с наличием таблиц InnoDB и MyISAM вместе. Если вы скопируете файлы базы данных, MyISAM будет в порядке, и InnoDB появится, но не будет работать.
Я видел это в системе centos 6.4 с mysql 5.1 и файловой системой xfs.
таблицы показывают с "показать таблицы", но выбрать или описать не удается с таблицей не существующее Сообщение, Как вы описали. Файлы там, где я ожидал их найти.
система работала нормально в течение нескольких месяцев, затем после перезапуска службы mysqld после изменения /etc / my.cnf, чтобы установить table_cache на 512 вместо 256, он пошел боком.
согласно arcconf рейд контроллер думает, что все в порядке. xfs_check ничего не найти. система-события-список с IPMI-это понятно. dmesg показывает некоторые жалобы iptables на отслеживание соединений и удаление пакетов, поэтому мы, возможно, были DOS'D, но поскольку на сервере ничего не работает, я не вижу, как это может повлиять на целостность данных mysql?
Я закончил продвижение раба к хозяину и перезагрузку системы, и теперь мне интересно, что могло вызвать ошибку, и если выбор xfs на centos 6.4 по-прежнему является стабильным выбором, или если виновником был mysql 5.1.
О да и никогда не меняйте работающую систему:)
Mac OS X? Стоп, пока ничего не переписывай...
У меня была эта проблема пару раз на Маверикс. MySQL больше не включен, но моя установка по существу такая же, как и то, что вы ожидаете найти на Snow Leopard, я думаю, а не MAMP или что-то еще.
после перехода с одного компьютера на другой у меня возникла эта проблема. Это было результатом запуска mysqld панели управления MySQL, а не моего запуска его в командной строке. (При миграции это несколько устаревшая панель управления забывает, что вы сказали ей не запускаться при загрузке.)
посмотрите на процессы (top или activity monitor) в моей системе: если владелец root, он был запущен запущенным и не работает должным образом; правильный процесс будет иметь _mysql в качестве владельца.
иногда у меня оба процесса работают бок о бок!
Как ни странно, вы можете делать все, включая использование mysql через командную строку. Однако, хотя InnoDB таблицы перечислены они создают не существует ошибки при запросе.
Это, по-видимому, проблема собственности, которая может применяться и к другим системам.
Это произошло со мной, когда я пытался выбрать таблицу, используя верхний регистр, а имя таблицы было строчным.
Итак, чтобы решить этот вопрос, я поставил "lower_case_table_names=1" на моем.cnf файл.