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


261

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

czy przywróciłeś bazę danych z kopii zapasowej? czy właśnie skopiowałeś pliki db? czy masz uprawnienia roota do serwera mysql?
alinoz

właśnie skopiowałem pliki! tak, mam dostęp do roota do wszystkiego
johnsmith,

możesz spróbować: mysql_fix_privilege_tables
alinoz

4
są te tabele innodb?
Paul Dixon,

1
Tak, wszystkie tabele są InnoDB. Mój zły, że tego nie powiedziałem!
johnsmith,

Odpowiedzi:


263

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.


27
Uratowałem mi życie! Dla innych osób pamiętaj, aby nie zastępować istniejących plików ib *, jeśli próbujesz skopiować do nowej instalacji. Wykonaj kopię zapasową istniejącego katalogu mysql /, zastąp go starym, który chcesz odzyskać, mysqldump wszystko, a następnie przywróć nowy mysql /. Następnie możesz poprawnie zaimportować mysqldumps.
Matthew

1
Na komputerze Mac, aby lokalnie zreplikować moją bazę danych, oprócz kopiowania pliku ibdata (znajdującego się obok katalogu bazy danych), musiałem chown _mysql:wheelużyć nazwy bazy danych katalog, ibdata i wszystkich plików w katalogu (użyj chown -R ...). Podobnie, uprawnienia były niepoprawne w katalogu, więc chmod -R 660 databasenamebyło potrzebne, aby tabele pojawiły się w bazie danych.
Dylan Valade,

4
Dzięki Mike. Aby to wyjaśnić, musisz ponownie uruchomić usługę mysql, aby to działało. Przynajmniej tak zrobiłem i dzięki Bogu to zadziałało. Wiele danych tam zapisanych!
Nick Martin

15
UWAGA: Nie zapomnij użyć chown!!! Tak więc wszystko po cpużyciu tego polecenia ->chown mysql:mysql /var/lib/mysql/ -R
K-Gun

1
UWAGA 2: Nie zapomnij zastosować odpowiedniego pozwolenia. W moim przypadku sudo chmod -R 600 /var/lib/mysql
sierpień

45

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


Dzięki naprawiłem również ten sam problem. Mój zdarzył się po wyłączeniu mojej maszyny z powodu nagłej utraty zasilania. Po pierwszym uruchomieniu komputera / uruchomieniu MySQL wystąpił błąd. Następnie przeczytałem tę odpowiedź. Zatrzymałem / uruchomiłem MySQL poprzez Preferencje systemowe i zostało to naprawione.
Jeff Evans

2
sudo /usr/local/mysql/support-files/mysql.server restart
laffuste

Również. Natknąłem się na to po aktualizacji do macOS Sierra 10.12.6. Nie jestem pewien, czy istnieje związek przyczynowy, ale czas wydaje się podejrzany.
Dave Mulligan,

Dzięki, pracował do pewnego stopnia; zrestartowałem usługę mysql (5.6, Windows), a następnie uruchomiłem check table TABLE_ONE;Mam błędy „partycja p2 zwróciła błąd”, „idx_blah_1 jest oznaczony jako uszkodzony”, a „idx_blah_2 jest oznaczony jako uszkodzony”. Teraz wracam do działania optimize table TABLE_ONE;i pojawia się komunikat o błędzie „Baza danych tabeli”. TABELA_ON „nie istnieje”.
Omar

Uruchamianie MySLQ na Mojave. Ponowne uruchomienie przez panel preferencji systemowych nie działało. Musiałem ponownie uruchomić za pomocą wiersza polecenia.
Cortex

30

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.


13
+1 W nazwach pól nie jest rozróżniana wielkość liter, ale w nazwach tabel są. Powszechny błąd i bardzo denerwujący.
GolezTrol,

27

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ę.


4
To mnie ugryzło. Cofnąłem wartość, zrestartowałem bazę danych, wyeksportowałem tabele, ustawiłem wartość z powrotem na 1, zrestartowałem bazę danych, ponownie zaimportowałem tabele i wszystko działało ponownie.
wmarbut,

17
  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

W moim przypadku musiałem też zrobić: 10.5 usunąć katalog <nazwa_db> z katalogu / var / lib / mysql /
Tony the Tech,

to nie działa. :( tabela „tablename.wp_posts” nie istnieje
Jahirul Islam Mamun

14

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.


bardzo przydatny post, dzięki! ale wszystkie tabele są ASCII z poprawną długością nazwy
John

11

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.


Dzięki, Andy, mam wskazówkę, że mam problem. Przeniosłem ibdata1 z dysku C na dysk D, aby zaoszczędzić miejsce na dysku C. Na szczęście dostałem ibdata1 (wraz z ib_logfile1. I ib_logfile0) na moim dysku D po przeczytaniu twoich komentarzy. Teraz sprawdzę, skąd przeniosłem te pliki i tam je przywracam. Mam nadzieję, że moje stoły wrócą.
AKS

Jak „od razu próbujesz zrzucić stół”? Mam ten sam problem, brak kopii zapasowych, więc szukam sposobu na uzyskanie struktury tabeli, ale jeśli usuniesz pliki z katalogu, wszystko po prostu zniknie?
mmvsbg

Zrobiło to! Dzięki,
jstuardo,

11

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;

4
Dzięki bracie! W moim przypadku musiałem wyłączyć obce_klucze i wykonać zapytanie wybierające w znikającej tabeli, po czym tabela znów stała się normalna. Wydaje mi się, że w wierszach danych występują pewne naruszenia klucza obcego, ponieważ przed wystąpieniem tego problemu miałem przerwany program.
Egist Li

Nie byłem w stanie dowiedzieć się, dlaczego dokładnie, ale to również rozwiązało mój problem
Miroslav Glamuzina

11

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.


1
Całkowicie działało dla mnie, chociaż moje polecenie było nieco inne: $ sudo /usr/local/mysql/support-files/mysql.server restart
KirstieBallance

To chyba powinno być na górze listy rzeczy do wypróbowania. Warto spróbować i w moim przypadku się udało.
Coroos,

7

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.


1
Po prostu FYI - Stół to MyISAM, a nie INNO
PlanetUnknown

1
Również `nazywa się backstick
Gary

7

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.


Chciałbym, żeby ludzie wskazywali, gdzie znajdują się pliki, do których się odnoszą ...
MagentoAaron,

Dostałem się tutaj z obrazu dokera mysql, który nie ma czytelnych tabel. Może potwierdzić, że zatrzymanie obrazu, usunięcie tych plików i ponowne uruchomienie dało dostęp ponownie.
Anthony Harley,

7

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


Uratowałeś mnie :)
10000

@ I0pan Próbowałem tych samych kroków, jak wspomniano. Ale po ALTER TABLE mydatabase.mytable IMPORT TABLESPACE; pokazuje, że tabela nie istnieje. Ale robi to :(
Syed Asad Abbas Zaidi

5

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 *.


5

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.


Stworzyłem procedurę, zdałem sobie sprawę, że to musi być widok. Na koniec zmieniłem nazwę procedury z kilkoma zzzami, aby mieć ją do wglądu i stworzyć widok o tej samej nazwie. Nie można uzyskać instrukcji SELECT, aby go zobaczyć, wystąpił ten błąd. <br> Skopiowałem kod do pliku tekstowego, usunąłem zarówno widok, jak i procedurę. Odtworzyłem widok i wszystko było dobrze. <br> Więc tak - siedem lat później - w niektórych przypadkach krawędzi wciąż dzieje się coś w rodzaju nazwy ducha / pamięci podręcznej.
Roger Krueger,

5

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.


Chyba masz na myśli /var/lib/mysqlzamiast/var/mysql
knocte

Jedyne, co mi pomogło, to usunięcie katalogów bazy danych i przywrócenie ich z kopii zapasowej.
Jano

3
  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;

2

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.


2

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

2

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 .


Próbowałem naprawdę dużo, ale to była jedyna rzecz, która bardzo mi pomogła po przeprowadzce na nowy serwer ze wszystkimi moimi bazami danych. Dzięki! (Ubuntu 16.04)
Falk

2

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.


1
To działa dla mnie! Sprawdziłem każdy wyzwalacz i stwierdziłem, że jeden należy poprawić i zadziałał!
Paresh

1

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.


Uzupełnianie tabulatorów nie pomaga i nie mogę wyświetlić tabeli, ponieważ tabela „nie istnieje”. z piekła rodem
johnsmith,

1

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 *.


1

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. :)


1

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.


1

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`;

1

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


1

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.


1

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


1

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.


1

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.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.