Tabela Schrödingers MySQL: istnieje, ale nie istnieje

Mam najdziwniejszy błąd ze wszystkich.

Czasami podczas tworzenia lub zmieniania tabel pojawia się błąd „tabela już istnieje”. Jednak DROP TABLE zwraca „# 1051 - nieznana tabela”. Więc mam tabelę, której nie mogę stworzyć, nie mogę upuścić.

Kiedy próbuję upuścić bazę danych, mysqld ulega awarii. Czasami pomaga stworzyć kolejną bazę danych o innej nazwie, a czasami nie.

Używam bazy danych z ~ 50 tabelami, wszystkie InnoDB. Ten problem występuje w przypadku różnych tabel.

Doświadczyłem tego w systemach Windows, Fedora i Ubuntu, MySQL 5.1 i 5.5. To samo zachowanie, gdy używasz PDO, PHPMyAdmin lub wiersza poleceń. Używam MySQL Workbench do zarządzania moim schematem - widziałem kilka powiązanych błędów (linie końcowe i inne), jednak żaden z nich nie był dla mnie istotny.

Nie, to nie jest widok, to stół. Wszystkie nazwy są pisane małymi literami.

Wypróbowałem wszystko, co mogłem wygooglować - opróżnianie tabel, przenoszenie plików .frm z db do db, czytanie dziennika mysql, nic nie pomogło, tylko przeinstalowanie całej cholernej rzeczy.

`` Pokaż tabele '' nic nie ujawnia, `` opisz '', że `` tabela nie istnieje '', `` nie ma pliku .frm '', ale `` tworzenie tabeli '' nadal kończy się błędem (tak samo jak `` tworzenie tabeli, jeśli nie istnieje '') i upuszczenie bazy danych powoduje awarię mysql

Powiązane, ale nieprzydatne pytania:

• Mysql 1050 Błąd „Tabela już istnieje”, podczas gdy w rzeczywistości tak nie jest

• Tabela MySQL nie istnieje błąd, ale istnieje

Edytować:

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'

I tak wszystko jedno: tabela nie istnieje, ale nie można jej utworzyć;

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

Nazwy się zmieniają, nie jest to jedyna tabela / baza danych, z którą mam problemy

Widziałem ten problem, gdy brakuje pliku danych w katalogu danych, ale plik definicji tabeli istnieje lub na odwrót. Jeśli używasz innodb_file_per_table, sprawdź katalog danych, aby upewnić się, że masz zarówno .frmplik, jak i plik .ibd dla danej tabeli. Jeśli to MYISAM, nie powinno być .frm, .MYIa .MYDplik.

Problem można zazwyczaj rozwiązać, ręcznie usuwając osierocony plik.

Wychodzę na szalony domysł, ale wygląda na to, że innodb nadal ma wpis dla twoich tabel w obszarze tabel, prawdopodobnie w ibdata. Jeśli naprawdę nie potrzebujesz żadnych danych lub masz kopie zapasowe, wypróbuj następujące rozwiązania:

1. Usuń wszystkie schematy (z wyjątkiem mysql)
2. zamknij bazę danych
3. Upewnij się, że wszystkie foldery w katalogu danych zostały poprawnie usunięte (ponownie, z wyjątkiem mysql)
4. usuń ibdata i pliki dziennika
5. zrestartuj bazę danych. Powinien odtworzyć obszar tabel i dzienniki od podstaw.

Naprawa okazuje się łatwa; przynajmniej to, co wypracowałem, zadziałało dla mnie. Utwórz tabelę „zzz” w innej instancji MySQL, gdzie zzz jest nazwą tabeli problemów. (tj. jeśli tabela nazywa się schrodinger, zamień ją na zzz, gdziekolwiek jest napisane). Nie ma znaczenia, jaka jest definicja tabeli. To tymczasowy manekin; Skopiuj plik zzz.frm do katalogu bazy danych na serwerze, na którym powinna znajdować się tabela, upewniając się, że prawa własności i uprawnienia do pliku są nadal prawidłowe. Na MySQL możesz teraz zrobić "show table;", a tabela zzz będzie tam. mysql> drop table zzz; ... powinien teraz działać. W razie potrzeby wyczyść wszystkie pliki zzz.MYD lub ZZZ.MYI w katalogu.

Wątpię, czy jest to bezpośrednia odpowiedź na ten przypadek pytania, ale oto, jak rozwiązałem ten dokładnie postrzegany problem w moim systemie OS X Lion.

Często tworzę / upuszczam tabele dla niektórych zadań analitycznych, które zaplanowałem. W pewnym momencie zacząłem otrzymywać błędy tabeli już w połowie skryptu. Ponowne uruchomienie serwera zazwyczaj rozwiązało problem, ale było to zbyt irytujące rozwiązanie.

Następnie zauważyłem w lokalnym pliku dziennika błędów ten konkretny wiersz:

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

To nasunęło mi pomysł, że być może gdyby moje tabele zawierały wielkie litery, MySQL dałby się nabrać, myśląc, że nadal tam są, nawet po ich upuszczeniu. Okazało się, że tak jest i przejście na używanie tylko małych liter w nazwach tabel sprawiło, że problem zniknął.

Prawdopodobnie jest to wynikiem jakiejś błędnej konfiguracji w moim przypadku, ale mam nadzieję, że ten przypadek błędu pomoże komuś marnować mniej czasu na szukanie rozwiązania.

To stare pytanie, ale właśnie trafiłem na ten sam problem, a odpowiedź w jednym z powiązanych problemów, do których link znajduje się na górze, była właśnie tym, czego potrzebowałem i znacznie mniej drastycznym niż usuwanie plików, tabel, wyłączanie serwera itp.

mysqladmin -uxxxxxx -pyyyyy flush-tables

W moim przypadku problem został rozwiązany poprzez zmianę właściciela katalogu danych mysql na użytkownika, który uruchomił aplikację. (W moim przypadku była to aplikacja Java z serwerem internetowym Jetty).

Mimo że mysql działał i inne aplikacje mogły go poprawnie używać, ta aplikacja miała z tym problem. Po zmianie właściciela katalogu danych i zresetowaniu hasła użytkownika wszystko działało poprawnie.

Jeśli będzie na stanie z tym błędem 1051 i chcesz tylko usunąć bazę danych i zaimportować to ponownie, wykonaj te czynności i wszystko będzie dobrze ....

w środowisku uniksowym AS root :

• rm -rf / var / lib / mysql / YOUR_DATABASE;
• OPCJONALNIE -> mysql_upgrade --force
• mysqlcheck -uUSER -p PRZEKAŻ SWOJĄ_ABAZĘ_DANYCH
• mysqladmin -uUSER -pPASS drop YOUR_DATABASE
• mysqladmin -uUSER -pPASS utwórz YOUR_DATABASE
• mysql -uUSER -p PRZEKAŻ SWOJĄ_BAZĘ_DANYCH <IMPORT_FILE

Pozdrawiam, Christus

Miałem ten problem i miałem nadzieję, że usunięcie pliku IBD pomoże, jak napisano powyżej, ale nie miało to żadnego znaczenia. MySQL odtworzył tylko nowy plik IBD. W moim przypadku są faktycznie podobne tabele w innych bazach danych w tej samej instancji MySQL. Ponieważ brakowało pliku FRM, skopiowałem plik FRM z podobnej tabeli w innej bazie danych, zrestartowałem MySQL i tabela działała poprawnie.

Napotkałem ten błąd po utworzeniu tabeli i usunięciu jej, a następnie chciałem utworzyć ją ponownie. W moim przypadku miałem samodzielny plik zrzutu, więc porzuciłem schemat, odtworzyłem go i zaimportowałem tabele i dane za pomocą pliku zrzutu.

Dzieje się tak w naszej witrynie (ale rzadko), zwykle, gdy „zdarzenie” ma miejsce podczas uruchamiania pewnych skryptów, które często przebudowują. Zdarzenia obejmują awarie sieci lub problemy z zasilaniem.
Co robię w tym przypadku w bardzo rzadkich przypadkach - używam podejścia ciężkiej ręki:

• Musiałem po prostu pozbyć się i odbudować konkretny stół. Zwykle jestem w pozycji, w której jest to w porządku, ponieważ stół jest budowany. (Twoja sytuacja może być inna, jeśli chcesz odzyskać dane)
• Jako administrator przejdź do instalacji mysql (w systemie Windows może to być "... program files / mysql / MySQL Server xx / data / <schemaname>
• Znajdź problematyczny plik z nazwą tabeli w folderze <schemaname> - i usuń go.
• Sprawdź, czy nie ma osieroconych plików tymczasowych i też je usuń. # ... frm plików, jeśli się tam znajdują.
• MySQL pozwoli Ci ponownie TWORZYĆ tabelę

Miałem ten problem na kilku różnych bazach danych przez długi czas (lata). To był problem z powodu sprzecznych wiadomości. Za pierwszym razem zrobiłem odmianę usuwania / przebudowy / zmiany nazwy bazy danych, jak opisano w innych odpowiedziach, i udało mi się wszystko zacząć, ale zdecydowanie trwa to dłużej. Na szczęście dla mnie zawsze zdarzało się odwoływać się do tabel, które są odbudowywane - DROP'd i CREATEd - zwykle rano. Rzadko pojawiał się problem, ale zaczął rozpoznawać go jako specjalny dziwaczny przypadek. (Powtórzę: jeśli chcesz odzyskać dane, wyglądają na inne rozwiązania).

• nie jest to tabela należąca do innego użytkownika ani w innej bazie danych
• to nie jest kwestia wielkich / małych liter, używam wszystkich małych liter, ale to był interesujący problem!
• bardzo frustrujące było zobaczenie odpowiedzi z odmianami „zdecydowanie było <tam / nie ma / jakiś-inny-przypadek-tabeli-użytkowników> i po prostu nie robisz tego dobrze” :)
• tabela nie została wyświetlona w opcji „pokaż tabele”
• tabela była (zawsze była / była) tabelą INNODB.
• próba DROP tabeli dała komunikat o błędzie, że tabela nie istnieje.
• ale próbuje TWORZENIE tabeli dał się komunikat o błędzie, że tabela już istnieje.
• używając mysql 5.0 lub 5.1
• NAPRAWA jest nieskuteczna w przypadku tego problemu

Miałem ten problem z jednym konkretnym stołem. Czytając możliwe rozwiązania, wykonałem kilka kroków, takich jak:

• Wyszukaj osierocone pliki: nikt nie istniał;
• execute:: show full tables in database;nie widziałem tego problematycznego;
• execute describe table;:: return table doesn't exist;
• execute SELECT * FROM information_schema.TABLES WHERE TABLE_NAME='table';:: return Empty set;
• Wyszukaj ręcznie przez phpMyAdmina powyższe zapytanie: nie istnieje;

Po tych krokach sprawdzam ponownie za pomocą show tables;i ... vualá! problematyczny stół zniknął. Mogłem go stworzyć i upuścić z tą samą problematyczną nazwą bez problemu i nie musiałem nawet restartować serwera! Dziwne...