MySQL> Таблиця не існує. Але це (або повинно)

Я змінив datadir інсталяції 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 datadir (наприклад ibdata1, ib_logfile0і ib_logfile1).

Коли я скопіював ті, то це працювало на мене.

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

Цю проблему я отримую, коли справа для імені таблиці, яку я використовую, вимкнена. Отже, таблиця називається 'db', але я використовував 'DB' у операторі select. Переконайтесь, що справа однакова.

Ця помилка може також виникнути при установці 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 та недруковані у назві таблиці. Якщо ви створили таблиці, скопіювавши код створення з якогось документа / веб-сайту, є ймовірність, що він десь має нульову ширину.

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

Якщо у вас немає недавнього резервного копіювання, наприклад, якщо ви покладалися на mySqlDump, ваші резервні копії, ймовірно, мовчки зламалися в якийсь момент минулого. Вам потрібно буде експортувати бази даних, що, звичайно, ви не можете зробити, тому що ви отримаєте помилки блокування під час роботи mySqlDump.

Отож, як вирішення, перейдіть до /var/log/mysql/database_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.) Використовується специфічний символ цитати = ` : Це ключ над TAB

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

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

Почався сервіс mysql.

Потім сервер працює.

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

Ось рішення, більшість з яких потребує перезавантаження mysql.

• Відтворення файлів журналу ( Видалити та перезапустити mysql )
• Змініть розмір файлів журналу (MySql 5.6+ поновлює файл для вас)
• Якщо ви робите певний тип міграції даних, переконайтеся, що ви правильно перемістили потрібний файл і дали йому дозволи, як уже заявили інші
• Перевірте дозволи на свої дані та файли журналів, що mysql є власником обох
• Якщо все інше не вдасться, вам, ймовірно, доведеться відтворити базу даних

Ось ще один сценарій (оновлення версії) :

Я перевстановив ОС (Mac OS El Captain) і встановив нову версію mysql (використовуючи домашню мову). Встановлена ​​версія (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 проставляє символ втечі.

Тож я усунув цю підкреслення в імені бази даних, і все спрацювало.

Сподіваюся, що це допоможе і комусь іншому.

Мій стіл якимось чином було перейменовано на ' 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 та повторіть спробу.

Скопіюйте лише ibdata1файл зі старого каталогу даних. Не копіюйте ib_logfile1та не ib_logfile0файли. Це призведе до того, що MySQL більше не запускається.

Сьогодні вирішилася така ж проблема. Це питання mysql "Ідентифікатор чутливості до регістру".

Перевірте відповідний файл даних. Цілком імовірно, що ім'я файлу є нижчим регістром у файловій системі, але ім'я таблиці, вказане в команді "показати таблиці", є великим регістром. Якщо системна змінна " 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, плагін-dir та порт #, залежно від вашої нової установки.