MySQL> Tabela nie istnieje. Ale to robi (lub powinno)

Zmieniłem katalog danych instalacji MySQL i wszystkie bazy zostały poprawnie przeniesione, z wyjątkiem jednej. Mogę połączyć się USEz bazą danych. SHOW TABLESzwraca mi również wszystkie tabele poprawnie, a pliki każdej tabeli istnieją w katalogu danych MySQL.

Jednak gdy próbuję SELECTcoś z tabeli, pojawia się komunikat o błędzie, że tabela nie istnieje. Nie ma to jednak sensu, ponieważ byłem w stanie wyświetlić tę samą tabelę za pomocą SHOW TABLESinstrukcji.

Domyślam się, że SHOW TABLESwyświetla listę istnienia pliku, ale nie sprawdza, czy plik jest uszkodzony, czy nie. W związku z tym mogę wyświetlić listę tych plików, ale nie mam do nich dostępu.

Niemniej jednak jest to tylko przypuszczenie. Nigdy wcześniej tego nie widziałem. Teraz nie mogę zrestartować bazy danych w celu przetestowania, ale każda inna aplikacja, która z niej korzysta, działa poprawnie. Ale to tylko przypuszczenie, nigdy wcześniej tego nie widziałem.

Czy ktoś wie, dlaczego tak się dzieje?

Przykład:

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

Na wypadek, gdyby ktoś nadal się przejmował:

Miałem ten sam problem po skopiowaniu katalogu bazy danych bezpośrednio za pomocą polecenia

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

Jeśli zrobisz to z bazą danych, która korzysta z InnoDBtabel, otrzymasz zwariowany błąd „tabela nie istnieje” wspomniany powyżej.

Problem jest, że trzeba te ib*pliki w katalogu głównym datadir MySQL (np ibdata1, ib_logfile0i ib_logfile1).

Kiedy skopiowałem te, zadziałało to dla mnie.

Dla mnie w systemie Mac OS (instalacja MySQL DMG) proste ponowne uruchomienie serwera MySQL rozwiązało problem. Zgaduję, że spowodowała to hibernacja.

Pojawia się ten problem, gdy sprawa nazwy tabeli, której używam, jest wyłączona. Tak więc tabela nazywa się „db”, ale użyłem „DB” w instrukcji select. Upewnij się, że sprawa jest taka sama.

Ten błąd może również wystąpić podczas ustawiania lower_case_table_namessię 1, a następnie próbuje tabel dostępu, które zostały utworzone z wartością domyślną dla tej zmiennej. W takim przypadku możesz przywrócić poprzednią wartość i będziesz mógł odczytać tabelę.

1. zatrzymać mysqld
2. zrób kopię zapasową folderu mysql: cp -a /var/lib/mysql /var/lib/mysql-backup
3. skopiuj folder bazy danych ze starego komputera do /var/lib/mysql
4. przesłonić ib * (ib_logfile *, ibdata) ze starej bazy danych
5. uruchom mysqld
6. zrzuć bazę danych
7. mysqldump >dbase.mysql
8. zatrzymaj usługę mysql
9. usunąć /var/lib/mysql
10. zmień nazwę /var/lib/mysql-backupna/var/lib/mysql
11. uruchom mysqld
12. utwórz bazę danych
13. mysqldump < dbase.mysql

Uruchom zapytanie:

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'

Niestety MySQL pozwala na stosowanie znaków Unicode i niedrukowalnych w nazwie tabeli. Jeśli utworzyłeś tabele, kopiując kod tworzenia z jakiegoś dokumentu / strony internetowej, istnieje szansa, że ​​ma on gdzieś miejsce o zerowej szerokości.

Właśnie spędziłem trzy dni na tym koszmarze. Najlepiej jest mieć kopię zapasową, którą można przywrócić, a następnie po prostu upuścić uszkodzoną tabelę. Tego rodzaju błędy mogą spowodować, że rozmiar ibdata1 będzie ogromny ( ponad 100 GB dla skromnych tabel)

Jeśli nie masz najnowszej kopii zapasowej, na przykład w przypadku polegania na mySqlDump, prawdopodobnie w pewnym momencie kopie zapasowe po cichu zepsuły się. Będziesz musiał wyeksportować bazy danych, czego oczywiście nie możesz zrobić, ponieważ podczas uruchamiania mySqlDump wystąpią błędy blokady.

Aby obejść ten problem, przejdź do /var/log/mysql/database_name/ i usuń nazwę_tabeli. *

Następnie natychmiast spróbuj zrzucić stół; robienie tego powinno teraz działać. Teraz przywróć bazę danych do nowej bazy danych i odbuduj brakujące tabele. Następnie zrzuć zepsutą bazę danych.

W naszym przypadku ciągle otrzymywaliśmy mysql has gone awaywiadomości w przypadkowych odstępach czasu we wszystkich bazach danych; po usunięciu uszkodzonej bazy danych wszystko wróciło do normy.

Nie znam przyczyny, ale w moim przypadku rozwiązałem po prostu wyłączenie i włączenie sprawdzania kluczy obcych

SET FOREIGN_KEY_CHECKS=0;
SET FOREIGN_KEY_CHECKS=1;

Miałem ten sam problem i szukałem 2-3 dni, ale dla mnie rozwiązanie było naprawdę głupie.

Uruchom ponownie mysql

$ sudo service mysql restart

Teraz tabele stają się dostępne.

Ok, to zabrzmi dość absurdalnie, ale humor mnie.
Dla mnie problem został rozwiązany, kiedy zmieniłem moje oświadczenie na:

SELECT * FROM `table`

Wprowadziłem dwie zmiany
1.) Nazwa tabeli została zapisana małymi literami - wiem !!
2.) Użyłem określonego symbolu cytatu = ` : To jest klucz nad TAB

Rozwiązanie brzmi absurdalnie, ale zadziałało i jest sobotni wieczór i pracuję od 9 rano - więc wezmę to :)

Powodzenia.

Miałem ten problem po aktualizacji WAMP, ale nie miałem kopii zapasowej bazy danych.

To działało dla mnie:

1. Zatrzymaj nowy WAMP

2. Skopiuj potrzebne katalogi bazy danych i plik ibdata1 ze starej instalacji WAMP

3. Usuń ib_logfile0iib_logfile1

4. Uruchom WAMP

Powinieneś być teraz w stanie tworzyć kopie zapasowe swoich baz danych. Jednak po ponownym uruchomieniu serwera nadal będziesz mieć problemy. Teraz zainstaluj ponownie WAMP i zaimportuj swoje bazy danych.

Spróbuj uruchomić kwerendę SQL, aby odrzucić obszar tabel przed skopiowaniem pliku idb:

ALTER TABLE mydatabase.mytable DISCARD TABLESPACE;

Skopiuj plik idb

ALTER TABLE mydatabase.mytable IMPORT TABLESPACE;

Uruchom ponownie MySql

Po ponownej instalacji MySQL miałem ten sam problem, wydaje się, że podczas instalacji niektóre pliki konfiguracyjne, które przechowują dane o plikach dziennika InnoDB, te pliki ib_logfile * (są to pliki dziennika, prawda?), Są zastępowane. Aby rozwiązać ten problem, właśnie usunąłem pliki ib_logfile *.

To, co zadziałało dla mnie, to po prostu upuszczenie stołu, mimo że nie istniał. Następnie utworzyłem tabelę i ponownie wypełniłem zrzut pamięci SQL wykonany wcześniej.

Musi istnieć metabaza nazw tabel i najprawdopodobniej istniała tam, dopóki jej nie upuściłem.

Miałem podobny problem ze stołem-widmem. Na szczęście miał zrzut SQL sprzed awarii.

W moim przypadku musiałem:

1. Zatrzymaj mySQL
2. Przenieś pliki ib * z /var/mysql off do kopii zapasowej
3. Usunąć /var/mysql/{dbname}
4. Uruchom ponownie mySQL
5. Utwórz ponownie pustą bazę danych
6. Przywróć plik zrzutu

UWAGA: Wymaga pliku zrzutu.

1. Czy mysqldump do bazy danych:

   mysqldump -u user -ppass dbname > D:\Back-ups\dbname.sql

2. Przywróć bazę danych

   mysql -u user -ppass dbname < D:\Back-ups\dbname.sql

Teraz wszystkie tabele w bazie danych zostały całkowicie przywrócone. Próbować..

SELECT * FROM dbname.tablename;

Zainstalowałem MariaDB na nowym komputerze, zatrzymałem usługę Mysql zmieniłem nazwę folderu danych na dane - Rozwiązałem problem z kopiowaniem tylko Mysql \ data \ table_folders i ibdata1 z uszkodzonego folderu danych HD MySql do nowego zainstalowanego folderu danych mysql.

Zrezygnowałem ib_logfile0 i ib_logfile1 (inaczej serwer nie rozpocznie usługa)

Uruchomiono usługę mysql.

Następnie serwer działa.

Wygląda na to, że problem dotyczy (przynajmniej mojego i kilku innych) nieprawidłowych (uszkodzonych?) Plików dziennika innodb. Ogólnie rzecz biorąc, po prostu trzeba je odtworzyć.

Oto rozwiązania, z których większość wymaga ponownego uruchomienia mysql.

• Utwórz ponownie pliki dziennika ( Usuń i uruchom ponownie mysql )
• Zmień rozmiar plików dziennika (MySql 5.6+ zregeneruje plik za Ciebie)
• Jeśli wykonujesz jakąś migrację danych, upewnij się, że poprawnie przeprowadziłeś migrację odpowiedniego pliku i nadałeś mu uprawnienia, jak inni już stwierdzili
• Sprawdź uprawnienia do danych i plików dziennika, czy mysql jest właścicielem obu
• Jeśli wszystko inne zawiedzie, prawdopodobnie będziesz musiał ponownie utworzyć bazę danych

Oto inny scenariusz (aktualizacja wersji) :

Ponownie zainstalowałem swój system operacyjny (Mac OS El Captain) i zainstalowałem nową wersję mysql (używając homebrew). Zainstalowana wersja (5.7) okazała się nowsza niż moja poprzednia. Następnie skopiowałem tabele, w tym pliki ib *, i ponownie uruchomiłem serwer. Widziałem tabele w środowisku mysql workbench, ale kiedy próbowałem coś wybrać, otrzymałem komunikat „Tabela nie istnieje”.

Rozwiązanie:

1. zatrzymaj serwer mysql np. mysql.server stoplubbrew services stop mysql
2. uruchom serwer za pomocą mysqld_safe --user=mysql --datadir=/usr/local/var/mysql/ (w razie potrzeby zmień ścieżkę)
3. biegać mysql_upgrade -u root -p password (w innym oknie terminala)
4. zamknij działający serwer mysqladmin -u root -p password shutdown
5. zrestartuj serwer w trybie normalnym mysql.server startlubbrew services start mysql

Odpowiednie dokumenty są tutaj .

W moim przypadku zdefiniowałem wyzwalacz w tabeli, a następnie próbowałem wstawić wiersz do tabeli. wygląda na to, że jakoś wyzwalacz był błędny, a zatem wstawianie dawało błąd, tabela nie istnieje.

Możliwe, że masz w nazwie tabeli ukrytą postać. Te nie pojawiają się, gdy robisz tabele pokazowe. Czy możesz zrobić „POKAŻ UTWÓRZ TABELĘ_TABELĘ” i wypełnij zakładkę „TABELA_TABELI” i sprawdź, czy zawiera ukryte znaki. Czy próbowałeś również upuścić i przerobić tabele. Tylko po to, aby upewnić się, że nie ma nic złego w uprawnieniach i że nie ma ukrytych postaci.

Ten sam dokładny problem po imporcie kopii zapasowej TimeMachine. Moje rozwiązanie polegało na zatrzymaniu serwera MySQL i naprawieniu uprawnień do odczytu i zapisu w plikach ib *.

Jeszcze jedna odpowiedź, którą moim zdaniem warto tu przywołać (ponieważ przyszedłem tutaj z tym samym problemem i ta okazała się dla mnie odpowiedzią):

Sprawdź dokładnie, czy nazwa tabeli w zapytaniu jest napisana dokładnie tak samo, jak w bazie danych.

To coś oczywistego, nowicjusz, ale takie rzeczy jak „użytkownik” kontra „użytkownicy” mogą wprawiać ludzi w osłupienie i pomyślałem, że będzie to przydatna odpowiedź na liście tutaj. :)

W moim przypadku, gdy importowałem eksportowany plik sql, otrzymywałem błąd, że tabela nie istnieje dla zapytania tworzenia tabeli.

Uświadomiłem sobie, że w nazwie mojej bazy danych znajduje się znak podkreślenia, a mysql umieścił tuż przed tym znak zmiany znaczenia.

Więc usunąłem podkreślenie w nazwie bazy danych, wszystko się udało.

Mam nadzieję, że pomoże to również komuś innemu.

Mój stolik został jakoś przemianowany na ' Customers'np. Z wiodącym miejscem

To znaczyło

a) zapytania zostały zerwane

b) tabela nie pojawiła się zgodnie z oczekiwaniami w kolejności alfabetycznej moich tabel, co w mojej panice oznaczało, że jej nie widziałem!

RENAME TABLE ` Customer` TO `Customer`;

W moim przypadku był to SQLCA.DBParmparametr.

użyłem

SQLCA.DBParm = "Databse = "sle_database.text""

ale musi być

SQLCA.DBParm = "Database='" +sle_database.text+ "'"

Wyjaśnienie:

Zamierzasz połączyć trzy ciągi:

 1. Database='              -  "Database='"

 2. (name of the database)  - +sle_database.text+

 3. '                       - "'" (means " ' "  without space)

Nie używaj spacji w znakach czwartorzędowych. Dziękuję mojemu koledze Janowi

Idź do: xampp\mysql\data\dbname
wewnątrz dbname mają plik tablename.frm i tablename.ibd.
usuń go, uruchom ponownie mysql i spróbuj ponownie.

Skopiuj tylko ibdata1plik ze starego katalogu danych. Nie kopiuj ib_logfile1ani ib_logfile0plików. To spowoduje, że MySQL nie będzie się już uruchamiał.

Dzisiaj spotkałem ten sam problem. Jest to problem „wrażliwości na wielkość liter” mysql.

Sprawdź odpowiedni plik danych. Jest bardzo prawdopodobne, że nazwa pliku jest zapisana małymi literami w systemie plików, ale nazwa tabeli wymieniona w poleceniu „pokaż tabele” jest pisana wielkimi literami. Jeśli zmienna systemowa „ lower_case_table_names” wynosi 0, zapytanie zwróci „tabela nie istnieje”, ponieważ w porównaniach nazw rozróżniana jest wielkość liter, gdy „ lower_case_table_names” wynosi 0.

Miałem ten sam problem w systemie Windows. Oprócz skopiowania plików ib * i katalogu mysql do katalogu danych, musiałem również dopasować plik my.ini.

Plik my.ini z mojej poprzedniej instalacji nie miał następującego wiersza:

innodb-page-size=65536

Ale zrobiła to moja nowa instalacja. Być może dlatego, że nie miałem tej opcji w starszym instalatorze. Usunąłem to i ponownie uruchomiłem usługę, a tabele działały zgodnie z oczekiwaniami. Krótko mówiąc, upewnij się, że nowy plik my.ini jest repliką starego, z jedynym wyjątkiem jest katalog danych, katalog wtyczek i numer portu, w zależności od nowej instalacji.