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

  1. остановить MySQL
  2. резервная копия папки mysql: cp -a/var/lib/mysql/var/lib/mysql-backup
  3. скопировать папку базы данных со старой машины в /var/lib/mysql
  4. переопределить ib * (ib_logfile *, ibdata) из старой базы данных
  5. начать MySQL
  6. свалка базы данных
  7. mysqldump >dbase.mysql
  8. остановить службу MySQL
  9. удалить /var/lib/mysql
  10. переименуйте /var/lib/mysql-backup в /var/lib/mysql
  11. начать MySQL
  12. создать базу данных
  13. 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

  • Скопируйте нужные каталоги базы данных и файл ibdata1 из старой установки WAMP

  • Удалить ib_logfile0 и ib_logfile1

  • Запустите 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

  1. Сделать mysqldump в базу данных:

    mysqldump -u user -ppass dbname > D:\Back-ups\dbname.sql
    
  2. Восстановить базу данных

    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 в целевой схеме и выбрать имя своей базы данных из раскрывающегося списка. После этого проблема была исправлена. По крайней мере, это была причина в моей базе данных.