El motor de almacenamiento de tablas para <TABLE> no tiene esta opción en pedido por consulta (ERROR 1031)

80

El motor de almacenamiento de tablas para <TABLE> no tiene esta opción.

Este es el error devuelto por MySQL en una order byconsulta. El tipo de columna esvarchar(2000) .

Consulta:

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

Error devuelto:

ERROR 1031 (HY000): el motor de almacenamiento de tablas para 'dbo.table_1' no tiene esta opción.

¿Por qué pasó esto? ¿Y cómo puedo solucionarlo?

mysql sql Umair Iqbal
fuente
use comillas inversas separadas para el nombre de la base de datos dboy el nombre de la tablatable_1
Ravinder Reddy
La declaración debería verse asíselect * from `dbo`.`table_1` order by textT
Ravinder Reddy
Puede ser un problema demax_length_for_sort_data
Abhik Chakraborty
Compruebe esto: dev.mysql.com/doc/refman/5.0/en/example-storage-engine.html
Stanislovas Kalašnikovas
2
Ha omitido tres datos importantes y ninguno de los comentaristas los ha solicitado. - ¿Qué versión de MySQL? ¿Qué motor de almacenamiento? Proporcionar SHOW CREATE TABLE table_1.
Rick James

Respuestas:

172

Este problema parece ocurrir cuando está importando una definición de tabla que se creó con MyISAM pero luego se cambió a InnoDB; las ROW_FORMATopciones resultantes parecen no ser válidas.

Si está intentando importar una base de datos exportada y encuentra este problema, simplemente puede buscar y reemplazar ROW_FORMAT=FIXEDcon nada.

Usé lo siguiente para hacerlo realmente rápido:

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

¡Problema resuelto! Gracias a jbrahy por señalar que el problema era ROW_FORMAT.

EDITAR: actualizado para funcionar para más plataformas según la sugerencia de @ seven

jhaagsma
fuente
Esto funcionó para mí, se me bloqueó la importación desde un archivo de volcado y ahora importa.
Blackwood
buen rapidito! me salvó
Tim Kretschmer
2
@haagsma sugiere editar para "-ie" en lugar de solo sed -e. -ie funciona tanto en versiones GNU como BSD de sed. Soy os osx y -i funciona de manera diferente)sed -ie 's/ROW_FORMAT=FIXED//g' backup.sql
siete
3
Si @jbrahy señaló el problema, ¿no debería recibir la respuesta? Parece extraño que él tenga 4 puntos y tú 32 cuando la suya fue la respuesta correcta.
Johnny 3653925
1
Según este informe de error , FIXEDse cambia silenciosamente a COMPACTen MySQL 5.6 y antes. Eso parece sugerir que sed -ie 's/ROW_FORMAT=FIXED/ROW_FORMAT=COMPACT/g' backup.sqlsería una solución "más segura" en términos de mantener el mismo comportamiento.
Steen Schütt
11

Recibo el mismo error cuando importo una definición de tabla que es InnoDB con ROW_FORMAT = DYNAMIC en ella. La tabla se creó con un motor MyISAM pero luego la cambié a InnoDB. Cuando eliminé ROW_FORMAT = DYNAMIC de la declaración de creación de tabla y recreé la tabla, funcionó bien. Mi solución a tu problema sería esta.

show create table `dbo.table_1`;

luego tome la salida de ese comando y elimine ROW_FORMAT = DYNAMIC luego cambie el nombre de la tabla a dbo.table_1_old

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

Luego ejecute la declaración de creación de tabla desde el primer paso, es decir

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

Luego, vuelva a llenar su tabla con los datos antiguos.

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

Entonces deberías poder ejecutar tu SQL original

select * from `dbo.table_1` order by textT;
jbrahy
fuente
10

También puedes probar esto: 

ALTER TABLE `dbo.table_1` ROW_FORMAT = DEFAULT ;
Michele Manzato
fuente
Gracias, esto funcionó perfectamente para mí y me ahorró tener que reconstruir innodb múltiples tablas llenas de claves externas.
Ian
2

Este problema parece ocurrir cuando está importando una definición de tabla a MySQL 5.7 que se creó con MySQL 5.6 y versiones anteriores. El mismo error puede producirb por la opción KEY_BUFFER_SIZE = 8192 y tamaños similares definidos en bytes para INNODB ENGINE. Tuve este error cuando estoy importando la base desde sql-dump. Decisión: sed -ie 's / KEY_BLOCK_SIZE = 16384 // g' my-file-sql_dump.sql

ANF-67
fuente
1

Estaba enfrentando este problema y mi archivo de respaldo era un .zsqlarchivo encriptado . Así que modifiqué my.cnf agregando innodb_strict_mode = off. Funcionó bien

prgmrDev
fuente