Diseño de tabla
- Todas las tablas de MySQL creadas deben usar el motor InnoDB.
- El tipo decimal debe ser DECIMAL. No utilice FLOAT o DOUBLE.
FLOAT y DOUBLE tienen menor precisión que DECIMAL y pueden causar errores de redondeo. Si un valor que se va a almacenar está más allá del rango de DECIMAL, divida el valor en piezas INTEGER y DECIMAL y guárdelas por separado.
- No se pueden usar las siguientes palabras reservadas: DESC, RANGE, MATCH y DELAYED.
Para obtener más información sobre las palabras clave y las palabras reservadas de MySQL Community Edition 8.0, véase Palabras clave y palabras reservadas.
Además de las palabras clave y palabras reservadas de MySQL Community Edition 8.0, se agregan a TaurusDB otras palabras clave y palabras reservadas. No utilice estas palabras clave ni palabras reservadas al asignar nombres a objetos.
Tabla 1 enumera las nuevas palabras clave y palabras reservadas de TaurusDB.Tabla 1 Nuevas palabras clave y palabras reservadas de TaurusDB Palabra reservada
Escenario relacionado
EXTRA_HEALTH
De alta disponibilidad
PBS
Copia de respaldo y restauración
REDO
Replicación primaria/de espera
SLICEID
Almacenamiento compartido
SLOWIO
Almacenamiento compartido
SPACEUSAGE
Almacenamiento compartido
RDS_INSTANT
Papelera de reciclaje
RECYCLE_BIN
Papelera de reciclaje
RDS_RECYCLE
Papelera de reciclaje
RDS_TAC
Papelera de reciclaje
RDS_GDB_CTRL
RegionlessDB
- Cada tabla de datos debe tener una clave principal, que puede ser un campo ordenado y único relacionado con el negocio o un campo de incremento automático no relacionado con el negocio.
- Cada campo de tabla debe tener un valor predeterminado y NOT NULL. Si el campo es el tipo numérico, utilice 0 como valor predeterminado. Si el campo es el tipo de carácter (como VARCHAR), utilice una cadena vacía (").
La ausencia de una clave primaria puede provocar una ejecución lenta de la base de datos primaria y la latencia de la replicación.
- No se recomienda utilizar tablas particionadas. Si es necesario, utilice varias tablas independientes.
Desventajas de las tablas particionadas:
- Todas las particiones se bloquearán durante las operaciones DDL. Como resultado, se bloquearán las operaciones en las particiones.
- Cuando una tabla particionada contiene una gran cantidad de datos, es difícil y arriesgado realizar DDL u otras operaciones de O&M en la tabla.
- Rara vez se utilizan tablas de particiones, lo que puede causar riesgos desconocidos.
- Cuando un solo servidor tiene un rendimiento deficiente, dividir una tabla particionada es costoso.
- Cuando se accede a todas las particiones debido a operaciones incorrectas en una tabla particionada, pueden producirse problemas de rendimiento graves.
- Cada tabla contiene dos campos DATETIME: CREATE_TIME y UPDATE_TIME.
Puede obtener los datos requeridos de un almacén de datos basado en estos dos campos sin necesidad de consultar servicios.
Cuando se produce una excepción en la base de datos, puede utilizar los dos campos para determinar la hora en que se insertan y actualizan los datos. En casos extremos, puede determinar si desea restaurar los datos basándose en los campos.
- VARCHAR es un tipo de datos de carácter de longitud variable. La longitud de VARCHAR no puede superar 2,048.
Si la longitud de un campo es superior a 2,048, defina el tipo de campo como TEXT o cree una tabla independiente y utilice una clave principal para asociar las tablas relacionadas. De esta manera, la eficiencia del índice de otros campos no se ve afectada.
- La longitud de una sola fila de una tabla no puede superar los 1,024 bytes.
- El número máximo de campos en una sola tabla es de 50.
- Si la longitud de todas las cadenas es casi la misma, utilice cadenas de caracteres de longitud fija.
- Con la premisa de garantizar la consistencia de los datos, se permiten campos redundantes entre tablas para evitar las consultas de unión y mejorar el rendimiento de las consultas.
Los campos redundantes deben cumplir con las siguientes reglas:
- Los campos no se modifican con frecuencia.
- Los campos no son grandes VARCHAR y TEXT.
- Los tipos de datos con el tamaño de almacenamiento adecuado pueden ahorrar espacio de almacenamiento de tablas de base de datos e índice, al tiempo que mejoran la velocidad de búsqueda. No se recomiendan LONG TEXT y BLOB.
- Asegúrese de que todos los caracteres estén almacenados y representados en la codificación UTF-8 o utf8mb4. Los comentarios deben ser proporcionados para tablas y campos.
- Evite el uso de grandes transacciones.
Por ejemplo, si se ejecutan varias sentencias SELECT y UPDATE en una transacción de alta frecuencia, la capacidad de concurrencia de la base de datos se ve gravemente afectada porque recursos tales como bloqueos mantenidos por la transacción solo pueden liberarse cuando la transacción se revierte o se confirma. En este caso, también se debe considerar la coherencia de escritura de datos.
- Los índices de texto completo no se recomiendan porque tienen muchas limitaciones.
- Para las tablas ultragrandes, también debe cumplir con las siguientes reglas:
- Utilice TINYINT, SMALLINT y MEDIUM_INT como tipos enteros en lugar de INT. Si un valor no es negativo, agregue UNSIGNED. Mantenga el tipo de campo lo más corto posible y cumpla con los requerimientos de evolución del servicio.
- Configure la longitud VARCHAR según sea necesario.
CREATE TABLE T1 (A VARCHAR(255));
Después de la optimización:
CREATE TABLE T1 (A VARCHAR(Length that meets service requirements));
- Utilice enumeraciones o números enteros en lugar de cadenas.
- Utilice TIMESTAMP en lugar de DATETIME.
- Mantenga el número de campos de una sola tabla por debajo de 20.
- Evite el uso de UNIQUE. Los programas pueden imponer las restricciones.
- Almacenar direcciones IP como enteros.
- Campos de partición con secuencia fuerte y agregar condiciones de rango durante las consultas para mejorar la eficiencia.
- Si es obvio que hay datos calientes y datos fríos, coloque los datos calientes en una partición separada.
- Utilice una instancia proxy para conectarse a una base de datos. En escenarios que no requieren alta consistencia, distribuya las solicitudes de lectura a réplicas de lectura. Si tiene un gran volumen de consultas, agregar réplicas de lectura puede ayudar a acelerarlas.
