Таблиця MySQL Schrödingers: існує, але це не так

У мене найдивніша помилка з усіх.

Іноді, створюючи або змінюючи таблиці, я отримую помилку "таблиця вже існує". Однак DROP TABLE повертає "# 1051 - невідома таблиця". Отже, я отримав таблицю, яку я не можу створити, не можу скинути.

Коли я намагаюся скинути базу даних, MySQL виходить з ладу. Іноді це допомагає створити ще один db з іншою назвою, іноді це не так.

Я використовую БД з ~ 50 таблицями, всі InnoDB. Ця проблема виникає з різними таблицями.

Я відчував це в Windows, Fedora та Ubuntu, MySQL 5.1 та 5.5. Така ж поведінка при використанні PDO, PHPMyAdmin або командного рядка. Я використовую MySQL Workbench для управління моєю схемою - я бачив деякі пов'язані з цим помилки (кінцеві лінії та інші речі), проте жодна з них не була для мене актуальною.

Ні, це не вид, це стіл. Усі назви мають малі літери.

Я спробував усе, що міг в google - промивання таблиць, переміщення файлів .frm з db в db, читання журналу mysql, нічого не допомогло, але перевстановити всю прокляту річ.

"Показати таблиці" нічого не виявляє, "описувати" в таблиці йдеться, що "таблиця не існує", немає файлу .frm, але "створити таблицю" все ще закінчується помилкою (і так "створити таблицю, якщо її немає") і випадання збоїв бази даних mysql

Питання, пов’язані з цим, але ще не корисні:

• Mysql 1050 Помилка "Таблиця вже існує", коли насправді це не так

• MySQL Таблиця не існує помилки, але вона існує

Редагувати:

mysql> use askyou;
Database changed

mysql> show tables;
Empty set (0.00 sec)

mysql> create table users_has_friends (id int primary key);
ERROR 1050 (42S01): Table '`askyou`.`users_has_friends`' already exists

mysql> drop table users_has_friends;
ERROR 1051 (42S02): Unknown table 'users_has_friends'

І все одно: таблиця не існує, але її неможливо створити;

mysql> drop database askyou;
ERROR 2013 (HY000): Lost connection to MySQL server during query

Імена змінюються, це не єдина таблиця / база даних, з якою у мене виникли проблеми

Я бачив цю проблему, коли в каталозі даних відсутній файл даних, але файл визначення таблиці існує або навпаки. Якщо ви використовуєте innodb_file_per_table, перевірте каталог даних, щоб переконатися, що у вас є і .frmфайл, і .ibd файл для відповідної таблиці. Якщо це MYISAM, має бути і файл .frm, .MYIі .MYDфайл.

Проблему зазвичай можна вирішити, видаливши осиротілий файл вручну.

Тут йдеться про дикі здогадки, але, схоже, у innodb все ще є запис для ваших таблиць у просторі таблиць, ймовірно, у ibdata. Якщо ви дійсно не потрібні якісь - або з даних, або якщо у вас є резервні копії, спробуйте наступне:

1. Видалити всі схеми (крім mysql)
2. закрити базу даних
3. Переконайтесь, що всі папки у вашому каталозі даних були видалені належним чином (знову ж таки, виключаючи mysql)
4. видалити файли ibdata та журналу
5. перезавантажте базу даних. Він повинен відтворити простір таблиць і журнали з нуля.

Виправлення виявляється легким; принаймні те, що я працював, працював для мене. Створіть таблицю "zzz" в іншому екземплярі MySQL, де zzz - назва проблемної таблиці. (тобто, якщо таблиця називається schrodinger, замініть її на zzz, коли написано.) Не має значення, що таке визначення таблиці. Це тимчасова пустушка; Скопіюйте файл zzz.frm в каталог баз даних на сервері, де має бути таблиця, переконайтесь, що право власності на файл та його права все ще є правильними. На MySQL тепер ви можете зробити "показати таблиці;", і таблиця zzz буде там. mysql> drop table zzz; ... зараз має працювати. При необхідності очистіть усі файли zzz.MYD або ZZZ.MYI в каталозі.

Я сумніваюся, що це пряма відповідь на тут питання, але ось як я вирішив цю точно сприйняту проблему в моїй системі OS X Lion.

Я часто створюю / скидаю таблиці для деяких запланованих нами завдань з аналітики. У якийсь момент я почав отримувати таблицю, вже існує помилки на півдорозі мого сценарію. Перезапуск сервера зазвичай вирішив проблему, але це було занадто дратує рішення.

Потім я помітив у локальному файлі журналу помилок саме цей рядок:

[Warning] Setting lower_case_table_names=2 because file system for /usr/local/mysql/data/ is case insensitive

Це дало мені думку про те, що, можливо, якщо мої таблиці містять великі літери, MySQL обдурить себе думкою, що вони все ще є, навіть після того, як я їх скинув. Це виявилося так, і проблема переходу на використання лише малих літер для імен таблиць усунула проблему.

Це, мабуть, результат якоїсь неправильної конфігурації в моєму випадку, але, сподіваємось, цей випадок помилок допоможе комусь витратити менше часу на пошук рішення.

Це старе запитання, але я просто потрапив на те саме питання, і відповідь на одне із пов'язаних питань, пов'язаних вгорі, було саме те, що мені було потрібно, і набагато менш кардинально, ніж видалення файлів, таблиць, закриття сервера тощо.

mysqladmin -uxxxxxx -pyyyyy flush-tables

У моєму випадку проблема була вирішена шляхом зміни власності на каталог даних mysql на користувача, який керував програмою. (У моєму випадку це була програма Java, що працює на веб-сервері Jetty.)

Незважаючи на те, що mysql працює і інші програми могли його правильно використовувати, у цього додатка виникли проблеми. Після зміни власності на каталог даних та скидання пароля користувача все працювало належним чином.

Якщо буде запас із цією помилкою 1051, і ви хочете лише видалити базу даних та імпортувати це, зробіть ці кроки, і все буде добре.

в Unix envoriment AS корінь :

• rm -rf / var / lib / mysql / YOUR_DATABASE;
• ОПЦІЙНО -> mysql_upgrade --force
• mysqlcheck -uUSER -PPASS YOUR_DATABASE
• mysqladmin -uUSER -PPASS крапля YOUR_DATABASE
• mysqladmin -uUSER -pPASS створити YOUR_DATABASE
• mysql -UUSER -PPASS YOUR_DATABASE <IMPORT_FILE

З повагою, Христусе

У мене була ця проблема і сподівався, що видалення файлу IBD допоможе, як було розміщено вище, але це не мало значення. MySQL відтворив лише новий файл IBD. У моєму випадку насправді є подібні таблиці в інших базах даних у тому ж екземплярі MySQL. Оскільки файл FRM відсутній, я скопіював файл FRM з аналогічної таблиці в іншу базу даних, перезапустив MySQL і таблиця працювала правильно.

Я зіткнувся з цією помилкою після того, як створив таблицю та видалив її, а потім хотів її створити заново. У моєму випадку у мене був автономний файл дампа, тому я скинув свою схему, відтворив її та імпортував таблиці та дані, використовуючи файл дампа.

Це трапляється на нашому сайті (але рідко), як правило, коли "подія" трапляється під час виконання певних сценаріїв, які багато переробляють. Події включають відключення мережі або проблеми з живленням.
Що я роблю для цього дуже рідко, коли це трапляється - я використовую важкий підхід:

• Мені потрібно було просто позбутися і відновити конкретний стіл. Зазвичай я в положенні, що це нормально з моменту створення таблиці. (Ваша ситуація може бути різною, якщо вам потрібно відновити дані)
• Як адміністратор, перейдіть до установки mysql (у Windows це може бути "... програмні файли / mysql / MySQL Server xx / data / <schemaname>
• Знайдіть у папці <schemaname> образливий файл із назвою таблиці - та видаліть його.
• Перевірте тимчасові файли-сироти та видаліть їх також. # ... файли frm, якщо вони трапляються там.
• MySQL дозволить вам створити таблицю ще раз

Я мав цю проблему в декількох різних базах даних протягом тривалого часу (років). Це було заїкання, оскільки суперечливі повідомлення. Перший раз я змінив базу даних для видалення / відновлення / перейменування, як описано в інших відповідях, і мені вдалося все покращити, але це, звичайно, триває довше. На щастя, для мене завжди трапляються посилання на таблиці, які перебудовуються - DROP'd та CREATEd - як правило, вранці. Рідко потрапив до проблеми, але визнав її особливою химерною справою. (Я повторю: якщо вам потрібно відновити дані, перегляньте інші рішення.)

• це не таблиця, що належить іншому користувачеві, або в іншій базі даних
• це не верхнє / нижнє регістр, я використовую всі малі регістри, але це було цікавим питанням!
• це було додатково неприємно бачити відповіді з варіаціями "це безумовно було <там / не-там / хтось інший-користувач-таблиця-випадок> і ти просто не робиш це правильно" :)
• таблиця не відображалася на "показати таблиці"
• таблиця була (завжди була / була) таблицею INNODB.
• намагаючись знищити таблицю, подало повідомлення про помилку, що таблиця не існує.
• але намагаючись СТВОРИТИ таблицю, подано повідомлення про помилку, що таблиця вже існує.
• використовуючи mysql 5.0 або 5.1
• РЕМОНТ не є ефективним для цієї проблеми

У мене була ця проблема з однією конкретною таблицею. Читаючи можливі рішення, я зробив кілька кроків, таких як:

• Пошук файлів-сиріт: нікого не існувало;
• Execute:: show full tables in database;не бачив проблемного;
• виконати describe table;:: повернуто table doesn't exist;
• виконати SELECT * FROM information_schema.TABLES WHERE TABLE_NAME='table';:: повернуто Empty set;
• Пошук за допомогою phpMyAdmin вручну: вищезазначений запит: не існувало;

І, після цих кроків, я ще раз перевіряю за допомогою show tables;та ... vualá! проблемної таблиці не було. Я міг би створити його і скинути його з тим самим проблемним ім'ям без проблем, і мені не довелося навіть перезавантажувати сервер! Дивно ...