В MySQL Table нет ошибки, но она существует

Ответ 1

В принципе, я считаю, что проблема, с которой я столкнулся, связана с различием длин хэш-кода. В моем случае у меня появился новый сервер, на нем был полный дамп mysql, который также передавал пароли и информацию о пользователе. Новый сервер уже был инициализирован корневым пользователем с хэш-длиной 16char, но мой старый сервер использовал более длинные длины хэшей 32 char.

Мне пришлось зайти в my.conf, чтобы установить старые настройки паролей в 0 (другой разумный каждый раз, когда я пытался обновлять базу данных, новое обновление было 16 символов в длину). Затем я обновил все пароли, чтобы они были одинаковыми с помощью команды UPDATE mysql.user SET password=PASSWORD('password here');, затем я сбросил привилегии.

Очевидно, что каждый пользователь с одним и тем же паролем - действительно плохая идея, поэтому я поменял их один за другим после того, как подтвердил, что он работает.

Я набрал запись в блоге, которая затрагивает некоторые другие вещи, которые я сделал, которые не работали здесь, прежде чем я столкнулся с этим решение (на случай, если один или несколько из этих изменений повлияли на мои результаты), однако я думаю, что вышеупомянутое решение будет полным... но я не пытался воспроизвести ошибку, поэтому я не могу быть на 100% уверен.

Ответ 2

Это произошло со мной, и через некоторое время я нашел ответ в статье в блоге и захотел поместить его здесь.

Если вы скопируете каталог данных 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. Вы увидите файл .frm в каталоге db и задаетесь вопросом, почему.

Для таблиц innodb важно скопировать файлы ib*, которые в моем случае были ibdata1, ib_logfile0 и ib_logfile1. Как только я сделал передачу, чтобы скопировать их, все сработало, как ожидалось.

Если ваш файл my.cnf содержит "innodb_file_per_table", файл .ibd будет присутствовать в каталоге db, но вам все равно нужны файлы ib *.

Ответ 3

Использование mysqlcheck было бы в порядке в этом случае, поэтому вы можете отказаться от проблем со столами и восстановить их, если они были заменены.

Ответ 4

Может ли быть, что ваш один сервер - это linux box? Mysql чувствителен к регистру на linux, но нечувствителен к окнам.

Ответ 5

У меня было такое поведение один раз. Позже я обнаружил, что драйвер JDBC, который я использовал, изменил мой запрос на нижний регистр, поэтому я не смог связаться с моей базой данных (с использованием смешанных букв), хотя мой код использовал правильные смешанные буквы.

Ответ 6

Если вы вошли в систему как человек, у которого нет разрешения на просмотр этой базы данных/таблицы, вы, вероятно, получите этот результат. Вы используете тот же логин в командной строке, что и в mysqli?

Ответ 7

Это может быть связано с таблицами InnoDB и MyISAM. Если вы скопируете файлы базы данных, MyISAM будет в порядке, и InnoDB появится, но не сработает.

Ответ 8

Я видел это в системе centos 6.4 с mysql 5.1 и файловой системой xfs.

Таблицы показывают с помощью "show tables", но выбор или описание не выполняется с табличным отсутствующим сообщением, как вы описали. Файлы там, где я их ожидаю.

Система работала отлично в течение нескольких месяцев, а затем после перезагрузки службы mysqld после изменения /etc/my.cnf, чтобы установить table_cache на 512 вместо 256, она пошла боком.

Согласно arcconf, контроллер рейда считает, что все в порядке. xfs_check ничего не находит. системный список событий IPMI понятен. dmesg показывает некоторые жалобы iptables на отслеживание соединений и удаление пакетов, поэтому мы, возможно, были DOS'd, но поскольку на сервере нет ничего действительно запущенного снаружи, я не вижу, как это может повлиять на целостность данных mysql?

Я закончил продвигать ведомый, чтобы освоить и перезагрузить систему, и теперь мне интересно, что могло вызвать ошибку, и если выбор xfs на centos 6.4 по-прежнему является стабильным выбором, или если виновником был mysql 5.1.

О да, и никогда не меняйте запущенную систему:)

Ответ 9

Mac OS X? STOP, ничего не возвращайте...

У меня была эта проблема пару раз на Mavericks. MySQL больше не включен, но моя установка по сути такая же, как вы, вероятно, найдете на Snow Leopard, а не в MAMP или что-то в этом роде.

После миграции с одного компьютера на другой у меня возникла эта проблема. Это было результатом того, что панель управления MySQL запускает mysqld, а не запускает ее в командной строке. (При переносе эта несколько устаревшая панель управления забывает, что вы сказали ей НЕ запускать при загрузке.)

Посмотрите на процессы (верхний или монитор активности), в моей системе: если владелец является root, он запускается запущенным и не работает должным образом; правильный процесс будет иметь _mysql как владельца.

Иногда у меня есть оба процесса, работающие бок о бок!

Как ни странно, вы можете делать все, включая использование mysql через командную строку. Однако, несмотря на то, что перечислены таблицы innodb, они генерируют ошибку при отсутствии запросов.

Это, похоже, проблема с владением, которая может применяться и к другим системам.