Conocimientos esenciales para el diseño de bases de datos. Ésta es la piedra angular de los avances futuros.
Tabla de contenido
Tabla de contenido
1. Especificación del comando de la base de datos
En segundo lugar, las especificaciones de diseño básicas de la base de datos.
Tres, especificaciones de diseño de campo de base de datos
Cuatro, especificaciones de diseño de índices
Cinco recomendaciones de columnas de índice comunes
Seis, cómo elegir el orden de las columnas de índice.
Siete, evite crear índices redundantes e índices duplicados
Ocho, dé prioridad a los índices de cobertura
Nueve, especificación SET de índice
10. Especificaciones de desarrollo de bases de datos SQL
11. Código de conducta para el funcionamiento de bases de datos
1. Especificación del comando de la base de datos
-
· Todos los nombres de los objetos de la base de datos deben usar letras minúsculas y estar separados por guiones bajos
-
· Todos los nombres de objetos de base de datos prohíben el uso de palabras clave reservadas de MySQL (si el nombre de la tabla contiene palabras clave para la consulta, debe encerrarlo entre comillas simples)
-
· El nombre de los objetos de la base de datos debe poder reconocerse por sus nombres, y el número final no debe exceder los 32 caracteres
-
· Las tablas de bases de datos temporales deben tener el prefijo tmp_ y el sufijo con la fecha, y las tablas de respaldo deben tener el prefijo bak_ y el sufijo con la fecha (marca de tiempo)
-
· Todos los nombres de columna y tipos de columna que almacenan los mismos datos deben ser consistentes (generalmente como columnas asociadas, si los tipos de columna asociados son inconsistentes durante la consulta, la conversión implícita de tipos de datos se realizará automáticamente, lo que hará que el índice de la columna deje de ser válido y reducirá la eficiencia de la consulta)
En segundo lugar, las especificaciones de diseño básicas de la base de datos.
1. Todas las tablas deben usar el motor de almacenamiento Innodb.
No hay requisitos especiales (es decir, funciones que Innodb no puede cumplir, como almacenamiento de columnas, datos de espacio de almacenamiento, etc.), todas las tablas deben usar el motor de almacenamiento Innodb (Myisam se usa por defecto antes de mysql5.5, 5.6 En el futuro, el valor predeterminado es Innodb) Innodb admite transacciones, admite bloqueos de nivel de fila, mejor recuperación, mejor rendimiento en alta concurrencia
2. Los conjuntos de caracteres de la base de datos y la tabla utilizan UTF8 de manera uniforme y la compatibilidad es mejor. El conjunto de caracteres uniforme puede evitar La conversión del juego de caracteres generó caracteres confusos, es necesario convertir diferentes juegos de caracteres antes de que la comparación provoque una falla en el índice
3. Todas las tablas y campos deben agregar comentarios, use la cláusula de comentarios para agregar comentarios de tabla y columna para mantener el diccionario de datos desde el principio
4. Intente controlar el tamaño de los datos de una sola tabla. Se recomienda controlarlo dentro de los 5 millones. 5 millones no es una limitación de la base de datos MySQL. Si la estructura de la tabla es demasiado grande, causará grandes problemas para modificar la estructura de la tabla, hacer copias de seguridad y restaurar. Puede usar datos históricos para archivar (aplicación (Para datos de registro), subtabla de base de datos (aplicada a datos comerciales) y otros medios para controlar la cantidad de datos.
5. Tenga cuidado al usar la tabla de particiones MySQL. La
tabla de particiones está representada físicamente como varios archivos y lógicamente como una tabla, seleccione cuidadosamente las particiones La eficiencia clave de las consultas entre particiones puede ser menor. Se recomienda administrar macrodatos en una tabla dividida físicamente.
6. Separe los datos calientes y fríos tanto como sea posible, reduzca el ancho de la tabla.
MySQL limita cada tabla para almacenar hasta 4096 columnas y el tamaño de cada fila de datos No puede exceder los 65535 bytes para reducir la E / S del disco y garantizar la tasa de aciertos de la memoria caché de datos activos (cuanto más ancha sea la tabla, mayor será la memoria ocupada cuando la tabla se carga en el grupo de búfer de memoria y también se consumirán más E / S), más efectivo Utilice la caché para evitar la lectura de datos fríos inútiles. Las columnas que a menudo se usan juntas se colocan en una tabla (para evitar más operaciones asociadas)
7. Está prohibido crear campos reservados en la tabla
El nombre de los campos reservados es difícil de identificar el nombre. Los campos reservados no pueden confirmar el tipo de datos almacenados, por lo que es imposible seleccionar el tipo apropiado para modificar el tipo de campo reservado, y la tabla se bloqueará.
8. Está prohibido almacenar imágenes en la base de datos , El archivo y otros datos binarios grandes
suelen ser archivos grandes, lo que provocará un rápido crecimiento en el volumen de datos en poco tiempo. Cuando la base de datos se lee de la base de datos, generalmente se realizan una gran cantidad de operaciones de E / S aleatorias. Cuando el archivo es grande, las operaciones de E / S requieren mucho tiempo y generalmente se almacenan En el servidor de archivos, la base de datos solo almacena información de direcciones de archivos
9. Está prohibido realizar pruebas de estrés de la base de datos en línea
10. Está prohibido conectarse directamente a la base de datos del entorno desde el entorno de desarrollo y el entorno de prueba.
Tres, especificaciones de diseño de campo de base de datos
1. Seleccione preferentemente el tipo de datos más pequeño que satisfaga las necesidades de almacenamiento. Cuanto mayor sea el campo de la columna del
motivo
, mayor será el espacio necesario para la indexación, de modo que el número de nodos de índice que se pueden almacenar en una página también será cada vez menor. Menos, se requieren más tiempos de E / S durante el recorrido y peor es el rendimiento del índice
Método
1) Convertir una cadena en un almacenamiento de tipo digital, como: convertir una dirección IP en datos enteros.
MySQL proporciona dos métodos para tratar con direcciones IP:
Antes de insertar datos, use inet_aton para convertir la dirección IP en un número entero, lo que puede ahorrar espacio. Cuando muestre datos, use inet_ntoa para convertir la dirección IP entera en pantalla de dirección.
2) Para datos no negativos (como ID autoincrementante, IP entera), se prefiere el entero sin signo para el almacenamiento
porque: sin firmar puede duplicar el espacio de almacenamiento en comparación con el firmado
La N en VARCHAR (N) representa el número de caracteres, no el número de bytes
Utilice UTF8 para almacenar 255 caracteres chinos Varchar (255) = 765 bytes. Una longitud excesiva consumirá más memoria.
2. Evite el uso de tipos de datos TEXT y BLOB. El tipo TEXT más común puede almacenar 64k de datos
. Se recomienda separar las columnas BLOB o TEXT en tablas extendidas separadas. Las
tablas temporales de memoria Mysql no son Admite tipos de datos grandes, como TEXT y BLOB. Si dichos datos se incluyen en la consulta, las tablas temporales en memoria no se pueden usar en operaciones como la clasificación y se deben usar tablas temporales de disco.
Y para este tipo de datos, Mysql todavía tiene que realizar una segunda consulta, lo que hará que el rendimiento de sql sea muy deficiente, pero no significa que no se deban utilizar dichos tipos de datos.
Si debe usarlo, se recomienda separar la columna BLOB o TEXT en una tabla extendida separada. No use select * al realizar consultas. Solo necesita recuperar las columnas necesarias. No consulte la columna cuando no necesite los datos en la columna TEXT.
· Los tipos TEXT o BLOB solo pueden usar índices de prefijo.
Debido a que MySQL tiene restricciones en la longitud de los campos de índice, los tipos TEXT solo pueden usar índices de prefijo y no puede haber valores predeterminados en las columnas de TEXT.
3. Evite usar el tipo ENUM
· Modificar el valor ENUM requiere el uso de la instrucción ALTER
· La operación ORDER BY del tipo ENUM es ineficiente y requiere operaciones adicionales
· Está prohibido usar valores numéricos como el valor de enumeración de ENUM
4. Intente definir todas las columnas como
razones NOT NULL :
· La columna de índice NULL necesita espacio adicional para guardar, por lo que ocupa más espacio;
· El valor NULL debe tratarse especialmente durante la comparación y el cálculo
5. Utilice TIMESTAMP (4 bytes) o tipo DATETIME (8 palabras) Sección) tiempo de almacenamiento
TIMESTAMP almacena el intervalo de tiempo 1970-01-01 00:00:01 ~ 2038-01-19-03: 14: 07.
TIMESTAMP ocupa 4 bytes, que es lo mismo que INT, pero es más legible que INT
. El almacenamiento de tipo DATETIME se usa para el almacenamiento que excede el rango de valores de TIMESTAMP.
La gente suele usar cadenas para almacenar datos de tipo fecha (práctica incorrecta):
· Desventaja 1: No se pueden usar funciones de fecha para el cálculo y la comparación
· Desventaja 2: Usar cadenas para almacenar fechas ocupa más espacio
6. Relacionado con las finanzas Los datos de cantidad deben usar el tipo decimal.
· Punto flotante de no precisión: float, doble
· Punto flotante preciso: El
tipo decimal decimal es un número de punto flotante preciso, que no perderá precisión durante el cálculo. El espacio ocupado está determinado por el ancho definido, cada 4 bytes pueden almacenar 9 dígitos y el punto decimal ocupa un byte. Puede usarse para almacenar datos enteros mayores que bigint.
Cuatro, especificaciones de diseño de índices
1. Limite el número de índices en cada tabla. Se recomienda que no haya más de 5
índices en una sola tabla. ¡ Cuantos más índices no mejor! Los índices pueden mejorar la eficiencia y también pueden reducirla.
Los índices pueden aumentar la eficiencia de las consultas, pero también reducir la eficiencia de las inserciones y actualizaciones, e incluso en algunos casos, reducir la eficiencia de las consultas.
Porque cuando el optimizador de mysql elige cómo optimizar la consulta, evaluará cada índice que se puede usar de acuerdo con la información unificada para generar el mejor plan de ejecución.Si hay muchos índices al mismo tiempo, se pueden usar para la consulta. Aumentará el tiempo que tarda el optimizador de mysql en generar un plan de ejecución y también reducirá el rendimiento de las consultas.
2. Está prohibido crear un índice separado para cada columna de la tabla.
Antes de la versión 5.6, un SQL solo puede usar un índice en una tabla. Después de 5.6, aunque existe un método de optimización para combinar índices, todavía está lejos de usar uno El método de consulta del índice conjunto es bueno
3. Cada tabla Innodb debe tener una clave primaria
Innodb es una tabla organizada por índices: el orden lógico de almacenamiento de datos y el orden del índice son los mismos.
Cada tabla puede tener varios índices, pero solo puede haber un orden de almacenamiento de la tabla. Innodb organiza la tabla en el orden del índice de clave principal.
No utilice columnas que se actualizan con frecuencia como claves primarias y no aplique claves primarias de varias columnas (equivalente a un índice conjunto) No utilice columnas UUID, MD5, HASH o cadenas como claves primarias (no se puede garantizar el crecimiento secuencial de datos).
Se recomienda utilizar un valor de ID de incremento automático para la clave principal.
Cinco recomendaciones de columnas de índice comunes
· Las columnas que aparecen en la cláusula WHERE de las declaraciones SELECT, UPDATE y DELETE
· Las columnas incluidas en ORDER BY, GROUP BY y DISTINCT
no crean un índice para todas las columnas que coinciden con los campos 1 y 2, generalmente 1, 2 Es mejor establecer un índice conjunto en los campos del campo
· Columnas asociadas de combinación de múltiples tablas
Seis, cómo elegir el orden de las columnas de índice.
El propósito de la indexación es buscar datos a través del índice, reducir la E / S aleatoria y aumentar el rendimiento de la consulta. Cuantos menos datos pueda filtrar el índice, menos datos se leerán del disco.
· La discriminación más alta se coloca en el lado más a la izquierda del índice conjunto (discriminación = el número de valores diferentes en la columna / el número total
de filas en la columna ); · Intente colocar la columna con la longitud de campo más pequeña en el lado izquierdo del índice conjunto (debido a la longitud del campo Cuanto más pequeña, mayor es la cantidad de datos que se pueden almacenar en una página y mejor es el rendimiento de IO);
· Las columnas más utilizadas se colocan en el lado izquierdo del índice conjunto (para que se puedan construir menos índices).
Siete, evite crear índices redundantes e índices duplicados
Porque esto aumentará el tiempo que tarda el optimizador de consultas en generar un plan de ejecución.
· Ejemplos de índices duplicados: clave primaria (id), índice (id), índice único (id)
· Ejemplos de índices redundantes: índice (a, b, c), índice (a, b), índice (a)
Ocho, dar prioridad a los índices de cobertura.
Para consultas frecuentes, dé prioridad al uso de un índice de cobertura.
Índice de cobertura: es un índice que contiene todos los campos de consulta (donde, seleccionar, ordenar por, agrupar por).
Los beneficios de un índice de cobertura:
· Evitar consultas secundarias de la indexación de tablas
Innodb . Innodb se almacena en el orden del índice agrupado. Para Innodb, el índice secundario almacenado en el nodo hoja es la información de la clave principal de la fila.
Si los datos son consultados por el índice secundario, después de encontrar el valor de clave correspondiente, la consulta secundaria debe realizarse a través de la clave principal. Obtenga los datos que realmente necesitamos. En un índice de cobertura, todos los datos se pueden obtener del valor de la clave del índice secundario, lo que evita consultas secundarias en la clave principal, reduce las operaciones de E / S y mejora la eficiencia de las consultas.
· La E / S aleatoria se puede convertir en E / S secuencial para acelerar la eficiencia de la consulta.
Debido a que el índice de cobertura se almacena en el orden de los valores clave, para la búsqueda de rango intensivo de E / S, es mucho menos E / S que leer cada fila de datos del disco al azar, por lo que El índice de cobertura también se puede utilizar para convertir la E / S de lectura aleatoria del disco en la E / S secuencial de la búsqueda de índice durante el acceso.
Nueve, especificación SET de índice
Trate de evitar el uso de restricciones de clave externa
· No se recomiendan las restricciones de clave externa (clave externa), pero se debe establecer un índice en la clave asociada entre la tabla y la tabla;
· Se pueden usar claves externas para garantizar la integridad referencial de los datos, pero se recomienda en los negocios Implementación de un extremo a otro:
· Las claves externas afectarán las operaciones de escritura de las tablas principal y secundaria, reduciendo así el rendimiento.
10. Especificaciones de desarrollo de bases de datos SQL
1. Se recomienda utilizar declaraciones preparadas para operaciones de base de datos. Las
declaraciones preparadas pueden reutilizar estos planes, reducir el tiempo requerido para la compilación de SQL y también pueden resolver el problema de inyección de SQL causado por SQL dinámico. Solo pasar parámetros es más eficiente que pasar declaraciones SQL. La misma oración se puede analizar una vez y usar varias veces para mejorar la eficiencia del procesamiento.
2. Evite la conversión implícita de tipos de datos. La
conversión implícita provocará una falla en el índice. Tales como: seleccione el nombre, el teléfono del cliente donde id = '111';
3. Haga un uso completo de los índices existentes en la tabla.
Evite el uso de condiciones de doble% de consulta.
Por ejemplo, un '% 123%' como ', (si no hay un% inicial, solo el% final, se puede usar el índice de la columna)
· Un SQL solo puede usar una columna en el índice compuesto para consultas de rango
como: , b, c columnas del índice conjunto, en la condición de consulta, hay una consulta de rango de la columna a, el índice de las columnas byc no se utilizará al definir el índice conjunto, si la columna a se va a utilizar para la búsqueda de rango Si este es el caso, coloque la columna a a la derecha del índice conjunto.
Use left join o no existe para optimizar el no en operación
porque usualmente no usa falla de índice.
4. Al diseñar la base de datos, debe considerar la expansión futura.
5. El programa se conecta a diferentes bases de datos y utiliza diferentes cuentas, y consulta entre bases de datos en dígitos.
Deje espacio para la migración de la base de datos y las subtablas de la base de datos
. Reduzca el acoplamiento comercial
. Evite los permisos. Riesgos de seguridad causados por un tamaño excesivo
6. Está prohibido usar SELECT * Debe usar SELECT <lista de campos> para realizar consultas.
Razones:
· Consume más CPU y IO para los recursos de ancho de banda de la red
· No se puede usar el índice de cobertura
· Puede reducir el impacto de los cambios en la estructura de la tabla.
7. Está prohibido usar declaraciones INSERT sin una lista de campos. Por
ejemplo: insertar en valores ('a', 'b', 'c');
insertar en t debe usarse (c1, c2, c3) valores ('a', 'b', 'c');
8. Evite el uso de subconsultas. Puede optimizar las subconsultas en operaciones de combinación.
Por lo general, las subconsultas están en la cláusula in y en la subconsulta Cuando es SQL simple (no incluye cláusulas de unión, agrupación, orden por y límite), la subconsulta se puede convertir en una consulta asociada para optimización.
Razones del rendimiento deficiente de la subconsulta:
· El conjunto de resultados de la subconsulta no puede utilizar el índice. Normalmente, el conjunto de resultados de la subconsulta se almacenará en una tabla temporal. No habrá índice en la tabla temporal de memoria o disco, por lo que el rendimiento de la consulta se verá afectado. Un cierto impacto;
· Especialmente para las subconsultas que devuelven un conjunto de resultados relativamente grande, mayor será el impacto en el rendimiento de la consulta;
· Dado que las subconsultas generarán una gran cantidad de tablas temporales y ningún índice, consumirán demasiada CPU y Los recursos de IO generan muchas consultas lentas.
9. Evite usar JOIN para asociar demasiadas
tablas.Para Mysql, hay una caché asociada, y el tamaño de la caché se puede establecer mediante el parámetro join_buffer_size.
En Mysql, si une una tabla para el mismo SQL, se asignará una caché asociada más. Si hay más tablas asociadas en un SQL, mayor será la memoria ocupada.
Si se utiliza una gran cantidad de operaciones de asociación de múltiples tablas en el programa, y la configuración de join_buffer_size no es razonable, fácilmente provocará un desbordamiento de la memoria del servidor, lo que afectará la estabilidad del rendimiento de la base de datos del servidor.
Al mismo tiempo, para las operaciones de asociación, se producirán operaciones de tabla temporal, afectando la eficiencia de la consulta. Mysql permite asociar hasta 61 tablas y se recomienda no exceder las 5.
10. Reducir el número de interacciones con la base de datos. La base de
datos es más adecuada para procesar operaciones por lotes y combinar varias operaciones idénticas, lo que puede mejorar la eficiencia del procesamiento.
11. Cuando se realizan juicios correspondientes a la misma columna, se usa en en lugar de o
en y el valor no debe exceder de 500 en operaciones Los índices se pueden utilizar de forma más eficaz o, en la mayoría de los casos, los índices se utilizan raramente.
12. Está prohibido usar order by rand () para la clasificación aleatoria, que
cargará todos los datos elegibles en la tabla en la memoria y luego clasificará todos los datos en la memoria de acuerdo con el valor generado aleatoriamente, y puede generar uno para cada fila. Valores aleatorios, si el conjunto de datos que cumple las condiciones es muy grande, consumirá una gran cantidad de recursos de CPU, IO y memoria.
Se recomienda obtener un valor aleatorio en el programa y luego obtener los datos de la base de datos
13. La cláusula WHERE prohíbe la conversión de funciones y el cálculo
de la columna El índice no se puede utilizar cuando la conversión de funciones o el cálculo se realizan en la columna.
· No recomendado:
· Recomendación:
14. Utilice UNION ALL en lugar de UNION cuando sea obvio que no habrá valores duplicados
. UNION colocará todos los datos de los dos conjuntos de resultados en una tabla temporal antes de realizar las operaciones de deduplicación
. UNION ALL ya no deduplicará el conjunto de resultados. Operación
15. Divida un SQL grande complejo en varios SQL pequeños
· Big SQL: lógicamente más complicado y requiere mucha CPU para los cálculos
· MySQL: un SQL solo puede usar una CPU para los cálculos
· SQL se puede pasar después de dividir Ejecución en paralelo para mejorar la eficiencia del procesamiento
11. Código de conducta para el funcionamiento de bases de datos
1. Las operaciones de escritura por lotes (ACTUALIZAR, ELIMINAR, INSERTAR) de más de 1 millón de filas deben realizarse varias veces en lotes
. Las operaciones por lotes grandes pueden causar retrasos graves entre maestro y esclavo. En un
entorno maestro-esclavo, las operaciones por lotes grandes pueden causar graves Retraso maestro-esclavo, las operaciones de escritura a gran escala generalmente toman mucho tiempo para ejecutarse, y solo cuando se complete la ejecución en la biblioteca maestra, se ejecutará en otras bibliotecas esclavas, por lo que causará una gran demora entre la biblioteca maestra y la biblioteca esclava
. Cuando el registro binlog está en formato de fila, se generará una gran cantidad de registros.
Las operaciones de escritura por lotes grandes generarán una gran cantidad de registros, especialmente para datos binarios en formato de fila. Dado que la modificación de cada fila de datos se registra en el formato de fila, cuantos más datos modifiquemos a la vez , Cuantos más registros se generen, mayor será el tiempo necesario para la transmisión y recuperación de registros, lo que también es una causa de retraso maestro-esclavo.
· Evite operaciones de transacciones grandes. La
modificación de grandes cantidades de datos debe realizarse en una transacción. Esto provocará que se bloqueen grandes cantidades de datos en la tabla, lo que resultará en una gran cantidad de bloqueo. El bloqueo tendrá un impacto muy grande en el rendimiento de MySQL.
En particular, el bloqueo a largo plazo llenará todas las conexiones disponibles a la base de datos, lo que hará que otras aplicaciones en el entorno de producción no puedan conectarse a la base de datos, por lo que debemos prestar atención a las operaciones de escritura por lotes.
2. Use pt-online-schema-change para modificar la estructura
de la tabla para tablas grandes. Evite retrasos maestro-esclavo causados por modificaciones de tablas grandes
. Evite bloquear tablas cuando modifique campos de tablas.
Debe tener cuidado al modificar estructuras de datos de tablas grandes. No se puede tolerar que se produzcan operaciones de bloqueo de mesa graves, especialmente en el entorno de producción.
pt-online-schema-change primero creará una nueva tabla con la misma estructura que la tabla original, y modificará la estructura de la tabla en la nueva tabla, y luego copiará los datos en la tabla original a la nueva tabla y en la tabla original Agrega algunos disparadores.
Copie los datos recién agregados en la tabla original a la nueva tabla. Una vez que se copian todos los datos de la fila, la nueva tabla se denomina tabla original y la tabla original se elimina.
Descomponga la operación DDL original en varios lotes pequeños.
3. Está prohibido otorgar superpermiso a la cuenta utilizada por el programa.
Cuando se alcanza el número máximo de conexiones, un usuario con superpermiso también se está ejecutando para conectarse. El superpermiso solo se puede reservar para la cuenta que el DBA maneja el problema.
4. Para que el programa se conecte a la cuenta de la base de datos, siga el principio de autoridad mínima. La
cuenta de la base de datos utilizada por el programa solo se puede usar en una base de datos, y la cuenta que no puede ser utilizada por programas entre bases de datos no puede tener permisos de eliminación en principio.