MySQL ›Таблица не существует. Но это так (или должно)

На всякий случай кому все равно:

У меня была такая же проблема после копирования каталога базы данных напрямую с помощью команды

cp -r /path/to/my/database /var/lib/mysql/new_database

Если вы сделаете это с базой данных, которая использует InnoDB таблицы, вы получите эту сумасшедшую ошибку «таблица не существует», упомянутая выше.

Проблема в том, что вам нужны файлы ib* в корне каталога данных MySQL (например, ibdata1, ib_logfile0 и ib_logfile1).

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

Для меня в Mac OS (установка MySQL DMG) простая перезагрузка сервера MySQL решила проблему. Я предполагаю, что причиной этого была гибернация.

У меня возникает эта проблема, когда регистр имени таблицы, которую я использую, выключен. Итак, таблица называется «db», но я использовал «DB» в операторе выбора. Убедитесь, что случай такой же.

Эта ошибка также может возникать при установке lower_case_table_names в 1, а затем при попытке доступа к таблицам, которые были созданы со значением по умолчанию для этой переменной. В этом случае вы можете вернуть его к предыдущему значению, и вы сможете читать таблицу.

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

Запустите запрос:

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 и непечатаемые символы в имени таблицы. Если вы создали свои таблицы, скопировав код создания из какого-либо документа / веб-сайта, есть вероятность, что где-то есть пространство нулевой ширины.

Я не знаю причины, но в моем случае я решил просто отключить и включить проверку внешних ключей

SET FOREIGN_KEY_CHECKS=0;
SET FOREIGN_KEY_CHECKS=1;

У меня была такая же проблема, и я искал 2-3 дня, но решение для меня было действительно глупым.

Перезагрузите mysql

$ sudo service mysql restart

Теперь таблицы стали доступны.

Я только что провел в этом кошмаре три дня. В идеале у вас должна быть резервная копия, которую можно восстановить, а затем просто удалить поврежденную таблицу. Ошибки такого рода могут привести к тому, что ваш ibdata1 станет огромным (более 100 ГБ для небольших таблиц)

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

Итак, в качестве обходного пути перейдите к /var/log/mysql/database_name/ и удалите table_name. *

Тогда сразу попробуйте сбросить таблицу; теперь это должно работать. Теперь восстановите базу данных в новую базу данных и восстановите недостающие таблицы. Затем сделайте дамп сломанной базы данных.

В нашем случае мы также постоянно получали mysql has gone away сообщения через случайные промежутки времени во всех базах данных; как только поврежденная база данных была удалена, все вернулось в норму.

Ok. это прозвучит довольно абсурдно, но посмешите меня.
Для меня проблема была решена, когда я изменил свое утверждение на это:

SELECT * FROM `table`

Я сделал два изменения
1.) Сделал имя таблицы в нижнем регистре - я знаю !!
2.) Использовал специальный символ кавычки = `: это клавиша над вашей TAB

Решение действительно звучит абсурдно, но оно сработало, и сейчас субботний вечер, а я работаю с 9 утра - так что возьму :)

Удачи.

Попробуйте запустить sql-запрос, чтобы отбросить табличное пространство перед копированием idb-файла:

ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;

Скопируйте idb-файл

ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;

Перезапустите MySql

Что сработало для меня, так это просто отбросить стол, хотя его не было. Затем я воссоздал таблицу и заново заполнил ее из ранее сделанного дампа sql.

Должна быть какая-то метабаза имен таблиц, и, скорее всего, она все еще существовала, пока я ее не отбросил.

У меня возникла эта проблема после обновления WAMP, но без резервной копии базы данных.

Это сработало для меня:

1. Остановить новый WAMP

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

3. Удалить ib_logfile0 и ib_logfile1

4. Запустить WAMP

Теперь вы должны иметь возможность делать резервные копии своих баз данных. Однако после повторного перезапуска сервера у вас все еще будут проблемы. Итак, переустановите WAMP и импортируйте свои базы данных.

После переустановки MySQL у меня возникла та же проблема, кажется, что во время установки некоторые файлы конфигурации, в которых хранятся данные о файлах журнала InnoDB, эти файлы ib_logfile * (они же файлы журнала, верно?) Перезаписываются. Чтобы решить эту проблему, я просто удалил файлы ib_logfile *.

Была аналогичная проблема с призрачной таблицей. К счастью, был дамп SQL до сбоя.

В моем случае мне пришлось:

1. Остановить mySQL
2. Переместить файлы ib * из /var/mysql в резервную копию
3. Удалить /var/mysql/{dbname}
4. Перезагрузите mySQL
5. Восстановить пустую базу данных
6. Восстановить файл дампа

ПРИМЕЧАНИЕ. Требуется файл дампа.

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;

Я установил MariaDB на новый компьютер, остановил службу Mysql, переименовав папку данных в данные - я решил свою проблему, копируя только Mysql \ data \ table_folders и ibdata1 из разбитой папки данных MySql HD в новая установленная папка данных mysql.

Я пропустил ib_logfile0 и ib_logfile1 (иначе сервер не запустил службу)

Запущен сервис mysql.

Тогда сервер запущен.

Похоже, что проблема связана (по крайней мере, в моем и некоторых других) с недопустимыми (поврежденными?) Файлами журнала innodb. Вообще говоря, их просто нужно воссоздать.

Вот решения, большинство из которых требует перезапуска mysql.

• Восстановите файлы журнала (Удалить и перезапустить mysql)
• Измените размер файлов журнала (MySql 5.6+ восстановит файл для тебя)
• Если вы выполняете какой-либо тип миграции данных, убедитесь, что вы правильно перенесли правильный файл и предоставили ему разрешения, как уже заявили другие.
• Проверьте разрешения ваших файлов данных и журналов, что mysql является владельцем обоих
• Если все остальное не поможет, вам, вероятно, придется воссоздать базу данных.

Вот еще один сценарий (обновление версии):

Я переустановил свою ОС (Mac OS El Captain) и установил новую версию mysql (используя homebrew). Установленная версия (5.7) оказалась новее моей предыдущей. Затем я скопировал таблицы, включая файлы ib *, и перезапустил сервер. Я мог видеть таблицы в рабочей среде mysql, но когда я пытался выбрать что-нибудь, я получил «Таблица не существует».

Решение:

1. остановить сервер mysql, например. mysql.server stop или brew services stop mysql
2. запустите сервер с помощью mysqld_safe --user=mysql --datadir=/usr/local/var/mysql/ (при необходимости измените путь)
3. запустить mysql_upgrade -u root -p password (в другом окне терминала)
4. выключите работающий сервер mysqladmin -u root -p password shutdown
5. перезапустите сервер в обычном режиме mysql.server start или brew services start mysql

Соответствующие документы находятся здесь.

В моем случае я определил триггер в таблице, а затем пытался вставить строку в таблицу. похоже, что-то триггер был ошибочным, и, следовательно, вставка выдает ошибку, таблица не существует.

Скопируйте только ibdata1 файл из старого каталога данных. Не копируйте ib_logfile1 или ib_logfile0 файлы. Это приведет к тому, что MySQL больше не будет запускаться.

Сегодня возникла такая же проблема. Это проблема mysql «Чувствительность к регистру идентификатора».

Пожалуйста, проверьте соответствующий файл данных. Очень вероятно, что имя файла в файловой системе находится в нижнем регистре, но имя таблицы, указанное в команде "show tables", находится в верхнем регистре. Если системная переменная «lower_case_table_names» равна 0, запрос вернет «таблица не существует», поскольку при сравнении имен учитывается регистр, когда «lower_case_table_names» равно 0.

Возможно, у вас есть скрытый символ в имени вашей таблицы. Они не появляются, когда вы устраиваете шоу-столы. Можете ли вы сделать «SHOW CREATE TABLE TABLE_ONE» и заполнить вкладку «TABLE_ONE» и посмотреть, вставляет ли он какие-либо скрытые символы. Кроме того, пробовали ли вы отбрасывать и переделывать таблицы. Просто чтобы убедиться, что с привилегиями все в порядке и нет скрытых символов.

Та же самая проблема после импорта резервной копии TimeMachine. Мое решение заключалось в том, чтобы остановить сервер MySQL и исправить разрешения на чтение и запись для файлов ib *.

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

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

Вроде очевидная вещь для новичков, но такие вещи, как «пользователь» против «пользователей», могут сбивать с толку людей, и я подумал, что было бы полезно указать здесь в списке. :)

В моем случае, когда я импортировал экспортированный файл sql, я получал сообщение об ошибке, будто таблица не существует для запроса создания таблицы.

Я понял, что в имени моей базы данных есть символ подчеркивания, а mysql ставит escape-символ непосредственно перед этим.

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

Надеюсь, это поможет и кому-то другому.

Моя таблица каким-то образом была переименована в ' Customers', то есть с начальным пробелом

Это значило

а) запросы сломались

б) таблица не появилась там, где ожидалось, в алфавитном порядке моих таблиц, что в моем панике означало, что я не мог ее увидеть!

RENAME TABLE ` Customer` TO `Customer`;

В моем случае это был параметр 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)

Не используйте пробелы в четвертях. Спасибо моему коллеге Яну.

Перейдите к: xampp\mysql\data\dbname
внутри dbname есть файл tablename.frm и tablename.ibd.
удалите его, перезапустите mysql и повторите попытку.

У меня была такая же проблема в окнах. В дополнение к копированию файлов ib * и каталога mysql в каталог данных thd мне также пришлось сопоставить файл my.ini.

В файле my.ini из моей предыдущей установки не было следующей строки:

innodb-page-size=65536

Но моя новая установка сработала. Возможно, потому, что у меня не было этой опции в старом установщике. Я удалил это и перезапустил службу, и таблицы работали, как ожидалось. Короче говоря, убедитесь, что новый файл my.ini является копией старого, за исключением каталога данных, каталога подключаемых модулей и номера порта, в зависимости от вашей новой установки.

У меня была такая же проблема, но не из-за скрытого персонажа или «таблицы Шредингера». Проблема (точно такая, как указано выше) появилась после процесса восстановления. Я использую MySQL с администратором версии 1.2.16. Когда необходимо выполнить восстановление, вы должны снять флажок ORIGINAL в целевой схеме и выбрать имя своей базы данных из раскрывающегося списка. После этого проблема была устранена. По крайней мере, это было причиной в моей базе данных.

Если в имени таблицы есть точка, она не будет выполнена для SELECT * FROM poorly_named.table;

Используйте обратные кавычки, чтобы найти таблицу SELECT * FROM `poorly_named.table`;

В моем случае это было без перемещения каталога данных или каких-либо манипуляций с файлами. Это случилось одним прекрасным утром.

Так как, как ни странно, я смог выгрузить таблицу с помощью mysqldump, несмотря на то, что MySQL иногда жаловался на то, что «таблица не существует», я решил это, выгрузив схему + данные таблицы, затем DROP-ing таблицы и повторно СОЗДАЙТЕ его сразу после, а затем импортируйте.