Debido a que la longitud almacenable del campo de la base de datos es demasiado pequeña, se ha alcanzado el límite de almacenamiento del tipo de carácter establecido, lo que genera un error y tipos de datos de uso común para el almacenamiento de datos.

Escenario del proyecto:

提示:这里简述项目相关背景:

Usando la base de datos MySQL, debido a que la longitud de almacenamiento del campo de la base de datos es demasiado pequeña, se ha alcanzado el límite de almacenamiento del tipo de carácter establecido, lo que genera un error cuando se almacenan los datos.

Descripción del problema

提示:这里描述项目中遇到的问题:

Debido a que la longitud de almacenamiento del campo de la base de datos es demasiado pequeña, se informa un error para el almacenamiento de datos y el mensaje de error es el siguiente:

Cause: com.mysql.cj.jdbc.exceptions.MysqlDataTruncation: Data truncation: Data too long for column 'remark' at row 1


Análisis de causa:

Sugerencia: Complete el análisis de la pregunta aquí:

La longitud de caracteres que se puede almacenar en el campo de la base de datos es demasiado pequeña, y el tipo de almacenamiento del campo no se selecciona como el tipo apropiado, y la longitud de caracteres almacenada en diferentes tipos de datos es diferente.
inserte la descripción de la imagen aquí
Por lo tanto, debemos establecer un espacio de almacenamiento razonable para los campos en la base de datos, de lo contrario, se producirá una falla de almacenamiento o una pérdida de espacio.

solución:

Consejo: Complete la solución específica al problema aquí:

Se debe seleccionar el tipo de campo apropiado y se debe establecer la longitud de caracteres adecuada de acuerdo con las necesidades reales.

Resumir:

Diseño y selección del tipo de campo

1. No debe haber demasiados campos en una sola tabla*

Se recomienda un máximo de 30

Más campos conducirán a la degradación del rendimiento y aumentarán la dificultad del desarrollo.

**

2. Use tipos de datos adecuados, pequeños y simples*

A. Tipo de cadena

Use char para longitud fija , varchar para longitud no fija y asigne espacio apropiado y suficiente

Cuando se consulta char , se eliminará el espacio al final

B. Tipo decimal

En general, puede usar float o double , que ocupa menos espacio, pero el almacenamiento puede perder precisión

Decimal puede almacenar decimales precisos, use decimal al almacenar datos financieros o requisitos de longitud

C. Hora y fecha

Por lo general, intente usar la marca de tiempo , ya que ocupa menos espacio y convertirá automáticamente la zona horaria, sin necesidad de preocuparse por la diferencia horaria regional

datetime y timestamp solo pueden almacenar la granularidad más pequeña es segundos, puede usar el tipo BIGINT para almacenar marcas de tiempo en el nivel de microsegundos

D. Gran blob de datos y texto

blob y text son tipos de datos de cadena diseñados para almacenar datos muy grandes, pero generalmente se recomienda evitar su uso

MySQL tratará cada blob y texto como un objeto independiente, y el motor de almacenamiento realizará un procesamiento especial al almacenar. Cuando el valor es demasiado grande, InnoDB utiliza un área de almacenamiento externo dedicada para el almacenamiento, almacena el puntero en la fila y luego almacena el valor real externamente. Estos pueden causar una sobrecarga de rendimiento grave

Blob es una cadena binaria y text es una cadena no binaria , las cuales pueden almacenar una gran cantidad de información. Blob almacena principalmente imágenes, información de audio, etc., mientras que el texto solo puede almacenar archivos de texto sin formato.

Tercero, intente establecer la columna en NOT NULL

a. Cuando se indexa una columna que puede ser NULL, ocupa más espacio de almacenamiento. Generalmente, cambiar una columna que puede ser NULL a NOT NULL genera menos mejoras.

b. Para las columnas que pueden ser NULL, MySQL necesita realizar un procesamiento especial al usar índices y comparaciones de valores, lo que consume una cierta cantidad de rendimiento y es más difícil de optimizar.

Sugerencia: por lo general, es mejor especificar las columnas como NO NULL a menos que realmente necesite almacenar valores NULL

4. Intenta usar un número entero como clave principal

a. Los tipos enteros suelen ser la mejor opción para las columnas de identidad porque son rápidos y pueden usar AUTO_INCREMENT

b. Los tipos de cadena deben evitarse como columnas de identidad, ya que ocupan mucho espacio y, por lo general, son más lentos que los tipos numéricos.

C. También se requiere más atención para cadenas completamente "aleatorias". Por ejemplo: cadenas generadas por MD5(), SHAI() o UUID(). Los nuevos valores generados por estas funciones también se distribuyen arbitrariamente en un espacio grande, lo que puede causar que INSERT y algunas declaraciones SELECT sean lentas

5. Tipo de datos y configuración de longitud correspondiente

Cada columna de la tabla tiene un tipo de datos correspondiente, que limita (o permite) los datos almacenados en esa columna.
Los tipos de datos comunes son: cadena, numérico, fecha y hora, tipos de datos binarios.
inserte la descripción de la imagen aquí
(1), tipo de datos de cadena
inserte la descripción de la imagen aquí
(2), tipo de datos numéricos
inserte la descripción de la imagen aquí
(3), tipo de datos de fecha y hora
inserte la descripción de la imagen aquí
(4), tipo de datos binarios
inserte la descripción de la imagen aquí

Supongo que te gusta

Origin blog.csdn.net/YHLSunshine/article/details/129388628
Recomendado
Clasificación