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.
Computação
Elastic Cloud Server
Bare Metal Server
Auto Scaling
Image Management Service
Dedicated Host
FunctionGraph
Cloud Phone Host
Huawei Cloud EulerOS
Redes
Virtual Private Cloud
Elastic IP
Elastic Load Balance
NAT Gateway
Direct Connect
Virtual Private Network
VPC Endpoint
Cloud Connect
Enterprise Router
Enterprise Switch
Global Accelerator
Gerenciamento e governança
Cloud Eye
Identity and Access Management
Cloud Trace Service
Resource Formation Service
Tag Management Service
Log Tank Service
Config
Resource Access Manager
Simple Message Notification
Application Performance Management
Application Operations Management
Organizations
Optimization Advisor
Cloud Operations Center
Resource Governance Center
Migração
Server Migration Service
Object Storage Migration Service
Cloud Data Migration
Migration Center
Cloud Ecosystem
KooGallery
Partner Center
User Support
My Account
Billing Center
Cost Center
Resource Center
Enterprise Management
Service Tickets
HUAWEI CLOUD (International) FAQs
ICP Filing
Support Plans
My Credentials
Customer Operation Capabilities
Partner Support Plans
Professional Services
Análises
MapReduce Service
Data Lake Insight
CloudTable Service
Cloud Search Service
Data Lake Visualization
Data Ingestion Service
GaussDB(DWS)
DataArts Studio
IoT
IoT Device Access
Outros
Product Pricing Details
System Permissions
Console Quick Start
Common FAQs
Instructions for Associating with a HUAWEI CLOUD Partner
Message Center
Segurança e conformidade
Security Technologies and Applications
Web Application Firewall
Host Security Service
Cloud Firewall
SecMaster
Anti-DDoS Service
Data Encryption Workshop
Database Security Service
Cloud Bastion Host
Data Security Center
Cloud Certificate Manager
Situation Awareness
Managed Threat Detection
Blockchain
Blockchain Service
Serviços de mídia
Media Processing Center
Video On Demand
Live
SparkRTC
Armazenamento
Object Storage Service
Elastic Volume Service
Cloud Backup and Recovery
Cloud Server Backup Service
Storage Disaster Recovery Service
Scalable File Service
Volume Backup Service
Data Express Service
Dedicated Distributed Storage Service
Containers
Cloud Container Engine
SoftWare Repository for Container
Application Service Mesh
Ubiquitous Cloud Native Service
Cloud Container Instance
Bancos de dados
Relational Database Service
Document Database Service
Data Admin Service
Data Replication Service
GeminiDB
GaussDB
Distributed Database Middleware
Database and Application Migration UGO
TaurusDB
Middleware
Distributed Cache Service
API Gateway
Distributed Message Service for Kafka
Distributed Message Service for RabbitMQ
Distributed Message Service for RocketMQ
Cloud Service Engine
EventGrid
Dedicated Cloud
Dedicated Computing Cluster
Aplicações de negócios
ROMA Connect
Message & SMS
Domain Name Service
Edge Data Center Management
Meeting
AI
Face Recognition Service
Graph Engine Service
Content Moderation
Image Recognition
Data Lake Factory
Optical Character Recognition
ModelArts
ImageSearch
Conversational Bot Service
Speech Interaction Service
Huawei HiLens
Developer Tools
SDK Developer Guide
API Request Signing Guide
Terraform
Koo Command Line Interface
Distribuição de conteúdo e computação de borda
Content Delivery Network
Intelligent EdgeFabric
CloudPond
Soluções
SAP Cloud
High Performance Computing
Serviços para desenvolvedore
ServiceStage
CodeArts
CodeArts PerfTest
CodeArts Req
CodeArts Pipeline
CodeArts Build
CodeArts Deploy
CodeArts Artifact
CodeArts TestPlan
CodeArts Check
Cloud Application Engine
MacroVerse aPaaS
KooPhone
KooDrive

Sugestões sobre o uso do RDS for MySQL

Atualizado em 2024-09-24 GMT+08:00

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.

Usamos cookies para aprimorar nosso site e sua experiência. Ao continuar a navegar em nosso site, você aceita nossa política de cookies. Saiba mais

Feedback

Feedback

Feedback

0/500

Conteúdo selecionado

Envie o conteúdo selecionado com o feedback