MySQL
Kody błędów

Kod błędu 1064: Błąd składni

select LastName, FirstName,
from Person

Zwraca wiadomość:

Kod błędu: 1064. Wystąpił błąd w składni SQL; sprawdź w instrukcji, która odpowiada wersji serwera MySQL, czy w wierszu 2 jest poprawna składnia do użycia w pobliżu „od osoby”.

Otrzymanie komunikatu „Błąd 1064” z MySQL oznacza, że zapytania nie można przeanalizować bez błędów składniowych. Innymi słowy, zapytanie nie ma sensu.

Cytat w komunikacie o błędzie zaczyna się od pierwszego znaku zapytania, którego MySQL nie może ustalić, jak go przeanalizować. W tym przykładzie MySQL nie może mieć sensu w kontekście from Person . W tym przypadku bezpośrednio przed from Person jest dodatkowy przecinek. Przecinek mówi MySQL, aby oczekiwał innego opisu kolumny w klauzuli SELECT

Błąd składniowy zawsze mówi ... near '...' . Rzecz na początku cytatów jest bardzo blisko miejsca, w którym występuje błąd. Aby zlokalizować błąd, spójrz na pierwszy token w cudzysłowach i ostatni token przed cudzysłowami.

Czasami zbliżasz się ... near '' ; to znaczy nic w cytatach. Oznacza to, że pierwszy znak, którego MySQL nie może zrozumieć, znajduje się na końcu lub na początku instrukcji. Sugeruje to, że zapytanie zawiera niezrównoważone cudzysłowy ( ' lub " ) lub niezrównoważone nawiasy lub że instrukcja nie została wcześniej zakończona poprawnie.

W przypadku Przechowywanej procedury mogłeś zapomnieć o prawidłowym użyciu DELIMITER .

Tak więc, gdy pojawi się błąd 1064, spójrz na tekst zapytania i znajdź punkt wymieniony w komunikacie o błędzie. Sprawdź wizualnie tekst zapytania wokół tego punktu.

Jeśli poprosisz kogoś o pomoc w rozwiązaniu problemu z błędem 1064, najlepiej podać zarówno tekst całego zapytania, jak i tekst komunikatu o błędzie.

Kod błędu 1175: Bezpieczna aktualizacja

Ten błąd pojawia się podczas próby aktualizacji lub usunięcia rekordów bez uwzględnienia klauzuli WHERE korzystającej z kolumny KEY .

Aby mimo to usunąć lub zaktualizować - wpisz:

SET SQL_SAFE_UPDATES = 0;

Aby ponownie włączyć tryb awaryjny - wpisz:

SET SQL_SAFE_UPDATES = 1;

Kod błędu 1215: Nie można dodać ograniczenia klucza obcego

Ten błąd występuje, gdy tabele nie są odpowiednio skonstruowane, aby obsłużyć szybką weryfikację wymagań klucza obcego ( FK ) wymaganych przez programistę.

CREATE TABLE `gtType` (
  `type` char(2) NOT NULL,
  `description` varchar(1000) NOT NULL,
  PRIMARY KEY (`type`)
) ENGINE=InnoDB;

CREATE TABLE `getTogethers` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `type` char(2) NOT NULL,
  `eventDT` datetime NOT NULL,
  `location` varchar(1000) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `fk_gt2type` (`type`), -- see Note1 below 
  CONSTRAINT `gettogethers_ibfk_1` FOREIGN KEY (`type`) REFERENCES `gtType` (`type`)
) ENGINE=InnoDB;

Uwaga 1: Klucz taki jak ten zostanie utworzony automatycznie w razie potrzeby z powodu definicji FK w linii po nim. Deweloper może go pominąć, a klucz (aka index) zostanie dodany, jeśli to konieczne. Przykład pomijania przez programistę pokazano poniżej w części someOther .

Do tej pory tak dobrze, dopóki nie zadzwonię poniżej.

CREATE TABLE `someOther` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `someDT` datetime NOT NULL,
  PRIMARY KEY (`id`),
  CONSTRAINT `someOther_dt` FOREIGN KEY (`someDT`) REFERENCES `getTogethers` (`eventDT`)
) ENGINE=InnoDB;

Kod błędu: 1215. Nie można dodać ograniczenia klucza obcego

W tym przypadku kończy się to niepowodzeniem z powodu braku indeksu w tabeli, do której odwołuje się getTogethers do obsługi szybkiego wyszukiwania eventDT . Do rozwiązania w następnym oświadczeniu.

CREATE INDEX `gt_eventdt` ON getTogethers (`eventDT`);

Tabela getTogethers została zmodyfikowana i teraz tworzenie niektórych someOther się powiedzie.

Ze strony podręcznika MySQL przy użyciu kluczowych kluczy OBCYCH :

MySQL wymaga indeksów kluczy obcych i kluczy referencyjnych, aby sprawdzanie kluczy obcych było szybkie i nie wymagało skanowania tabeli. W tabeli odwołań musi istnieć indeks, w którym kolumny kluczy obcych są wymienione jako pierwsze kolumny w tej samej kolejności. Taki indeks jest tworzony automatycznie w tabeli odwołań, jeśli nie istnieje.

Odpowiednie kolumny w kluczu obcym i kluczu odniesienia muszą mieć podobne typy danych. Rozmiar i znak typów liczb całkowitych muszą być takie same. Długość typów ciągów nie musi być taka sama. W przypadku niebinarnych (ciągów znaków) kolumn zestaw znaków i układanie muszą być takie same.

InnoDB pozwala kluczowi obcemu odwoływać się do dowolnej kolumny indeksu lub grupy kolumn. Jednak w tabeli, do której istnieją odniesienia, musi istnieć indeks, w którym kolumny, do których istnieją odniesienia, są wymienione jako pierwsze kolumny w tej samej kolejności.

Zauważ, że ostatni punkt powyżej na temat pierwszych (najbardziej po lewej) kolumn i braku wymogu klucza podstawowego (choć wysoce zalecane).

Po pomyślnym utworzeniu tabeli odniesienia (potomnej) wszystkie klucze, które zostały dla Ciebie automatycznie utworzone, są widoczne za pomocą polecenia, takiego jak:

SHOW CREATE TABLE someOther;

Inne typowe przypadki występowania tego błędu to, jak wspomniano powyżej z dokumentów, ale należy je podkreślić:

• Pozornie trywialne różnice w INT która jest podpisana, wskazując na INT UNSIGNED .

• Deweloperzy mają problemy ze zrozumieniem KLUCZYKÓW wielokolumnowych (kompozytowych) i wymagań dotyczących pierwszego (od lewej) kolejności.

1045 Odmowa dostępu

Zobacz dyskusje w „GRANT” i „Odzyskiwanie hasła roota”.

1236 „pozycja niemożliwa” w replikacji

Zwykle oznacza to, że Master sync_binlog , a sync_binlog był WYŁĄCZONY. Rozwiązaniem jest CHANGE MASTER to POS=0 MASTERA CHANGE MASTER to POS=0 następnego pliku binlog (patrz Master) na Slave.

Przyczyna: Master wysyła elementy replikacji do Slave przed opróżnieniem do swojego binlog (gdy sync_binlog=OFF ). Jeśli Master ulegnie awarii przed opróżnieniem, Slave logicznie przeszedł już poza koniec pliku na binlog. Kiedy Master ponownie uruchamia się, rozpoczyna nowy binlog, więc ZMIANA na początku tego binlogu jest najlepszym dostępnym rozwiązaniem.

Rozwiązaniem długoterminowym jest sync_binlog=ON , jeśli możesz sobie pozwolić na dodatkowe sync_binlog=ON we / wy, które powoduje.

(Jeśli korzystasz z GTID, ...?)

2002, 2003 Nie można się połączyć

Sprawdź, czy nie występuje problem z zaporą blokującą port 3306.

Niektóre możliwe diagnostyki i / lub rozwiązania

• Czy serwer faktycznie działa?
• „service firewalld stop” i „systemctl wyłącz firewalld”
• telnet master 3306
• Sprawdź bind-address
• sprawdź skip-name-resolve
• sprawdź gniazdo.

1067, 1292, 1366, 1411 - Zła wartość dla liczby, daty, wartości domyślnej itp.

1067 Prawdopodobnie jest to związane z wartościami domyślnymi TIMESTAMP , które zmieniły się z czasem. Zobacz TIMESTAMP defaults na stronie Daty i godziny. (który jeszcze nie istnieje)

1292/1366 DOUBLE / Integer Sprawdź litery lub inne błędy składniowe. Sprawdź, czy kolumny są wyrównane; być może myślisz, że umieszczasz w VARCHAR ale jest on wyrównany z kolumną numeryczną.

1292 DATETIME Sprawdź za daleko w przeszłości lub przyszłości. Sprawdzaj między 2 a 3 rano rano, gdy zmieniły się oszczędności w świetle dziennym. Sprawdź, czy nie ma złej składni, np. +00 stref czasowych.

1292 ZMIENNA Sprawdź dozwolone wartości dla VARIABLE którą próbujesz SET .

1292 ŁADUJ DANE Spójrz na linię, która jest „zła”. Sprawdź symbole ucieczki itp. Spójrz na typy danych.

1411 STR_TO_DATE Niepoprawnie sformatowana data?

126, 127, 134, 144, 145

Podczas próby uzyskania dostępu do rekordów z bazy danych MySQL mogą pojawić się te komunikaty o błędach. Te komunikaty o błędach wystąpiły z powodu uszkodzenia bazy danych MySQL. Oto typy

MySQL error code 126 = Index file is crashed
MySQL error code 127 = Record-file is crashed
MySQL error code 134 = Record was already deleted (or record file crashed)
MySQL error code 144 = Table is crashed and last repair failed
MySQL error code 145 = Table was marked as crashed and should be repaired

Przyczyną tego uszkodzenia jest błąd MySQL, atak wirusa, awaria serwera, nieprawidłowe zamknięcie, uszkodzona tabela. Kiedy zostanie uszkodzony, stanie się niedostępny i nie będziesz już mieć do niego dostępu. Aby uzyskać dostępność, najlepszym sposobem na odzyskanie danych ze zaktualizowanej kopii zapasowej. Jeśli jednak nie masz zaktualizowanej lub prawidłowej kopii zapasowej, możesz przejść do naprawy MySQL.

Jeśli typ silnika tabeli to MyISAM , zastosuj CHECK TABLE , a następnie REPAIR TABLE .

Zastanów się poważnie nad konwersją na InnoDB, aby ten błąd się nie powtórzył.

Składnia

CHECK TABLE <table name> ////To check the extent of database corruption
REPAIR TABLE <table name> ////To repair table

139

Błąd 139 może oznaczać, że liczba i rozmiar pól w definicji tabeli przekracza pewien limit. Obejścia:

• Ponownie pomyśl o schemacie
• Normalizuj niektóre pola
• Pionowo podziel tabelę

1366

Zazwyczaj oznacza to, że obsługa zestawu znaków nie była spójna między klientem a serwerem. Zobacz ... po dalszą pomoc.

126, 1054, 1146, 1062, 24

(robiąc sobie przerwę) Po uwzględnieniu tych 4 numerów błędów myślę, że ta strona obejmie około 50% typowych błędów, które mogą wystąpić.

(Tak, ten „Przykład” wymaga zmiany.)

24 Nie można otworzyć pliku (zbyt wiele otwartych plików)

open_files_limit pochodzi z ustawienia systemu operacyjnego. table_open_cache musi być mniejszy niż to.

Mogą powodować ten błąd:

• Błąd DEALLOCATE PREPARE w procedurze przechowywanej.

• PARTYCJONOWANE tabele z dużą liczbą partycji i innodb_file_per_table = ON. Nie zaleca się posiadania więcej niż 50 partycji w danej tabeli (z różnych powodów). (Gdy „rodzime partycje” staną się dostępne, ta rada może się zmienić).

Oczywistym obejściem jest ustawienie zwiększenia limitu systemu operacyjnego: Aby zezwolić na więcej plików, zmień ulimit lub /etc/security/limits.conf lub w sysctl.conf (kern.maxfiles & kern.maxfilesperproc) lub coś innego (zależnie od systemu operacyjnego). Następnie zwiększ open_files_limit i table_open_cache .

Począwszy od 5.6.8, open_files_limit ma automatyczny rozmiar na podstawie max_connections , ale można go zmienić z domyślnego.

1062 - Zduplikowany wpis

Ten błąd występuje głównie z następujących dwóch powodów

1. Zduplikowana wartość - Error Code: 1062. Duplicate entry '12' for key 'PRIMARY'

   Kolumna klucza podstawowego jest unikalna i nie zaakceptuje duplikatu pozycji. Więc kiedy próbujesz wstawić nowy wiersz, który już jest w tobie, tabela wygeneruje ten błąd.

Aby rozwiązać ten problem, ustaw kolumnę klucza podstawowego jako AUTO_INCREMENT . A gdy próbujesz wstawić nowy wiersz, zignoruj kolumnę klucza podstawowego lub wstaw wartość NULL do klucza podstawowego.

CREATE TABLE userDetails(
  userId INT(10) NOT NULL AUTO_INCREMENT,
  firstName VARCHAR(50),
  lastName VARCHAR(50),
  isActive INT(1) DEFAULT 0,
  PRIMARY KEY (userId) );

--->and now while inserting 
INSERT INTO userDetails VALUES (NULL ,'John', 'Doe', 1);

2. Niepowtarzalne pole danych - Error Code: 1062. Duplicate entry 'A' for key 'code'

   Możesz przypisać kolumnę jako unikalną i próba wstawienia nowego wiersza z już istniejącą wartością dla tej kolumny spowoduje błąd.

Aby przezwyciężyć ten błąd, użyj INSERT IGNORE zamiast normalnego INSERT . Jeśli nowy wiersz, który próbujesz wstawić, nie powiela istniejącego rekordu, MySQL wstawia go jak zwykle. Jeśli rekord jest duplikatem, słowo kluczowe IGNORE odrzuca go bez generowania błędu.

INSERT IGNORE INTO userDetails VALUES (NULL ,'John', 'Doe', 1);