Silnik magazynu tabel dla <TABLE> nie ma tej opcji na zamówienie według zapytania (ERROR 1031)

80

Mechanizm przechowywania tabel dla <TABLE> nie ma tej opcji.

To jest błąd zwracany przez MySQL w order byzapytaniu. Typ kolumny to varchar(2000).

Pytanie:

select * from `dbo.table_1` order by textT;

Zwrócony błąd:

BŁĄD 1031 (HY000): Silnik przechowywania tabel dla „dbo.table_1” nie ma tej opcji.

Dlaczego to się dzieje? Jak mogę to naprawić?

mysql sql Umair Iqbal
źródło
użyj oddzielnych lewych apostrofów zarówno dla nazwy bazy danych, jak dboi nazwy tabelitable_1
Ravinder Reddy,
oświadczenie powinno wyglądać takselect * from `dbo`.`table_1` order by textT
Ravinder Reddy
Może to byćmax_length_for_sort_data
Abhik Chakraborty,
Sprawdź to: dev.mysql.com/doc/refman/5.0/en/example-storage-engine.html
Stanislovas Kalašnikovas Kwietnia
2
Pominąłeś trzy ważne informacje i żaden z komentujących o nie nie prosił. - Jaka wersja MySQL? Jaki silnik pamięci masowej? Zapewnij SHOW CREATE TABLE table_1.
Rick James

Odpowiedzi:

172

Wydaje się, że ten problem występuje podczas importowania definicji tabeli, która została utworzona za pomocą MyISAM, ale później została przełączona do InnoDB; wynikowyROW_FORMAT opcje wydają się być nieprawidłowe.

Jeśli próbujesz zaimportować wyeksportowaną bazę danych i napotkasz ten problem, możesz po prostu wyszukać i zamienić ROW_FORMAT=FIXED nic.

Użyłem następujących, aby zrobić to naprawdę szybko:

sed -ie 's/ROW_FORMAT=FIXED//g' backup.sql

Problem rozwiązany! Dziękuję jbrahy za wskazanie, że to ROW_FORMAT był problemem.

EDYCJA: Zaktualizowano, aby działał na większej liczbie platform zgodnie z sugestią @ seven

jhaagsma
źródło
To zadziałało dla mnie, zostałem zablokowany przed importowaniem z pliku zrzutu, a teraz importuje.
Blackwood
niezły szybki numerek! uratował mnie
Tim Kretschmer
2
@haagsma sugeruje edycję dla „-ie” zamiast tylko sed -e. -ie działa zarówno na wersjach seda GNU, jak i BSD. Jestem OSX i -i działa inaczej)sed -ie 's/ROW_FORMAT=FIXED//g' backup.sql
siedem
3
Jeśli @jbrahy wskazał na problem, czy nie powinien otrzymać odpowiedzi? Wydaje się dziwne, że ma 4 punkty, a ty masz 32, gdy jego odpowiedź była poprawna.
Johnny 3653925
1
Zgodnie z tym zgłoszeniem błędu , FIXEDzostał po cichu zmieniony na COMPACTMySQL 5.6 i wcześniejsze. Wydaje się to sugerować, że sed -ie 's/ROW_FORMAT=FIXED/ROW_FORMAT=COMPACT/g' backup.sqlbyłoby to „bezpieczniejsze” rozwiązanie pod względem utrzymania tego samego zachowania.
Steen Schütt
11

Otrzymuję ten sam błąd, gdy importuję definicję tabeli, która jest InnoDB z ROW_FORMAT = DYNAMIC w nim. Tabela została utworzona za pomocą silnika MyISAM, ale później przeniosłem ją na InnoDB. Kiedy usunąłem ROW_FORMAT = DYNAMIC z instrukcji tworzenia tabeli i ponownie utworzyłem tabelę, działało dobrze. Moim rozwiązaniem twojego problemu byłoby to.

show create table `dbo.table_1`;

następnie weź dane wyjściowe z tego polecenia i usuń ROW_FORMAT = DYNAMIC, a następnie zmień nazwę tabeli na dbo.table_1_old

rename table `dbo.table_1` to `dbo.table_1_old`;

Następnie wykonaj instrukcję create table z pierwszego kroku, tj

-- don't use this create as there are missing columns use yours
create table `dbo.table_1` (textT VARCHAR(255));

Następnie ponownie wypełnij tabelę starymi danymi.

insert into `dbo.table_1` select * from `dbo.table_1_old`;

Wtedy powinieneś być w stanie wykonać oryginalny SQL

select * from `dbo.table_1` order by textT;
jbrahy
źródło
10

Możesz także spróbować tego: 

ALTER TABLE `dbo.table_1` ROW_FORMAT = DEFAULT ;
Michele Manzato
źródło
Dziękuję, to zadziałało idealnie dla mnie i zaoszczędziło mi konieczności przebudowywania wielu tabel innodb pełnych kluczy obcych.
Ian
2

Wydaje się, że ten problem występuje podczas importowania definicji tabeli do MySQL 5.7, która została utworzona za pomocą MySQL 5.6 i wcześniejszych. Ten sam błąd może być spowodowany opcją KEY_BUFFER_SIZE = 8192 i podobnymi rozmiarami zdefiniowanymi w bajtach dla INNODB ENGINE. Wystąpił ten błąd podczas importowania bazy z sql-dump. Decyzja: sed -ie 's / KEY_BLOCK_SIZE = 16384 // g' my-file-sql_dump.sql

ANF-67
źródło
1

Miałem do czynienia z tym problemem, a mój plik kopii zapasowej był .zsqlplikiem zaszyfrowanym . Więc zmodyfikowałem my.cnf, dodając innodb_strict_mode = off. Działało dobrze

prgmrDev
źródło