Design da tabela
- Todas as tabelas de MySQL criadas devem usar o mecanismo InnoDB.
- O tipo decimal deve ser DECIMAL. Não utilize FLOAT ou DOUBLE.
FLOAT e DOUBLE têm menor precisão do que DECIMAL e podem causar erros de arredondamento. Se um valor a ser armazenado estiver além do intervalo de DECIMAL, divida o valor em partes INTEGER e DECIMAL e armazene-as separadamente.
- As seguintes palavras reservadas não podem ser usadas: DESC, RANGE, MATCH e DELAYED.
Para obter detalhes sobre as palavras-chave e palavras reservadas do MySQL Community Edition 8.0, consulte Palavras-chave e palavras reservadas.
Além das palavras-chave e palavras reservadas do MySQL Community Edition 8.0, algumas outras palavras-chave e palavras reservadas são adicionadas ao TaurusDB. Não use essas palavras-chave e palavras reservadas ao nomear objetos.
Tabela 1 lista as novas palavras-chave e palavras reservadas em TaurusDB.Tabela 1 Novas palavras-chave e palavras reservadas em TaurusDB Palavra reservada
Cenário relacionado
EXTRA_HEALTH
Alta disponibilidade
PBS
Backup e restauração
REDO
Replicação primária/em espera
SLICEID
Armazenamento compartilhado
SLOWIO
Armazenamento compartilhado
SPACEUSAGE
Armazenamento compartilhado
RDS_INSTANT
Lixeira
RECYCLE_BIN
Lixeira
RDS_RECYCLE
Lixeira
RDS_TAC
Lixeira
RDS_GDB_CTRL
RegionlessDB
- Toda tabela de dados deve ter uma chave primária, que pode ser um campo ordenado e exclusivo relacionado a negócios ou um campo de incremento automático não relacionado a negócios.
- Cada campo de tabela deve ter um valor padrão e NOT NULL. Se o campo for do tipo numérico, use 0 como valor padrão. Se o campo for do tipo de caractere (como VARCHAR), use uma cadeia de caracteres vazia (").
A ausência de uma chave primária pode causar lentidão na execução do banco de dados primário e na latência de replicação.
- Não é aconselhável usar tabelas particionadas. Se necessário, use várias tabelas independentes.
Desvantagens das tabelas particionadas:
- Todas as partições serão bloqueadas durante as operações DDL. Como resultado, as operações nas partições serão bloqueadas.
- Quando uma tabela particionada contém uma grande quantidade de dados, é difícil e arriscado executar operações DDL ou outras operações de O&M na tabela.
- Tabelas de partição raramente são usadas, o que pode causar riscos desconhecidos.
- Quando um único servidor tem baixo desempenho, dividir uma tabela particionada é caro.
- Quando todas as partições são acessadas devido a operações impróprias em uma tabela particionada, podem ocorrer graves problemas de desempenho.
- Cada tabela contém dois campos de DATETIME: CREATE_TIME e UPDATE_TIME.
Você pode obter os dados necessários de um data warehouse com base nesses dois campos sem consultar serviços.
Quando ocorre uma exceção no banco de dados, você pode usar os dois campos para determinar a hora em que os dados são inseridos e atualizados. Em casos extremos, você pode determinar se deseja restaurar os dados com base nos campos.
- VARCHAR é um tipo de dado de caractere de comprimento variável. O comprimento do VARCHAR não pode exceder 2.048.
Se o comprimento de um campo exceder 2.048, defina o tipo de campo como TEXT ou crie uma tabela independente e utilize uma chave primária para associar as tabelas relacionadas. Dessa forma, a eficiência do índice de outros campos não é afetada.
- O comprimento de uma única linha em uma tabela não pode exceder 1.024 bytes.
- O número máximo de campos em uma única tabela é 50.
- Se os comprimentos de todas as cadeias forem quase os mesmos, use as cadeias de caracteres de comprimento fixo.
- Com a premissa de garantir a consistência dos dados, os campos redundantes entre tabelas são permitidos para evitar consultas de junção e melhorar o desempenho da consulta.
Os campos redundantes devem estar em conformidade com as seguintes regras:
- Os campos não são modificados com frequência.
- Os campos não são VARCHAR e TEXT grandes.
- Os tipos de dados com tamanho de armazenamento adequado podem economizar espaço de tabela de banco de dados e de armazenamento de índice, ao mesmo tempo que melhoram a velocidade de pesquisa. LONG TEXT e BLOB não são recomendados.
- Certifique-se de que todos os caracteres sejam armazenados e representados na codificação UTF-8 ou utf8mb4. Comentários devem ser fornecidos para tabelas e campos.
- Evite usar grandes transações.
Por exemplo, se várias instruções SELECT e UPDATE forem executadas em uma transação de alta frequência, a capacidade de simultaneidade do banco de dados será severamente afetada porque recursos como bloqueios mantidos pela transação poderão ser liberados somente quando a transação for revertida ou confirmada. Nesse caso, a consistência da gravação de dados também deve ser considerada.
- Índices de texto completo não são recomendados porque há muitas limitações neles.
- Para tabelas ultragrandes, você também precisa cumprir as seguintes regras:
- Use TINYINT, SMALLINT e MEDIUM_INT como tipos inteiros em vez de INT. Se um valor não for negativo, adicione UNSIGNED. Mantenha o tipo de campo o mais curto possível enquanto atende aos requisitos de evolução do serviço.
- Configure o comprimento do VARCHAR conforme necessário.
CREATE TABLE T1 (A VARCHAR(255));
Após a otimização:
CREATE TABLE T1 (A VARCHAR(Comprimento que atenda aos requisitos de serviço));
- Use enumerações ou números inteiros em vez de cadeias de caracteres.
- Use TIMESTAMP em vez de DATETIME.
- Mantenha o número de campos em uma única tabela abaixo de 20.
- Evite usar UNIQUE. Os programas podem impor as restrições.
- Armazene endereços IP como números inteiros.
- Particione campos com sequência forte e adicione condições de intervalo durante as consultas para melhorar a eficiência.
- Se houver dados óbvios quentes e dados frios, coloque os dados quentes em uma partição separada.
- Use uma instância de proxy para se conectar a um banco de dados. Em cenários que não exigem alta consistência, distribua solicitações de leitura para réplicas de leitura. Se você tiver um grande volume de consultas, a adição de réplicas de leitura pode ajudar a acelerá-las.
