without used specification pagina length datos con column mysql sql mysql-error-1170

used - Error de MySQL: especificación de clave sin una longitud de clave



blob/text column used in key specification without a key length (13)

Además, si desea utilizar el índice en este campo, debe usar el motor de almacenamiento MyISAM y el tipo de índice FULLTEXT.

Tengo una tabla con una clave principal que es un varchar (255). Han surgido algunos casos donde 255 caracteres no son suficientes. Intenté cambiar el campo a un texto, pero aparece el siguiente error:

BLOB/TEXT column ''message_id'' used in key specification without a key length

¿Cómo puedo arreglar esto?

edición: también debo señalar que esta tabla tiene una clave primaria compuesta con varias columnas.

Agregue otra columna varChar (255) (con el valor predeterminado como cadena vacía no nula) para contener el desbordamiento cuando 255 caracteres no sean suficientes, y cambie esta PK para usar ambas columnas. Sin embargo, esto no suena como un esquema de base de datos bien diseñado, y recomendaría que un modelador de datos analice lo que tiene con vistas a refactorizarlo para una mayor normalización.

Debe cambiar el tipo de columna a varchar o integer para la indexación.

Debe definir qué parte inicial de una columna de TEXT desea indexar.

InnoDB tiene una limitación de 768 bytes por clave de índice y no podrá crear un índice más largo que eso.

Esto funcionará bien:

CREATE TABLE t_length ( mydata TEXT NOT NULL, KEY ix_length_mydata (mydata(255))) ENGINE=InnoDB;

Tenga en cuenta que el valor máximo del tamaño de la clave depende del conjunto de caracteres de la columna. Son 767 caracteres para un conjunto de caracteres de un solo byte como LATIN1 y solo 255 caracteres para UTF8 ( MySQL solo usa BMP que requiere un máximo de 3 bytes por carácter)

Si necesita que toda la columna sea la PRIMARY KEY , calcule el hash SHA1 o MD5 y utilícelo como PRIMARY KEY .

El error ocurre porque MySQL puede indexar solo los primeros N caracteres de una columna BLOB o TEXT . Por lo tanto, el error ocurre principalmente cuando hay un tipo de campo / columna de TEXT o BLOB o aquellos que pertenecen a tipos de TEXT o BLOB , como TINYBLOB , MEDIUMBLOB , LONGBLOB , TINYTEXT , MEDIUMTEXT y LONGTEXT que intenta hacer una clave primaria o un índice. Con BLOB completo o TEXT sin el valor de longitud, MySQL no puede garantizar la singularidad de la columna ya que es de tamaño variable y dinámico. Por lo tanto, cuando se usan tipos BLOB o TEXT como un índice, se debe proporcionar el valor de N para que MySQL pueda determinar la longitud de la clave. Sin embargo, MySQL no admite un límite de longitud de clave en TEXT o BLOB . TEXT(88) simplemente no funcionará.

El error también aparecerá cuando intente convertir una columna de tabla de tipo non-TEXT y non-BLOB , como VARCHAR y ENUM en tipo TEXT o BLOB , con la columna ya definida como restricciones o índice únicos. El comando Alter Table SQL fallará.

La solución al problema es eliminar la columna TEXT o BLOB del índice o restricción única o establecer otro campo como clave principal. Si no puede hacerlo y desea poner un límite en la columna TEXT o BLOB , intente usar el tipo VARCHAR y coloque un límite de longitud en él. De forma predeterminada, VARCHAR está limitado a un máximo de 255 caracteres y su límite debe especificarse implícitamente dentro de un corchete justo después de su declaración, es decir, VARCHAR(200) lo limitará solo a 200 caracteres.

A veces, aunque no use el tipo relacionado con TEXT o BLOB en su tabla, también puede aparecer el Error 1170. Ocurre en una situación como cuando usted especifica la columna VARCHAR como clave principal, pero establece incorrectamente su longitud o tamaño de caracteres. VARCHAR solo acepta hasta 256 caracteres, por lo que cualquier cosa como VARCHAR(512) forzará a MySQL a convertir automáticamente VARCHAR(512) a un tipo de datos SMALLTEXT , que posteriormente falla con el error 1170 en la longitud de la clave si la columna se usa como principal Índice clave o único o no único. Para resolver este problema, especifique una cifra inferior a 256 como el tamaño para el campo VARCHAR .

Referencia: MySQL Error 1170 (42000): Columna BLOB / TEXT usada en la especificación de clave sin una longitud de clave

La solución al problema es que en su CREATE TABLE , puede agregar la restricción UNIQUE ( problemtextfield(300) ) después de la columna, crear definiciones para especificar una longitud de key de 300 caracteres para un campo de TEXT , por ejemplo. Entonces, los primeros 300 caracteres del campo TEXT campo de TEXT necesitarían ser únicos, y cualquier diferencia después de eso sería ignorada.

MySQL no permite indexar un valor completo de las columnas BLOB , TEXT y VARCHAR largas porque los datos que contienen pueden ser enormes, e implícitamente el índice de DB será grande, lo que significa que no hay beneficio del índice.

MySQL requiere que se definan los primeros N caracteres para ser indexados, y el truco es elegir un número N que sea lo suficientemente largo para dar una buena selectividad, pero lo suficientemente corto para ahorrar espacio. El prefijo debe ser lo suficientemente largo como para que el índice sea tan útil como lo sería si hubiera indexado toda la columna.

Antes de seguir adelante vamos a definir algunos términos importantes. La selectividad del índice es la relación del total de valores indexados distintos y el número total de filas . Aquí hay un ejemplo para la tabla de prueba:

+-----+-----------+ | id | value | +-----+-----------+ | 1 | abc | | 2 | abd | | 3 | adg | +-----+-----------+

Si indexamos solo el primer carácter (N = 1), la tabla de índices se verá como la siguiente tabla:

+---------------+-----------+ | indexedValue | rows | +---------------+-----------+ | a | 1,2,3 | +---------------+-----------+

En este caso, la selectividad del índice es igual a IS = 1/3 = 0.33.

Veamos ahora qué sucederá si aumentamos el número de caracteres indexados a dos (N = 2).

+---------------+-----------+ | indexedValue | rows | +---------------+-----------+ | ab | 1,2 | | ad | 3 | +---------------+-----------+

En este escenario, IS = 2/3 = 0.66, lo que significa que aumentamos la selectividad del índice, pero también hemos aumentado el tamaño del índice. El truco consiste en encontrar el número mínimo N que dará lugar a la selectividad máxima del índice .

Hay dos enfoques que puede hacer cálculos para su tabla de base de datos. Voy a hacer demostración en este volcado de base de datos .

Digamos que queremos agregar la columna last_name en los empleados de la tabla al índice, y queremos definir el número más pequeño N que producirá la mejor selectividad de índice.

Primero vamos a identificar los apellidos más frecuentes:

select count(*) as cnt, last_name from employees group by employees.last_name order by cnt +-----+-------------+ | cnt | last_name | +-----+-------------+ | 226 | Baba | | 223 | Coorg | | 223 | Gelosh | | 222 | Farris | | 222 | Sudbeck | | 221 | Adachi | | 220 | Osgood | | 218 | Neiman | | 218 | Mandell | | 218 | Masada | | 217 | Boudaillier | | 217 | Wendorf | | 216 | Pettis | | 216 | Solares | | 216 | Mahnke | +-----+-------------+ 15 rows in set (0.64 sec)

Como puede ver, el apellido Baba es el más frecuente. Ahora vamos a encontrar los prefijos de último nombre que ocurren con más frecuencia, comenzando con los prefijos de cinco letras.

+-----+--------+ | cnt | prefix | +-----+--------+ | 794 | Schaa | | 758 | Mande | | 711 | Schwa | | 562 | Angel | | 561 | Gecse | | 555 | Delgr | | 550 | Berna | | 547 | Peter | | 543 | Cappe | | 539 | Stran | | 534 | Canna | | 485 | Georg | | 417 | Neima | | 398 | Petti | | 398 | Duclo | +-----+--------+ 15 rows in set (0.55 sec)

Hay muchas más apariciones de cada prefijo, lo que significa que tenemos que aumentar el número N hasta que los valores sean casi los mismos que en el ejemplo anterior.

Aquí están los resultados para N = 9

select count(*) as cnt, left(last_name,9) as prefix from employees group by prefix order by cnt desc limit 0,15; +-----+-----------+ | cnt | prefix | +-----+-----------+ | 336 | Schwartzb | | 226 | Baba | | 223 | Coorg | | 223 | Gelosh | | 222 | Sudbeck | | 222 | Farris | | 221 | Adachi | | 220 | Osgood | | 218 | Mandell | | 218 | Neiman | | 218 | Masada | | 217 | Wendorf | | 217 | Boudailli | | 216 | Cummings | | 216 | Pettis | +-----+-----------+

Aquí están los resultados para N = 10.

+-----+------------+ | cnt | prefix | +-----+------------+ | 226 | Baba | | 223 | Coorg | | 223 | Gelosh | | 222 | Sudbeck | | 222 | Farris | | 221 | Adachi | | 220 | Osgood | | 218 | Mandell | | 218 | Neiman | | 218 | Masada | | 217 | Wendorf | | 217 | Boudaillie | | 216 | Cummings | | 216 | Pettis | | 216 | Solares | +-----+------------+ 15 rows in set (0.56 sec)

Estos son muy buenos resultados. Esto significa que podemos hacer un índice en la columna last_name indexando solo los primeros 10 caracteres. En la columna de definición de la tabla, last_name se define como VARCHAR(16) , y esto significa que hemos guardado 6 bytes (o más si hay caracteres UTF8 en el último nombre) por entrada. En esta tabla hay 1637 valores distintos multiplicados por 6 bytes, aproximadamente 9 KB, e imagínese cómo crecería este número si nuestra tabla contiene millones de filas.

Puedes leer otras formas de calcular el número de N en mis posts. Los índices de prefijo en MySQL .

No tienen valores largos como clave principal. Eso destruirá tu rendimiento. Consulte el manual de mysql, sección 13.6.13 ''Ajuste y resolución de problemas de InnoDB''.

En su lugar, tenga una clave int de sustitución como principal (con auto_increment), y su clave loong como única ÚNICA secundaria.

Otra excelente manera de lidiar con esto es crear su campo TEXTO sin la restricción única y agregar un campo VARCHAR para hermanos que sea único y contenga un resumen (MD5, SHA1, etc.) del campo TEXTO. Calcule y almacene el resumen sobre todo el campo TEXTO cuando inserte o actualice el campo TEXTO, entonces tiene una restricción de singularidad en todo el campo TEXTO (en lugar de en una parte importante) que se puede buscar rápidamente.

Puede especificar la longitud de la clave en la solicitud de modificación de la tabla, algo así como:

alter table authors ADD UNIQUE(name_first(20), name_second(20));

Usar asi

@Id @Column(name = "userEmailId", length=100) private String userEmailId;

Vaya a mysql edit table -> cambie el tipo de columna a varchar(45) .