especificaciones de diseño de tablas mysql

Convenciones de nombres

Los nombres de tablas y campos deben utilizar letras minúsculas o números y no se utilizan abreviaturas en inglés.

No importa si es un poco más largo, lo mejor es hacérselo saber a otros desarrolladores.

Nombre del índice de clave principal: pk_field nombre Nombre de índice único: uk_field nombre Nombre de índice común: jdx_field nombre

Elija el tipo de campo apropiado

Elija tipos de campo con espacio de almacenamiento pequeño tanto como sea posible, tinyint smallint int bigint comienza de izquierda a derecha

tipo de datos	característica	escenas a utilizar
`tinyint`	Entero con signo de 1 byte, que va de -128 a 127 o de 0 a 255 (sin signo)	Almacena valores booleanos, estados, indicadores y otros datos con valores de rango bajo
`smallint`	Entero con signo de 2 bytes, que va de -32 768 a 32 767 o de 0 a 65 535 (sin signo)	Almacene valores enteros pequeños, como año, cantidad del pedido, etc.
`int`	Entero con signo de 4 bytes, que va de -2.147.483.648 a 2.147.483.647 o de 0 a 4.294.967.295 (sin signo)	Almacene valores enteros regulares, como ID de usuario, edad, cantidad, etc.
`bigint`	Entero con signo de 8 bytes, el rango de valores es -9.223.372.036.854.775.808 a 9.223.372.036.854.775.807 o 0 a 18.446.744.073.709.551.615 (sin signo)	Almacene valores enteros grandes, como claves primarias, números de pedido, etc.

Tipo decimal, como cantidad, seleccione decimal

Asegúrese de usar bidecimal, ¡Shigen ha solucionado un error enorme escrito por sus predecesores!

Las longitudes de las cadenas almacenadas son casi iguales, utilizando el tipo de cadena char de longitud fija.
cadena de longitud variable varchar, la longitud no debe exceder 5000
Si el valor almacenado es demasiado grande, cambie el tipo de campo a texto y cree una tabla separada con la clave principal correspondiente.

Elija la longitud de campo adecuada

Optimice el espacio de almacenamiento de datos. Si la longitud del campo se establece demasiado grande, se desperdiciará espacio de almacenamiento. Si la longitud del campo se establece demasiado pequeña, puede provocar el truncamiento de datos o un error de inserción.

Priorizar la eliminación lógica sobre la eliminación física

Dificultad para recuperar datos eliminados físicamente
La eliminación física hará que la clave principal ya no sea continua
No se recomienda eliminar físicamente datos en tablas comerciales principales.

Campos comunes requeridos por cada tabla.

Los diferentes campos comunes tienen diferentes nombres en inglés, pero todos se recomiendan en la especificación.

identificación	significado	debe
crear_tiempo	tiempo de creación	debe
tiempo de actualizacion	cambiar la hora	debe
versión	bloqueo optimista	no es necesario
reafirmar	Anotación de datos	no es necesario
modificado por	Modificador	no es necesario
creador	fundador	no es necesario

No tengas demasiados campos en una tabla.

No exceda los 20 campos. Si la tabla tiene demasiados campos, los datos almacenados en la tabla pueden ser muy grandes y la eficiencia de la consulta se reducirá. Simplemente divida la tabla grande en tablas pequeñas y haga que sus claves principales sean iguales.

Utilice not null para definir campos siempre que sea posible

Establezca el campo en una cadena vacía o un valor constante

no nulo previene problemas de puntero nulo
El almacenamiento de valores nulos también requiere espacio adicional, lo que resulta en operaciones de comparación más complejas y dificulta que el optimizador optimice SQL.
Los valores nulos pueden causar fallas en el índice

índice de diseño

Los campos con condiciones de consulta generalmente deben indexarse

El índice de una sola tabla no debe exceder de 5
Los campos que no son muy distinguibles no agregan índices (género)
Evite fallas de índice (función incorporada de mysql)
Demasiados índices, utilice la optimización de índices conjuntos

No utilice asociaciones de claves externas

Existen problemas de rendimiento, problemas de bloqueo de simultaneidad e inconvenientes en el uso de claves externas. Cada eliminación y actualización debe considerar restricciones de clave externa
No se pueden utilizar subbases de datos ni subtablas.

No se recomienda utilizar procedimientos almacenados y desencadenantes.

Procedimiento almacenado:

Una o más sentencias SQL que se han precompilado en un procedimiento ejecutable.

desencadenar:

Un fragmento de código que se ejecuta automáticamente cuando se activa un evento.

Se pueden implementar modificaciones en cascada utilizando tablas relacionadas en la base de datos.
Supervisar los cambios en un campo de una tabla y tomar las medidas adecuadas
Generar ciertos números comerciales
El abuso causa dificultades en el mantenimiento de bases de datos y aplicaciones
MySQL no es muy maduro para procedimientos almacenados, activadores, etc., y no tiene un procesamiento completo de registros de errores, por lo que no se recomienda su uso.

Experiencia de optimización en escritura SQL.

Intente no utilizar select * para consultas
Si el resultado de la consulta solo necesita un registro o solo el registro más grande/más pequeño, se recomienda utilizar el límite 1.
Evite el uso de la cláusula o en donde para conectar condiciones
Optimizar el problema de paginación de profundidad límite
donde las condiciones limitan los datos que se consultarán para evitar devolver filas redundantes
Evite operaciones de expresión en campos en cláusulas donde
Para optimizar el índice, debería considerar agregar índices a las columnas involucradas en dónde y ordenar por.
Se han insertado demasiados datos. Seleccione la inserción por lotes.