PolarDB:Perguntas frequentes

P: O que é o PolarDB?

R: O PolarDB é um service de banco de dados relacional em cloud implantado em data centers em mais de 10 regiões no mundo todo, oferecendo uma experiência pronta para uso. O PolarDB suporta três engines independentes: 100% compatível com MySQL, 100% compatível com PostgreSQL e altamente compatível com a sintaxe Oracle. Ele oferece capacidade de armazenamento de até 200 TB. Para obter mais informações, consulte O que é o PolarDB for MySQL Enterprise Edition?, ou .

P: Por que o PolarDB é uma escolha melhor do que bancos de dados tradicionais?

R: Em comparação com bancos de dados tradicionais, o PolarDB armazena centenas de terabytes de dados e fornece recursos como alta disponibilidade, alta confiabilidade, dimensionamento elástico rápido e backups sem bloqueio. Para obter mais informações, consulte Benefícios, ou .

P: Quando o PolarDB foi lançado e quando se tornou comercialmente disponível?

R: O PolarDB foi lançado para visualização pública em setembro de 2017 e tornou-se comercialmente disponível em março de 2018.

P: O que são clusters e nós?

R: O PolarDB Cluster Edition utiliza uma arquitetura de múltiplos nós. Um cluster contém um nó primário e vários nós somente leitura. Um único cluster PolarDB pode ser implantado em várias zonas, mas não em várias regiões. O gerenciamento e o faturamento do service ocorrem no nível do cluster. Para obter mais informações, consulte Termos, ou .

P: Quais linguagens de programação são suportadas?

R: O PolarDB suporta diversas linguagens de programação, incluindo Java, Python, PHP, Go, C, C++, .NET e Node.js. Qualquer linguagem de programação que suporte MySQL nativo funciona com o PolarDB for MySQL. Para obter mais informações, visite o site oficial do MySQL.

P: Quais engines de armazenamento são suportadas?

P: O PolarDB é um banco de dados distribuído?

R: Sim. O PolarDB é um cluster de armazenamento distribuído baseado no protocolo de consenso Parallel Raft. Sua engine de computação consiste em 1 a 16 nós de computação distribuídos em diferentes servidores. O cluster fornece capacidade máxima de armazenamento de 200 TB e suporta até 88 núcleos de CPU e 710 GB de memória. É possível dimensionar dinamicamente os recursos de armazenamento e computação online sem afetar suas cargas de trabalho.

P: Após comprar um cluster PolarDB, também preciso adquirir o middleware de banco de dados PolarDB-X para implementar sharding?

R: Sim.

P: O PolarDB suporta particionamento de tabelas?

R: Sim.

P: Posso alterar a região de um cluster PolarDB após a compra?

R: Não, não é possível alterar a região de um cluster após a compra.

P: O PolarDB inclui automaticamente um mecanismo de particionamento?

R: Sim. O PolarDB realiza o particionamento na camada de armazenamento, o que é transparente para os usuários.

P: Como um cluster de nó único garante a disponibilidade do service e a confiabilidade dos dados?

R: Um cluster de nó único executa em um único nó de computação para finalidades específicas. Embora possua apenas um nó, o cluster de nó único aproveita tecnologias como agendamento instantâneo de computação e armazenamento distribuído de múltiplas réplicas para garantir alta disponibilidade do service e confiabilidade dos dados.

P: Como compro um cluster PolarDB de nó único?

R: A série de produtos de nó único não está mais disponível. No entanto, é possível criar um cluster que funcione como um cluster de nó único definindo o número de nós somente leitura como 0 ao comprar um cluster PolarDB.

P: O PolarDB é compatível com o MySQL Community Edition?

R: O PolarDB for MySQL é 100% compatível com o MySQL Community Edition.

P: Quais níveis de isolamento de transação são suportados?

R: O PolarDB for MySQL suporta os níveis de isolamento READ-UNCOMMITTED, READ-COMMITTED (padrão) e REPEATABLE-READ. O nível de isolamento SERIALIZABLE não é suportado.

P: A saída do SHOW PROCESSLIST é diferente da do MySQL Community Edition?

A: Se você se conectar ao cluster usando o endpoint primário, a saída será a mesma. Caso utilize o endpoint do cluster, a saída será ligeiramente diferente. Você encontrará vários registros com o mesmo ID de thread, cada um correspondendo a um nó no cluster PolarDB for MySQL.

P: O mecanismo de bloqueio de metadados (MDL) no PolarDB for MySQL é diferente do MySQL Community Edition?

R: Não, o mecanismo MDL no PolarDB for MySQL é igual ao do MySQL Community Edition. Contudo, como os nós do PolarDB for MySQL usam uma arquitetura de armazenamento compartilhado, ao realizar uma operação DDL no nó primário, os nós somente leitura podem ler dados intermediários da operação DDL, levando à inconsistência de dados. Para evitar isso, o PolarDB for MySQL sincroniza os MDLs exclusivos envolvidos na operação DDL com os nós somente leitura usando redo logs. Isso impede que outros threads de usuário nos nós somente leitura acessem a tabela durante a operação DDL. Em alguns casos, isso pode paralisar a operação DDL. Execute o comando SHOW PROCESSLIST para visualizar o status de execução da operação DDL. Se o status for Wait for syncing with replicas, indica que ocorreu uma paralisação. Para obter mais informações sobre como resolver esse problema, consulte Visualizar o status de execução da instrução DDL e o status do MDL.

P: O formato do binlog é diferente do formato nativo do MySQL?

R: Não, não há diferença.

P: Os schemas performance e sys são suportados?

R: Sim.

P: O mecanismo de coleta de estatísticas de tabela é diferente do MySQL Community Edition?

R: As estatísticas de tabela no nó primário de um cluster PolarDB for MySQL são consistentes com as do MySQL Community Edition. Para garantir planos de execução consistentes entre o nó primário e os nós somente leitura, cada atualização de estatística no nó primário é sincronizada com os nós somente leitura. Além disso, execute o comando ANALYZE TABLE nos nós somente leitura para carregar proativamente as estatísticas mais recentes do disco.

P: O PolarDB suporta transações XA? Há diferença em relação à implementação oficial do MySQL?

R: Sim, o PolarDB suporta transações XA e não há diferença em relação à implementação oficial do MySQL.

P: O PolarDB suporta pesquisa de texto completo?

P: O Percona Toolkit é suportado?

R: Sim, mas recomendamos o uso de DDL online.

P: O gh-ost é suportado?

R: Sim, mas recomendamos o uso de DDL online.

P: Quais são os itens faturáveis de um cluster PolarDB?

R: Os itens faturáveis incluem espaço de armazenamento, nós de computação, backups (com cota gratuita) e SQL Explorer (opcional). Para obter mais informações, consulte Itens faturáveis, ou .

P: O que o espaço de armazenamento cobrado inclui?

R: O espaço de armazenamento cobrado inclui arquivos de tabelas de banco de dados, arquivos de índice, arquivos de undo log, arquivos de redo log, arquivos de binlog, arquivos de slow log e uma pequena quantidade de arquivos de sistema. Para obter mais informações, consulte Visão geral, ou .

P: Como sou cobrado se adicionar um nó somente leitura?

R: O preço de um nó somente leitura é igual ao de um nó primário. Para obter mais informações, consulte Detalhes de preços de nós de computação, ou .

P: Se eu adicionar um nó somente leitura, a capacidade de armazenamento dobra?

R: Não. O PolarDB utiliza uma arquitetura que desacopla computação e armazenamento. Ao comprar um nó somente leitura, você adiciona um recurso de computação, o que não aumenta a capacidade de armazenamento.

O espaço de armazenamento é serverless, portanto, não é necessário selecionar uma capacidade no momento da compra. Ele escala automaticamente conforme seus dados crescem, e você paga apenas pela quantidade de dados utilizada. Cada especificação de cluster possui uma capacidade máxima de armazenamento. Para aumentar o limite de armazenamento, atualize as especificações do cluster, ou .

P: Como paro de incorrer em cobranças para um cluster de pagamento conforme o uso?

R: Caso não precise mais do cluster, libere-o. Liberar o cluster interrompe todas as cobranças futuras.

P: Posso alterar as especificações de um cluster durante uma atualização temporária?

R: Durante uma atualização temporária, enquanto o status do cluster for Running, é possível atualizar manualmente as especificações. No entanto, não é possível fazer downgrade manual, ativar o dimensionamento automático ou adicionar ou remover nós.

P: Qual é a largura de banda pública do PolarDB e existem custos associados?

R: O próprio PolarDB não possui limite de largura de banda pública. A largura de banda depende principalmente do service Server Load Balancer (SLB) utilizado. O PolarDB não cobra por conexões públicas.

P: Por que ainda vejo cobranças diárias para um cluster por assinatura?

R: Os itens faturáveis do PolarDB incluem nós de computação (nós primários e somente leitura), espaço de armazenamento, backups de dados (cobrados apenas quando a cota gratuita é excedida), SQL Explorer (opcional) e Global Database Network (GDN) (opcional). Para obter mais informações, consulte Itens faturáveis. O método de faturamento por assinatura exige pré-pagamento pelos nós de computação ao criar um cluster, mas não cobre os custos de espaço de armazenamento, backups de dados e SQL Explorer. As taxas desses itens de pagamento conforme o uso são deduzidas da sua conta por hora. Portanto, mesmo com uma assinatura, você ainda receberá faturas de pagamento conforme o uso.

P: Existem cobranças extras para migração com um clique do ApsaraDB RDS for MySQL para o PolarDB?

R: O processo de migração com um clique é gratuito. Você paga apenas pela instância ApsaraDB RDS for MySQL e pelo próprio cluster PolarDB.

P: Por que ainda sou cobrado pelo espaço de armazenamento após excluir dados de uma tabela PolarDB usando o comando DELETE?

R: O comando DELETE apenas marca linhas para exclusão. Ele não libera o espaço da tabela.

P: Como implemento a divisão de leitura/escrita no PolarDB?

R: Basta usar o endpoint do cluster em sua aplicação. A divisão de leitura/escrita é então implementada com base no modo de leitura/escrita configurado. Para obter mais informações, consulte Configurar o proxy de banco de dados, ou .

P: Qual é o número máximo de nós somente leitura suportados em um cluster PolarDB?

R: O PolarDB utiliza uma arquitetura de cluster distribuído. Um cluster contém um nó primário e até 15 nós somente leitura. Pelo menos um nó somente leitura é necessário para garantir alta disponibilidade.

P: Por que as cargas de trabalho estão desequilibradas entre vários nós somente leitura?

R: O desequilíbrio de carga entre nós somente leitura pode ser causado por um baixo número de conexões aos nós ou por um endpoint de cluster personalizado que não inclua todos os nós somente leitura em sua configuração.

P: O que causa carga alta ou baixa no nó primário?

R: Uma carga alta no nó primário pode resultar de vários fatores: conexões diretas ao endpoint primário, o nó primário aceitando solicitações de leitura, grande volume de solicitações de transação, alta latência de replicação fazendo com que solicitações sejam roteadas para o nó primário, ou falha em um nó somente leitura desviando solicitações de leitura para o nó primário.

Uma carga baixa no nó primário pode ocorrer se a opção de aceitar solicitações de leitura no nó primário estiver desativada.

P: Como reduzo a carga no nó primário?

P: Por que não consigo ler dados imediatamente após a inserção?

P: Como forço a execução de uma instrução SQL no nó primário?

P: Posso atribuir endpoints diferentes para services diferentes? Esses endpoints fornecem isolamento entre os services?

R: Sim, crie múltiplos endpoints personalizados para services diferentes. Se esses endpoints utilizarem nós subjacentes distintos, eles fornecerão isolamento e não se afetarão mutuamente. Para obter informações sobre como criar um endpoint personalizado, consulte Criar um endpoint de cluster personalizado, ou .

P: Se eu tiver vários nós somente leitura, como crio um endpoint dedicado de nó único para um deles?

P: Qual é o número máximo de endpoints de nó único que posso criar em um cluster?

R: Se seu cluster tiver três nós, crie um endpoint de nó único para apenas um nó somente leitura. Caso tenha quatro nós, crie endpoints de nó único separados para dois dos nós somente leitura. Esse padrão continua conforme o número de nós aumenta.

P: Estou usando apenas o endpoint primário, mas vejo carga nos nós somente leitura. O endpoint primário também suporta divisão de leitura/escrita?

R: Não, o endpoint primário não suporta divisão de leitura/escrita. Ele sempre se conecta apenas ao nó primário. Uma pequena quantidade de QPS nos nós somente leitura é normal e não está relacionada ao endpoint primário.

P: Como adiciono campos e índices online?

R: Utilize DDL online nativo ou ferramentas como pt-online-schema-change e gh-ost. Recomendamos o uso de operações DDL online nativas.

P: O recurso de bulk insert é suportado?

R: Sim.

P: O bulk insert é suportado se eu gravar dados apenas no nó primário? Qual é o número máximo de valores que posso inserir por vez?

R: Sim, é suportado. O número máximo de valores que podem ser inseridos por vez é determinado pelo valor do parâmetro max_allowed_packet. Para obter mais informações, consulte Replicação e max_allowed_packet.

P: Posso realizar uma operação de bulk insert através do endpoint do cluster?

R: Sim.

P: Existe atraso de replicação entre o nó primário e os nós somente leitura?

R: Sim, existe um atraso na ordem de milissegundos entre eles.

P: O que pode causar aumento no atraso de replicação?

P: Se houver atraso de replicação, como garanto a consistência das consultas?

R: Utilize um endpoint de cluster e selecione um nível de consistência apropriado para ele. Os níveis de consistência disponíveis, do maior para o menor, são consistência global (consistência forte), consistência de sessão e consistência eventual. Para obter mais informações, consulte Níveis de consistência, ou .

P: Um objetivo de ponto de recuperação (RPO) de 0 pode ser garantido em caso de falha de um único nó?

R: Sim.

P: Como as atualizações de especificação (por exemplo, de 2 núcleos e 8 GB de memória para 4 núcleos e 16 GB) são implementadas no backend? Qual é o impacto nos services?

R: O PolarDB realiza uma atualização contínua tanto no proxy quanto nos nós de banco de dados para minimizar o impacto no service. Uma atualização geralmente leva de 10 a 15 minutos para ser concluída, com impacto no service de no máximo 30 segundos. Durante esse período, podem ocorrer de um a três erros transitórios de conexão. Para obter mais informações, consulte Dimensionamento manual, ou .

P: Quanto tempo leva para adicionar um nó? Isso afeta meus services?

P: Quanto tempo leva para atualizar para a versão de revisão mais recente? Isso afeta meus services?

R: O PolarDB utiliza um método de atualização contínua em vários nós para minimizar o impacto em seus services. Uma atualização de versão geralmente leva menos de 30 minutos. Durante a atualização, o proxy de banco de dados ou a engine do kernel do DB é reiniciado, o que pode causar erros transitórios de conexão. Recomendamos realizar a atualização fora dos horários de pico e garantir que sua aplicação possua um mecanismo de reconexão automática. Para obter mais informações, consulte Gerenciamento de versões menores, ou .

P: Como funciona o failover automático?

R: O PolarDB utiliza uma arquitetura de cluster de alta disponibilidade Active-Active. O failover automático ocorre entre o nó primário de leitura/escrita e os nós somente leitura. O sistema elege automaticamente um novo nó primário. Cada nó em um cluster PolarDB possui uma prioridade de failover, que determina sua probabilidade de ser eleito como o novo nó primário durante um failover. Se vários nós tiverem a mesma prioridade, terão a mesma probabilidade de serem eleitos. Para obter mais informações, consulte Alternância automática e manual de nó primário/secundário, ou .

P: Quais permissões são necessárias para encerrar uma conexão em um cluster PolarDB for MySQL?

R: No MySQL, são necessárias permissões específicas para encerrar uma conexão usando o comando KILL. Especificamente, para encerrar a conexão de outro usuário comum, você deve ter a permissão PROCESS.

P: Meu log de execução mostra um erro [ERROR] InnoDB: fil_space_extend space_name:xxx. Isso afeta meus services atuais?

R: Não, isso não afeta seus services. Essa entrada de log indica que, após a extensão do tamanho do arquivo no nó de leitura/escrita do cluster PolarDB, o nó somente leitura sincroniza as informações de tamanho do arquivo em sua memória. Em clusters que executam MySQL 5,7, o nível de log para esta mensagem não é ajustado e permanece como ERROR. Nos nós somente leitura, considere isso como uma mensagem de nível INFO. Não afeta seus services.

P: Qual é a arquitetura do proxy de banco de dados? Ele possui mecanismo de failover? Como sua alta disponibilidade é garantida?

R: O proxy de banco de dados utiliza uma arquitetura de alta disponibilidade de dois nós, distribuindo o tráfego uniformemente entre eles. O sistema verifica continuamente o status de integridade dos nós de proxy. Se detectar falha em um nó, o sistema desconecta proativamente as conexões nesse nó, e o nó saudável restante assume automaticamente todo o tráfego para garantir service ininterrupto. Simultaneamente, o sistema reconstrói e restaura automaticamente o nó de proxy com falha. Esse processo é tipicamente concluído em cerca de 2 minutos. Durante esse tempo, o cluster de banco de dados permanece acessível.

Em casos raros, conexões a um nó com falha podem não ser desconectadas em tempo hábil e tornarem-se irresponsivas. Para lidar com tais situações, configure políticas de timeout apropriadas no lado do cliente, como socketTimeout e connectTimeout do JDBC. Isso permite que a camada de aplicação detecte e encerre prontamente conexões suspensas, melhorando ainda mais a tolerância a falhas e a eficiência de resposta do sistema.

P: Como visualizo os logs de erro de um cluster PolarDB for MySQL?

R: Acesse o console do PolarDB. Na página de detalhes do cluster, navegue até Diagnostics and Optimization > Log Management no painel de navegação à esquerda. Na aba Running Logs, visualize os logs de erro.

P: O PolarDB for MySQL cria automaticamente uma chave primária oculta para uma tabela sem chave primária?

R: Sim. Por padrão, o PolarDB for MySQL cria uma chave primária implícita para qualquer tabela sem chave primária.

Visualizar a chave primária implícita

Faça logon no cluster e execute SET show_ipk_info = 1. Em seguida, visualize a chave executando o comando SHOW CREATE TABLE.

-- Set the parameter to display the implicit primary key.
SET show_ipk_info = 1;
-- View the table schema.
SHOW CREATE TABLE t;

Visualize o schema da tabela. A coluna __#alibaba_rds_row_id#__ é a chave primária implícita.

+-------+------------------------------------------------------------------------------------------------------------+
| Table | Create Table                                                                                               |
+-------+------------------------------------------------------------------------------------------------------------+
| t     | CREATE TABLE `t` (
  `id` int(11) DEFAULT NULL,
  `__#alibaba_rds_row_id#__` bigint(20) NOT NULL AUTO_INCREMENT COMMENT 'Implicit Primary Key by RDS',
  KEY `__#alibaba_rds_row_id#__` (`__#alibaba_rds_row_id#__`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 |
+-------+------------------------------------------------------------------------------------------------------------+

P: Por que vejo um erro Lock wait timeout exceeded e encontro uma transação com trx_mysql_thread_id igual a 0?

MySQL xxx > select * from information_schema.innodb_trx\G
*************************** 1. row ***************************
                    trx_id: 3317965
                 trx_state: RUNNING
               trx_started: 2025-12-23 11:29:17
      trx_requested_lock_id: NULL
          trx_wait_started: NULL
                trx_weight: 3
       trx_mysql_thread_id: 0
                 trx_query: NULL

Por que diferentes clusters PolarDB for MySQL 8.0 apresentam comportamento inconsistente de tratamento de erros ao comparar tipos inválidos de data e hora?

• Descrição do problema: Clusters PolarDB for MySQL 8.0 estão disponíveis em duas versões, MySQL 8.0.1 e MySQL 8.0.2, totalmente compatíveis com MySQL 8.0.13 e MySQL 8.0.18, respectivamente. No entanto, essas duas versões tratam tipos inválidos de data e hora de forma inconsistente.

  Especificamente, quando um literal de string é comparado com um valor de tipo temporal, tenta-se converter a string para um tipo temporal. Se a string for uma data inválida, a conversão falha. O comportamento diante da falha de conversão difere entre as duas versões. A versão compatível com 8.0.13 emite apenas um WARNING, enquanto a versão compatível com 8.0.18 retorna um erro ER_WRONG_VALUE. Como resultado, ao comparar datas inválidas e campos de tempo, essas duas versões de clusters PolarDB for MySQL exibem comportamento inconsistente de relatório de erros.

• Solução: Para garantir resultados consistentes de execução SQL (todos com sucesso ou todos com falha), múltiplos clusters PolarDB for MySQL devem usar a mesma versão principal do kernel, seja todos MySQL 8.0.1 ou todos MySQL 8.0.2.

P: Como o PolarDB faz backup de dados?

R: O PolarDB utiliza snapshots para fazer backup de dados. Para obter mais informações, consulte Método de backup 1: Backup automático e Método de backup 2: Backup manual, ou .

P: Qual é a velocidade de restauração de um banco de dados?

R: Restaurar um banco de dados a partir de um conjunto de backups (snapshot) ou clonar um banco de dados leva cerca de 40 minutos por TB. Se você restaurar dados para um ponto específico no tempo, o tempo necessário para aplicar redo logs também é incluído. Aplicar redo logs leva cerca de 20 a 70 segundos por GB. O tempo total de restauração é a soma dessas duas partes.

P: Por que o desempenho do PolarDB for MySQL não é significativamente superior ao do ApsaraDB RDS for MySQL?

Para uma comparação de desempenho entre PolarDB for MySQL e ApsaraDB RDS for MySQL, consulte Comparação de desempenho: PolarDB for MySQL vs. ApsaraDB RDS for MySQL.

P: Qual é o número máximo de tabelas? Em que ponto o desempenho pode degradar?

R: O número máximo de tabelas é limitado pelo número de arquivos. Para obter mais informações, consulte Limites, ou .

P: O particionamento de tabelas pode melhorar o desempenho de consulta do PolarDB?

R: Geralmente, sim. Se uma consulta puder ser restrita a uma partição específica, o desempenho poderá ser melhorado.

P: Posso criar 10.000 bancos de dados em um cluster PolarDB? Qual é o número máximo de bancos de dados?

R: Sim, crie 10.000 bancos de dados em um cluster PolarDB. O número máximo de bancos de dados é limitado pelo número de arquivos. Para obter mais informações, consulte Limites, ou .

P: O número máximo de conexões está relacionado ao número de nós somente leitura? Posso aumentar o número máximo de conexões adicionando nós somente leitura?

R: Não, o número de nós somente leitura não está relacionado ao número máximo de conexões. O número máximo de conexões no PolarDB é determinado pelas especificações do nó. Para obter mais informações, consulte Limites. Se precisar de mais conexões, atualize as especificações.

P: Como os IOPS são limitados e isolados? Pode ocorrer contenção de I/O entre múltiplos nós de cluster PolarDB?

R: Em um cluster PolarDB, cada nó possui um limite de IOPS baseado em suas especificações. Os IOPS de cada nó são isolados e não afetam outros nós.

P: O desempenho de um nó somente leitura lento pode afetar o nó primário?

R: Sim. Se um nó somente leitura tiver alta carga ou aumento na latência de replicação, poderá aumentar ligeiramente o consumo de memória do nó primário.

P: Qual é o impacto no desempenho ao ativar o binlog?

R: Ativar o binlog não afeta o desempenho de consultas (SELECT), mas impacta operações de escrita (INSERT, UPDATE, DELETE). Em um banco de dados com carga de trabalho equilibrada de leitura e escrita, ativar o binlog tipicamente impacta o desempenho em menos de 10%.

P: Qual é o impacto no desempenho ao ativar o SQL Explorer?

R: Não há impacto no desempenho.

P: Qual protocolo de rede de alta velocidade o PolarDB utiliza?

R: O PolarDB utiliza tecnologia RDMA dupla de 25 Gbps para comunicação entre seus nós de computação e armazenamento, e entre suas réplicas de dados de armazenamento. Isso fornece desempenho de I/O poderoso com baixa latência e alto throughput.

P: Qual é a largura de banda máxima para conexões externas ao PolarDB?

R: A largura de banda máxima para conexões externas ao PolarDB é de 10 Gbit/s.

P: Quais são as vantagens de armazenar tabelas grandes no PolarDB for MySQL em comparação com bancos de dados tradicionais que usam discos locais?

R: No PolarDB for MySQL, uma única tabela é dividida fisicamente e armazenada em vários servidores de armazenamento. Como resultado, as operações de I/O na tabela são distribuídas entre vários discos de armazenamento. O throughput geral de leitura de I/O, embora não a latência de I/O, é muito superior ao de bancos de dados centralizados que usam discos locais.

P: Como otimizo tabelas grandes?

R: Recomendamos o uso de tabelas particionadas.

P: Quando é apropriado usar tabelas particionadas?

R: Tabelas particionadas são adequadas para cenários onde você precisa podar tabelas grandes para controlar a quantidade de dados acessados pelas consultas, desejando que essa poda seja transparente ao código do seu negócio sem exigir modificações. Por exemplo, utilize tabelas particionadas para limpar periodicamente dados históricos de negócios, como excluir a partição do mês mais antigo e criar uma nova para o próximo mês, retendo apenas os últimos seis meses de dados.

P: Qual é a melhor maneira de copiar uma tabela muito grande (por exemplo, copiar a tabela A para a tabela B) dentro do mesmo banco de dados PolarDB for MySQL?

CREATE TABLE B AS SELECT * FROM A;

P: Posso otimizar conexões de curta duração do PHP em cenários de alta concorrência?

R: Sim. Otimize-as ativando o pool de conexões no nível de sessão nas configurações do endpoint do cluster. Para obter mais informações, consulte Configurar o endpoint do cluster, ou .

P: Como evito que algumas consultas SQL ineficientes degradem todo o banco de dados?

R: Se seu cluster PolarDB for MySQL for versão 5,6 ou 8.0, utilize o recurso de Controle de concorrência para aplicar limitação de taxa a instruções específicas.

P: O PolarDB suporta timeout de sessão ociosa?

R: Sim. Personalize o timeout para sessões ociosas modificando o parâmetro wait_timeout. Para etapas detalhadas, consulte Especificar parâmetros de cluster e nó.

P: Como encontro consultas SQL lentas?

P: Como encerro uma consulta SQL lenta?

mysql> KILL 33554499;
Query OK, 0 rows affected (0.01 sec)

P: Como um cluster PolarDB for MySQL arquiva dados quentes e mornos como dados frios?

R: Um cluster PolarDB for MySQL pode arquivar dados quentes da engine InnoDB e dados mornos do X-Engine no PolarStore para o Object Storage Service (OSS) como dados frios no formato CSV ou ORC usando políticas DDL. Esse arquivamento libera efetivamente espaço de armazenamento no PolarStore e reduz os custos gerais de armazenamento do banco de dados. Para obter mais informações, consulte Arquivar dados frios manualmente.

P: Um cluster PolarDB for MySQL suporta separação e arquivamento automáticos de dados quentes, mornos e frios? Como isso é implementado?

R: O PolarDB for MySQL suporta a separação e o arquivamento automáticos de dados quentes, mornos e frios. Ao especificar uma política DLM, arquive automaticamente dados do PolarStore para armazenamento OSS de baixo custo, reduzindo e otimizando os custos de armazenamento do banco de dados. Para obter mais informações, consulte Arquivar dados frios automaticamente.