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

Я изменил каталог данных установки MySQL, и все базы переместились правильно, кроме одной. Я могу подключить и USEбазу данных. SHOW TABLESтакже возвращает мне все таблицы правильно, и файлы каждой таблицы существуют в каталоге данных MySQL.

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

На тот случай, если кому-то все равно

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

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

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

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

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

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

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

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

SET FOREIGN_KEY_CHECKS=0;
SET FOREIGN_KEY_CHECKS=1;

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

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

$ sudo service mysql restart

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

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

SELECT * FROM `table`

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

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

Удачи.

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

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

1. Стоп новый WAMP

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

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

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

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

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

ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;

Скопировать idb-файл

ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;

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

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

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

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

Была похожая проблема с призрачной таблицей. К счастью, был дамп 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 из сбойной папки данных HD MySql в новую установленную папку данных mysql.

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

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

Затем сервер работает.

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

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

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

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

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

Решение:

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

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

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

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

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

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

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

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

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

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

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

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

Мой стол был как-то переименован в ' Customers'ie с пробелом

Это значило

а) запросы разбиты

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

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 и попробуйте снова.

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

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

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

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

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

innodb-page-size=65536

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