MySQL> Таблица не существует. Но он (или должен)
Я изменил datadir установки MySQL, и после нескольких шагов он работал нормально. Каждая базовая база была перемещена правильно, но одна.
Я могу подключиться и использовать базу данных, даже SHOW TABLES вернет мне все таблицы правильно и файлы каждой таблицы существуют в каталоге данных mysql. Но когда я пытаюсь выбрать что-то там, он говорит, что таблица не существует. Но таблица существует, она даже отображается в инструкции 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
Ответы
Ответ 1
На всякий случай все еще заботятся:
У меня была такая же проблема после копирования каталога базы данных напрямую с помощью команды
cp -r /path/to/my/database /var/lib/mysql/new_database
Если вы делаете это с помощью базы данных, которая использует таблицы InnoDB
, вы получите эту сумасшедшую ошибку "таблица не существует", упомянутую выше.
Проблема в том, что вам нужны файлы ib*
в корневом каталоге MySQL datadir (например, ibdata1
, ib_logfile0
и ib_logfile1
).
Когда я скопировал те, это сработало для меня.
Ответ 2
Для меня в Mac OS (MySQL DMG Installation) простой перезапуск сервера MySQL решил проблему. Я предполагаю, что гибернация вызвала это.
Ответ 3
Я получаю эту проблему, когда случай для имени таблицы, который я использую, отключен. Таким образом, таблица называется "db", но я использовал "DB" в select statement. Убедитесь, что корпус тот же.
Ответ 4
Эта ошибка также может возникать при настройке lower_case_table_names
на 1
, а затем попытки доступа к таблицам, которые были созданы со значением по умолчанию для этой переменной. В этом случае вы можете вернуть его к предыдущему значению, и вы сможете прочитать таблицу.
Ответ 5
- остановить MySQL
- резервная копия папки mysql:
cp -a/var/lib/mysql/var/lib/mysql-backup
- скопировать папку базы данных со старой машины в
/var/lib/mysql
- переопределить ib * (ib_logfile *, ibdata) из старой базы данных
- начать MySQL
- свалка базы данных
-
mysqldump >dbase.mysql
- остановить службу MySQL
- удалить
/var/lib/mysql
- переименуйте
/var/lib/mysql-backup
в /var/lib/mysql
- начать MySQL
- создать базу данных
-
mysqldump < dbase.mysql
Ответ 6
Запустите запрос:
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 и non-printable в имени таблицы.
Если вы создали свои таблицы, скопировав код с какого-либо документа/веб-сайта, есть вероятность, что он имеет нулевое пространство.
Ответ 7
Я просто провел три дня на этом кошмаре. В идеале у вас должна быть резервная копия, которую вы можете восстановить, а затем просто опустите поврежденную таблицу. Подобные ошибки могут привести к тому, что ваш ibdata1 станет огромным (размер 100 ГБ + для скромных таблиц)
Если у вас нет недавней резервной копии, например, если вы полагались на mySqlDump, то ваши резервные копии, вероятно, в какой-то момент в прошлом проваливались. Вам нужно будет экспортировать базы данных, которые, конечно, вы не можете сделать, потому что при запуске mySqlDump вы получите ошибки блокировки.
Итак, в качестве обходного пути перейдите к /var/log/mysql/database_name/
и удалите имя_таблицы. *
Затем немедленно попытайтесь сбросить таблицу; это должно теперь работать. Теперь восстановите базу данных в новой базе данных и перестройте отсутствующие таблицы. Затем выгрузите разбитую базу данных.
В нашем случае мы также постоянно получали сообщения mysql has gone away
через случайные интервалы во всех базах данных; как только поврежденная база данных была удалена, все стало нормальным.
Ответ 8
У меня была та же проблема, и я искал 2-3 дня, но решение для меня было действительно глупо.
Перезагрузите mysql
$ sudo service mysql restart
Теперь становятся доступными таблицы.
Ответ 9
Попробуйте выполнить sql-запрос для удаления табличного пространства перед копированием idb файла:
ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;
Скопируйте idb файл
ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;
Перезапустите MySql
Ответ 10
O.k. это будет звучать довольно абсурдно, но юмор меня.
Для меня проблема решена, когда я изменил свое выражение на следующее:
SELECT * FROM `table`
Я сделал два изменения
1.) Сделал нижний регистр названия таблицы - я знаю!!
2.) Используется специальный символ цитаты = `: это ключ над вашей табуляцией
Решение звучит абсурдно, но это сработало, и в субботу вечером, и я работаю с 9 утра. Поэтому я возьму его:)
Удачи.
Ответ 11
Я не знаю причины, но в моем случае я решил просто отключить и включить проверку внешних ключей
SET FOREIGN_KEY_CHECKS=0;
SET FOREIGN_KEY_CHECKS=1;
Ответ 12
У меня возникла эта проблема после обновления WAMP, но без резервного копирования базы данных.
Это сработало для меня:
Теперь вы сможете создавать резервные копии своих баз данных. Однако после перезагрузки сервера у вас все еще будут проблемы. Теперь переустановите WAMP и импортируйте свои базы данных.
Ответ 13
После переустановки MySQL у меня возникла такая же проблема, кажется, что во время установки некоторые файлы конфигурации, в которых хранятся данные о файлах журнала InnoDB, эти файлы ib_logfile * (они являются файлами журнала справа?), перезаписываются. Чтобы решить эту проблему, я просто удалил файлы ib_logfile *.
Ответ 14
Была аналогичная проблема с таблицей призраков. К счастью, у SQL-дампа произошел сбой.
В моем случае мне пришлось:
- Остановить mySQL
- Перенесите ib * файлы из
/var/mysql
в резервную копию
- Удалить
/var/mysql/{dbname}
- Перезагрузка mySQL
- Восстановить пустую базу данных
- Восстановить файл дампа
ПРИМЕЧАНИЕ. Требуется файл дампа.
Ответ 15
То, что сработало для меня, просто отбросило таблицу, хотя она не существовала. Затем я создал таблицу и заново заполнил сделанный ранее sql файл.
Должна быть какая-то метабаза имен таблиц, и она, скорее всего, все еще существует там, пока я ее не уронил.
Ответ 16
Я установил MariaDB на новый компьютер,
остановил услугу Mysql
переименованную папку данных в data-
Я решил решить проблему
Mysql\data\table_folders и ibdata1
от разбитых данных HD MySql Папка в новую установленную папку данных mysql.
Я пропустил ib_logfile0 и ib_logfile1 (в противном случае сервер не запускал сервис)
Запустил службу mysql.
Затем сервер работает.
Ответ 17
Похоже, что проблема должна выполняться (по крайней мере, у меня и нескольких других) с недопустимыми (поврежденными?) файлами журнала innodb. Вообще говоря, их просто нужно воссоздать.
Вот решения, большинство из которых требуют перезагрузки mysql.
- Восстановите файлы журнала (Удалить и перезапустить mysql)
- Измените размер файлов журнала (MySql 5.6+ восстановит файл для вас)
- Если вы выполняете миграцию данных определенного типа, убедитесь, что вы правильно перенесли нужный файл и дали ему разрешения, как уже указывали другие.
- Проверьте разрешения ваших данных и файлов журналов, что mysql является владельцем обоих
- Если все остальное не работает, вам, вероятно, придется воссоздать базу данных
Ответ 18
Вот еще один сценарий (обновление версии):
Я переустановил свою ОС (Mac OS El Captain) и установил новую версию mysql (используя homebrew). Установленная версия (5.7) оказалась более новой, чем предыдущая. Затем я скопировал таблицы, включая файлы ib *, и перезапустил сервер. Я мог видеть таблицы в workbench 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
Соответствующие документы здесь.
Ответ 19
В моем случае я определил триггер для таблицы, а затем пытался вставить строку в таблицу. похоже, каким-то образом триггер был ошибочным, и, следовательно, вставка выдавала ошибку, таблица не существует.
Ответ 20
-
Сделать 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;
Ответ 21
Возможно, у вас есть скрытый символ в имени вашей таблицы. Они не отображаются, когда вы показываете таблицы. Можете ли вы сделать "SHOW CREATE TABLE TABLE_ONE" и вкладку заполнить "TABLE_ONE" и посмотреть, содержит ли она какие-либо скрытые символы. Кроме того, вы попытались сбросить и переделать таблицы. Просто чтобы убедиться, что с привилегиями ничего нет, и что скрытых символов нет.
Ответ 22
В моем случае это был параметр SQLCA.DBParm
.
Я использовал
SQLCA.DBParm = "Databse = "sle_database.text""
но это должно быть
SQLCA.DBParm = "Database='" +sle_database.text+ "'"
Объяснение:
Вы собираетесь объединить три строки:
1. Database=' - "Database='"
2. (name of the database) - +sle_database.text+
3. ' - "'" (means " ' " without space)
Не используйте пробелы в quatermarks.
Спасибо моему коллеге Ян.
Ответ 23
Точная проблема после импорта резервной копии TimeMachine. Мое решение состояло в том, чтобы остановить сервер MySQL и исправить права на чтение и запись в файлах ib *.
Ответ 24
Еще один ответ, который, я думаю, стоит здесь подняться (потому что я пришел сюда с той же проблемой, и это оказалось для меня ответом):
Дважды проверьте, что имя таблицы в вашем запросе написано точно так же, как и в базе данных.
Вид очевидной новички, но такие вещи, как "пользователь" и "пользователи" , могут отключать людей, и я подумал, что это будет полезный ответ, который есть в списке здесь.:)
Ответ 25
В моем случае, когда я импортировал экспортированный sql файл, я получал ошибку, так как таблица не существует для запроса таблицы create.
Я понял, что в имени моей базы данных есть символ подчеркивания, а mysql перед тем как он запускает escape-символ.
Итак, я удалил это подчеркивание в имени базы данных, все получилось.
Надеюсь, что это тоже поможет кому-то другому.
Ответ 26
Моя таблица каким-то образом была переименована в ' Customers'
, т.е. с ведущим пространством
Это означало
a) запросы сломались
b) таблица не появилась там, где ожидалось в алфавитном порядке моих таблиц, что в моей панике означало, что я не мог ее увидеть!
RENAME TABLE ` Customer` TO `Customer`;
Ответ 27
Перейдите по ссылке: xampp\mysql\data\dbname
внутри dbname есть файл tablename.frm и tablename.ibd.
удалить его
и перезапустите mysql и повторите попытку.
Ответ 28
Скопируйте только файл ibdata1
из старого каталога данных. Не ib_logfile0
файлы ib_logfile1
или ib_logfile0
. Это приведет к тому, что MySQL больше не будет запускаться.
Ответ 29
Пришла сегодня одна и та же проблема. Это mysql "Чувствительность к регистру идентификатора".
Пожалуйста, проверьте соответствующий файл данных. Весьма вероятно, что имя файла в файловой системе в нижнем регистре, а имя таблицы, указанное в команде "show tables", в верхнем регистре. Если системная переменная " lower_case_table_names
" равна 0, запрос возвратит "таблица не существует", потому что сравнения имен чувствительны к регистру, когда " lower_case_table_names
" равно 0.
Ответ 30
У меня была та же проблема, но это было не из-за скрытого символа или "таблицы schroedinger". Проблема (как указано выше) появилась после восстановления. Я использую администратор MySQL версии 1.2.16. Когда восстановление должно быть выполнено, вы должны снять флажок ORIGINAL
в целевой схеме и выбрать имя своей базы данных из раскрывающегося списка. После этого проблема была исправлена. По крайней мере, это была причина в моей базе данных.