Este conteúdo foi traduzido por máquina para sua conveniência e a Huawei Cloud não pode garantir que o conteúdo foi traduzido com precisão. Para exibir o conteúdo original, use o link no canto superior direito para mudar para a página em inglês.
Central de ajuda/ Relational Database Service/ Melhores práticas/ RDS for MySQL/ Sugestões sobre o uso do RDS for MySQL
Atualizado em 2024-09-24 GMT+08:00
Ver PDF
Compartilhar

Sugestões sobre o uso do RDS for MySQL

Nomeação de banco de dados

  • Os nomes dos objetos de banco de dados, como bancos de dados, tabelas e colunas, devem estar em letras minúsculas. Palavras diferentes no nome são separadas com sublinhados (_).
  • Palavras e palavras-chave reservadas não podem ser usadas para nomear objetos de banco de dados no RDS for MySQL.
  • Cada nome de objeto de banco de dados deve ser explicável e conter no máximo 32 caracteres.
  • Cada tabela temporária em bancos de dados é prefixada com tmp e sufixada com uma data.
  • Cada tabela de backup nos bancos de dados é prefixada com bak e sufixada com uma data.
  • Todas as colunas que armazenam os mesmos dados em diferentes bancos de dados ou tabelas devem ter o mesmo nome e ser do mesmo tipo.

Design de banco de dados

  • Todas as tabelas usam o mecanismo de armazenamento InnoDB, a menos que especificado de outra forma. O InnoDB suporta transações e bloqueios de linha. Ele oferece excelente desempenho, facilitando a recuperação de dados.
  • Todos os bancos de dados e tabelas usam o conjunto de caracteres UTF8 para evitar que os caracteres sejam ilegíveis pela conversão do conjunto de caracteres.
  • Todas as tabelas e campos exigem comentários que podem ser adicionados usando a cláusula COMMENT para manter o dicionário de dados desde o início do design.
  • O comprimento de uma única linha na tabela não pode exceder 1024 bytes.
  • Para evitar consultas de partição cruzada, as tabelas particionadas do RDS for MySQL não são recomendadas. As consultas de partição cruzada diminuirão a eficiência da consulta. Uma tabela particionada é logicamente uma única tabela, mas os dados são armazenados em vários arquivos diferentes.
  • Não crie muitas colunas em uma tabela. Armazene dados frios e quentes separadamente para reduzir a largura de uma tabela. Ao fazer isso, mais linhas de dados podem ser armazenadas em cada página de memória, diminuindo a I/O do disco e fazendo um uso mais eficiente do cache.
  • As colunas que são frequentemente usadas juntas devem estar na mesma tabela para evitar operações JOIN.
  • Não crie campos reservados em uma tabela. Caso contrário, modificar o tipo de coluna bloqueará a tabela, o que causa um impacto maior do que adicionar um campo.
  • Não armazene dados binários, como imagens e arquivos, em bancos de dados.
  • Os índices de texto completo não são recomendados porque há muitas limitações nos índices de texto completo para o MySQL Community Edition.

Design de campo

  • Verifique se cada tabela contém no máximo 50 campos.
  • Selecione um tipo de dados pequeno para cada coluna, tanto quanto possível. Os dados numéricos são preferidos, seguidos por datas ou dados binários, e os menos preferidos são caracteres. Quanto maior o tipo de dados da coluna, maior o espaço necessário para criar índices. Como resultado, há menos índices em uma página e mais operações de I/O necessárias, de modo que o desempenho do banco de dados se deteriora.
  • Se o tipo inteiro for usado como o tipo de campo do banco de dados, selecione o tipo de coluna mais curto. Se o valor for um número não negativo, ele deve ser do tipo não assinado.
  • Cada campo deve ter o atributo NOT NULL. O valor padrão para o tipo numérico como INT é recomendado ser 0, e que para o tipo de caractere como VARCHAR é recomendado para ser uma cadeia de caracteres vazia.
  • Não use o tipo ENUM. Em vez disso, use o tipo TINYINT.

    Altere os valores ENUM usando ALTER. As operações ORDER BY em valores ENUM são ineficientes e exigem operações extras.

    Se você especificou que os valores ENUM não podem ser numéricos, outros tipos de dados (como char) podem ser usados.

  • Se o tipo de dados numérico for necessário, use DECIMAL em vez de FLOAT ou DOUBLE.

    Os dados FLOAT e DOUBLE não podem ser armazenados com precisão, e os resultados da comparação de valores podem estar incorretos.

  • Quando você quiser registrar uma data ou hora específica, use o tipo DATETIME ou TIMESTAMP em vez do tipo de sequência.
  • Armazene endereços IP usando o tipo INT UNSIGNED. Você pode converter endereços IP em dados numéricos usando a função inet_aton ou inet_ntoa.
  • Os dados VARCHAR devem ser tão curtos quanto possível. Embora os dados VARCHAR variem de comprimento dinamicamente em discos, eles ocupam o comprimento máximo na memória.
  • Use VARBINARY para armazenar cadeias de caracteres de comprimento variável que diferenciam maiúsculas de minúsculas. VARBINARY diferencia maiúsculas de minúsculas por padrão e é rápido de processar porque nenhum conjunto de caracteres está envolvido.

Design de índice

  • Crie uma chave primária para cada tabela InnoDB. Não use uma coluna atualizada com frequência como chave primária nem uma chave primária de várias colunas. Não use a coluna UUID, MD5 ou cadeia de caracteres como chave primária. Use uma coluna cujos valores podem ser incrementados continuamente como a chave primária. Portanto, a coluna de ID com incremento automático é recomendada.
  • Não use mais de 5 índices em uma única tabela. Os índices aceleram as consultas, mas muitos índices podem tornar as gravações mais lentas. Índices inadequados às vezes reduzem a eficiência da consulta.
  • Não crie um índice independente para cada coluna em uma tabela. Um índice composto bem projetado é muito mais eficiente do que um índice separado em cada coluna.
  • Crie um índice nas seguintes colunas:
    • Colunas especificadas na cláusula WHERE das instruções SELECT, UPDATE ou DELETE
    • Colunas especificadas em ORDER BY, GROUP BY ou DISTINCT
    • Colunas associadas para unir várias tabelas.
  • A ordem das colunas do índice é a seguinte:
    • Coloque a coluna com a maior seletividade na extremidade esquerda ao criar um índice composto. Seletividade = valores diferentes em uma coluna/total de linhas na coluna
    • Coloque a coluna com o menor comprimento de campo na extremidade esquerda do índice composto. Quanto menor o comprimento de um campo, mais dados uma página armazena e melhor é o desempenho de I/O.
    • Coloque a coluna usada com mais frequência à esquerda do índice composto, para que você possa criar menos índices.
  • Evite usar índices redundantes, como chave primária (id), índice (id) e índice exclusivo (id).
  • Evite usar índices duplicados, como index(a,b,c), index(a,b) e index(a). Índices duplicados e redundantes podem tornar as consultas lentas porque o otimizador de consulta do RDS for MySQL não sabe qual índice ele deve usar.
  • Ao criar um índice no campo VARCHAR, especifique o comprimento do índice com base na seletividade. Não indexe o campo inteiro.

    Se um índice com o comprimento de 20 bytes for do tipo string, sua seletividade poderá atingir 90% ou mais. Nesse caso, use count(distinct left(column name, index length))/count(*) para verificar a seletividade do índice.

  • Use índices de cobertura para consultas frequentes.

    Um índice de cobertura é um tipo especial de índice em que todos os campos obrigatórios para uma consulta são incluídos no índice. O próprio índice contém colunas especificadas nas cláusulas WHERE e GROUP BY, mas também combinações de colunas consultadas em SELECT, sem a necessidade de executar consultas adicionais.

  • As restrições em chaves estrangeiras são as seguintes:

    Os conjuntos de caracteres das colunas para as quais uma relação de chave estrangeira é estabelecida devem ser os mesmos, ou os conjuntos de caracteres das tabelas pai e filho para as quais uma relação de chave estrangeira é estabelecida devem ser os mesmos.

Desenvolvimento da instrução SQL

  • Use instruções preparadas para executar operações de banco de dados em programas. As instruções preparadas podem ser executadas várias vezes em um programa depois que são escritas, mais eficientes do que as instruções SQL.
  • Evite conversões implícitas porque elas podem fazer com que o índice se torne inválido.

    Não realize conversões de função ou cálculos matemáticos em colunas na cláusula WHERE. Caso contrário, o índice se torna inválido.

  • Não use sinais de porcentagem dupla (%%) ou coloque% antes de uma condição de consulta, ou o índice não pode ser usado.
  • Não use select * para consultas porque usar select *:
    • Consome mais CPUs, endereços IP e largura de banda.
    • Faz com que os índices de cobertura fiquem indisponíveis.
    • Aumenta o impacto das alterações na estrutura da tabela no código.
  • Não use subconsultas. As subconsultas geram tabelas temporárias que não têm índices. Se houver muitos dados, a eficiência da consulta será severamente afetada. Converta subconsultas em consultas associadas.
  • Minimize o uso de operações JOIN para mais de 5 tabelas. Use o mesmo tipo de dados para os campos que exigem operações JOIN.

    Cada operação JOIN em uma tabela ocupa memória extra (controlada por join_buffer_size) e requer operações temporárias de tabela, afetando a eficiência da consulta. Não use NATURAL JOIN.

  • Reduza ao máximo as interações com o mesmo banco de dados. O banco de dados é mais adequado para processar operações em lote.
  • Substitua as operações OR por operações IN. As operações IN podem usar índices com eficiência. O número de valores IN não pode exceder 500.
  • Não execute consultas reversas, por exemplo, NOT IN e NOT LIKE.
  • Não use ORDER BY RAND() para classificação aleatória.

    Esta operação carrega todos os dados que atendem às condições da tabela para a memória para classificação, consumindo mais recursos de CPU, I/O e memória.

    Obtenha um valor aleatório do programa e recupere dados do banco de dados envolvido com base no valor.

  • Se a deduplicação não for necessária, use UNION ALL em vez de UNION.

    UNION ALL não classifica conjuntos de resultados.

  • Combine várias operações e as execute em lotes. O banco de dados é bom para processamento em lote.

    Isso reduz as interações com o mesmo banco de dados.

  • Se houver mais de 1 milhão de linhas de operações de gravação, execute-as em vários lotes.

    Um grande número de gravações em lote pode resultar em latência primária/em espera excessiva.

  • Se ORDER BY for usado, use a ordem dos índices.
    • O último campo de ORDER BY faz parte de um índice composto e é colocado no final da ordem do índice composto.
    • Evite file_sort para acelerar as consultas.

    Exemplo correto: em que where a=? and b=? order by c;, índice: a_b_c

    Exemplo incorreto: se um índice suportar a pesquisa de intervalo, a ordem do índice não poderá ser usada. Por exemplo, WHERE a>10 ORDER BY b;, índice: a_b (ordenação não é permitida)

  • Use instruções SQL padrão ANSI em vez de instruções SQL estendidas do MySQL para operações DML. As instruções SQL estendidas comuns do MySQL incluem:
    • REPLACE INTO
    • INSERT ... ON DUPLICATE KEY UPDATE
  • Os procedimentos armazenados não são recomendados porque são difíceis de depurar, estender e transplantar.
  • Para evitar dependência lógica no banco de dados, não use gatilhos, agendadores de eventos ou exibições para lógica de serviço.
  • Transações grandes não são recomendadas. Se possível, uma transação não deve conter mais do que cinco instruções SQL porque grandes transações têm problemas como longo tempo de bloqueio de dados, muitos caches e consumo de conexão.
  • TRUNCATE TABLE é mais rápido que DELETE e usa menos recursos de sistema e log. Se a tabela a ser excluída não tiver um gatilho e toda a tabela precisar ser excluída, TRUNCATE TABLE é recomendado.
  • Não execute o comando flush logs com frequência para evitar falhas de exclusão automática do binlog.
Tópico principal: RDS for MySQL