Todos os produtos
Search

Este produto

    AnalyticDB:Gravações e consultas

    Central de documentação

    AnalyticDB:Gravações e consultas

    Última atualização: Aug 24, 2026

    Este tópico responde às perguntas frequentes sobre gravações e consultas no AnalyticDB for MySQL.

    Nota

    Caso a edição do product não seja especificada em uma pergunta, a resposta se aplica apenas ao AnalyticDB for MySQL Data Warehouse Edition e Enterprise Edition.

    Visão geral das perguntas frequentes

    Os clusters da Enterprise Edition, Basic Edition e Data Lakehouse Edition suportam consulta de dados em tabelas Hudi via JDBC?

    Sim. Após crie uma tabela Hudi em um cluster da Enterprise Edition, Basic Edition ou Data Lakehouse Edition, você pode consultar diretamente a tabela Hudi usando JDBC.

    Os clusters da Enterprise Edition, Basic Edition e Data Lakehouse Edition suportam leitura de dados de tabelas Hudi do OSS?

    Sim. Para obter mais informações sobre como ler dados de tabelas Hudi no OSS usando uma tabela externa, consulte Use an external table to import data into a Data Lakehouse Edition cluster.

    Enterprise Edition, Basic Edition e Data Lakehouse Edition: os clusters suportam alternância automática entre jobs XIHE MPP e jobs XIHE BSP?

    Não. Ao envie um job, você deve especifique manualmente se deseja enviá-lo para um grupo de recursos Interactive ou Job. Essa escolha determina se o job será executado como um job XIHE MPP ou XIHE BSP.

    Como escolha entre XIHE MPP e XIHE BSP para execute jobs em clusters da Enterprise Edition, Basic Edition e Data Lakehouse Edition?

    Por padrão, um job XIHE BSP é enviado de forma assíncrona. A diferença entre o envio síncrono e o assíncrono reside na necessidade de o cliente aguardar ou não a conclusão da consulta.

    O envio assíncrono apresenta as seguintes limitações:

    • O conjunto de resultados pode conter no máximo 10.000 linhas.

    • É possível reter até 1.000 conjuntos de resultados, incluindo seus links para baixe de arquivos CSV, por até 30 dias.

    Recomendamos o uso do envio assíncrono para consultas com longos tempos de execução e altas cargas computacionais, mas que retornam pequenos conjuntos de resultados, como INSERT INTO SELECT, INSERT OVERWRITE SELECT ou CREATE TABLE AS SELECT.

    Clusters da Enterprise Edition, Basic Edition e Data Lakehouse Edition: como visualize o status de um job XIHE BSP?

    • Se você enviou um job XIHE BSP usando o editor de jobs em um cluster da Data Lakehouse Edition, acesse a página Job Editor > SQL Development e visualize o status do job na aba Execution Records, na parte inferior da página.

    • Caso o envio do job XIHE BSP não tenha sido feito pelo editor de jobs, consulte o status dele em uma tabela de sistema interna. Execute a seguinte instrução:

      SELECT status FROM information_schema.kepler_meta_elastic_job_list WHERE process_id='<job_id>';

      Para obter uma contagem de todos os jobs XIHE BSP agrupados por status, execute a seguinte instrução:

      SELECT status,count(*) FROM information_schema.kepler_meta_elastic_job_list GROUP BY status;

    Isolamento de recursos para jobs SQL

    Os clusters da Data Warehouse Edition (Elastic Mode) e da Enterprise Edition, Basic Edition e Data Lakehouse Edition suportam grupos de recursos. Para mais detalhes sobre os tipos de grupos de recursos, consulte Resource group overview (Data Warehouse Edition) e Resource group overview (Data Lakehouse Edition). Crie diferentes tipos de grupos de recursos e envie jobs SQL para os grupos adequados para garantir o isolamento de recursos.

    Como lidar com excesso de itens em uma cláusula IN

    O AnalyticDB for MySQL limita o número de itens em uma lista IN. O limite padrão é de 2.000, mas esse valor pode ser ajustado.

    Nota

    A quantidade de itens em uma lista IN não pode exceder 5.000. Um número maior pode degradar o desempenho.

    Por exemplo, para defina o limite como 3.000, execute a seguinte instrução:

    SET ADB_CONFIG max_in_items_count=3000;

    Resolução do erro "Query exceeded maximum time limit"

    Esse erro ocorre porque a consulta SQL ultrapassou o tempo limite padrão de execução de 1.800.000 ms (30 minutos) configurado no AnalyticDB for MySQL. Configure o tempo limite de consulta para uma única consulta ou para todas as consultas do cluster:

    • Defina o tempo limite para uma única consulta.

      /*+ QUERY_TIMEOUT=xxx */SELECT count(*) FROM t;

    • Defina o tempo limite para todas as consultas do cluster.

      SET ADB_CONFIG QUERY_TIMEOUT=xxx;

      Para mais informações, consulte Common configuration parameters.

    Resolução de erros de falta de memória

    Causa: podem existir consultas SQL grandes e de longa execução no cluster AnalyticDB for MySQL. Essas consultas consomem uma grande quantidade de memória, o que provoca um erro de falta de memória ao envie uma nova consulta SQL.

    Solução: aguarde alguns minutos e execute a instrução SQL novamente.

    Resolução do erro "STORAGE_INDEX_ERROR"

    Causa: esse erro é provocado por um defeito conhecido em algumas versões anteriores do kernel do AnalyticDB for MySQL. Sob condições específicas, esse defeito pode causar inconsistências nos metadados de índice de uma tabela. Consequentemente, o índice não é encontrado durante uma consulta, o que aciona a exceção STORAGE_INDEX_ERROR.

    Solução: Upgrade the kernel version of your cluster. Esse problema foi corrigido nas versões posteriores do kernel.

    Importante

    • Duração da atualização: a atualização da versão do kernel geralmente leva cerca de 30 minutos.

    • Interrupção do service: durante a atualização, ocorre uma interrupção transitória de conexão de alguns segundos.

    • Recomendação: realize a atualização durante uma janela de manutenção programada ou em horários de baixa demanda. Certifique-se de que sua aplicação possua um mecanismo de reconexão automática para lidar adequadamente com a interrupção transitória da conexão.

    Resolução do erro "multi-statement found"

    Apenas clusters com versão de kernel 3.1.9.3 ou posterior suportam o recurso multi-statement. Primeiro, verifique se a versão do kernel do seu cluster é 3.1.9.3 ou superior. Se a versão do kernel for anterior a 3.1.9.3, entre em contato com o suporte técnico para realizar a atualização. Caso a versão do kernel seja 3.1.9.3 ou posterior, mas o erro persista, o recurso multi-statement pode estar desativado no cliente.

    Por exemplo, ao usar um cliente JDBC do MySQL para se conectar a um cluster, além de execute o comando SET ADB_CONFIG ALLOW_MULTI_QUERIES=true; para ative manualmente o recurso Multi-Statement, também é necessário defina a propriedade de conexão JDBC allowMultiQueries como true.

    Solução de problemas com valores de tempo truncados nos resultados de consulta

    Primeiro, verifique o resultado usando um cliente MySQL. Se o valor de tempo for exibido corretamente no cliente MySQL, o problema pode ser causado por outra ferramenta cliente que esteja processando o conjunto de resultados.

    Correção de erros na função AES_ENCRYPT

    A seguinte instrução reporta um erro.

     SELECT CONVERT(AES_DECRYPT(AES_ENCRYPT('ABC123','key_string'),'key_string'),char(10));

    Causa: o erro ocorre porque o tipo de dados do primeiro argumento x na função AES_ENCRYPT(varbinary x, varchar y) deve ser varbinary. O exemplo a seguir mostra uma instrução válida:

    SELECT CONVERT(AES_DECRYPT(AES_ENCRYPT(CAST('ABC123' AS VARBINARY), 'key_string'), 'key_string'),char(10));

    Alterações inesperadas nos resultados de consulta

    Se você confirme que os dados não foram atualizados, os resultados da consulta podem mudar inesperadamente pelos seguintes motivos:

    • Uma cláusula LIMIT é usada sem uma cláusula ORDER BY. O AnalyticDB for MySQL é um banco de dados distribuído que executa consultas em vários nós e múltiplas threads. Se algumas threads retornarem linhas suficientes para satisfazer a cláusula LIMIT, a consulta é encerrada. Portanto, sem uma cláusula ORDER BY, a ordem dos resultados não é garantida, pois o sistema não consegue assegurar uma ordem fixa de resposta das threads.

    • Em uma consulta agregada com agrupamento, se um campo na lista SELECT não estiver dentro de uma função de agregação e não for incluído na cláusula GROUP BY, um valor aleatório do grupo será retornado para esse campo.

    Se o problema persistir, entre em contato com o suporte técnico.

    Consultas ORDER BY lentas em uma única tabela

    Causa: os dados não estão classificados na camada de armazenamento e são armazenados de maneira dispersa. Isso pode desencadear uma grande quantidade de leituras de dados desnecessárias, aumentando o tempo de consulta.

    Solução: crie um índice clusterizado no campo especificado na cláusula ORDER BY. Com um índice clusterizado, os dados são parcialmente ordenados na camada de armazenamento. As consultas ORDER BY passam então a ler menos dados, o que melhora o desempenho. Para mais informações sobre como crie um índice clusterizado, consulte Add a clustered index.

    Nota

    • Cada tabela suporta apenas um índice clusterizado. Se já existir um índice clusterizado em outro campo, exclua-o antes de crie um novo no campo especificado na cláusula ORDER BY.

    • Após adicionar um índice clusterizado a uma tabela grande, o tempo necessário para os jobs BUILD aumenta, o que afeta a utilização da CPU nos nós de armazenamento.

    Discrepância na contagem de linhas verificadas

    Esse problema é geralmente causado por tabelas replicadas. No AnalyticDB for MySQL, uma cópia de uma tabela replicada é armazenada em cada shard. Ao consultar uma tabela replicada, o número de linhas verificadas é contado repetidamente para cada cópia.

    Duplicação de dados com INSERT OVERWRITE

    A deduplicação automática não é suportada para tabelas no AnalyticDB for MySQL que não possuem chave primária.

    Resolução do erro "Column not in GROUP BY clause"

    Em uma consulta agrupada, não é possível usar a instrução de consulta SELECT * FROM table GROUP BY key para recuperar todos os campos. Liste explicitamente todos os campos. Abaixo está um exemplo de SQL.

    SELECT nation.name FROM nation GROUP BY nation.nationkey

    Por que o INSERT OVERWRITE SELECT não sobrescreve os dados da tabela original?

    Causa: a instrução INSERT OVERWRITE sobrescreve os dados com base em partições. Novas partições substituem partições antigas que compartilham os mesmos valores de partição. Se o resultado do SELECT estiver vazio, nenhuma nova partição será criada e, portanto, os dados existentes na tabela original não serão sobrescritos.

    Solução: modifique a instrução INSERT OVERWRITE SELECT para garantir que o resultado do SELECT não esteja vazio antes de sobrescrever os dados na tabela original.

    Limite de valores do operador IN em resultados JSON

    Para clusters do AnalyticDB for MySQL com versão de kernel 3.1.4 ou anterior, o número de valores especificados em um operador IN não pode exceder 16. Para clusters com versão de kernel posterior a 3.1.4, não há limite imposto. Para obter informações sobre como verifique a versão do kernel do seu cluster, consulte View the kernel version of a cluster.

    Uso de arquivos CSV compactados com GZIP do OSS como source de dados

    O AnalyticDB for MySQL suporta o uso de arquivos CSV compactados com GZIP do OSS como source de dados para uma tabela externa. Para isso, adicione compress_type=gzip à definição da tabela externa. Para mais informações sobre a sintaxe de tabela externa do OSS, consulte Non-partitioned OSS external tables.

    O INSERT ON DUPLICATE KEY é suportado?

    O AnalyticDB for MySQL suporta apenas atualizações por igualdade de valores, não expressões aritméticas.

    Uso de cláusula JOIN em instruções UPDATE

    Esse recurso está disponível apenas para clusters do AnalyticDB for MySQL com versão de kernel 3.1.6.4 ou posterior. Para mais informações, consulte UPDATE.

    Posso defina variáveis em uma instrução SQL?

    O AnalyticDB for MySQL não suporta a definição de variáveis em instruções SQL.

    É possível usar a instrução INSERT ON DUPLICATE KEY UPDATE para inserir dados em massa com o plugin Logstash?

    Sim. Ao usar a instrução INSERT ON DUPLICATE KEY UPDATE para inserir dados em lotes, não é necessário adicionar ON DUPLICATE KEY UPDATE após cada instrução VALUES(). Basta adicioná-lo após a última instrução VALUES().

    Por exemplo, para inserir em lote 3 registros na tabela student_course, execute a seguinte instrução:

    INSERT INTO student_course(`id`, `user_id`, `nc_id`, `nc_user_id`, `nc_commodity_id`, `course_no`, `course_name`, `business_id`)
VALUES(277943, 11056941, '1001EE1000000043G2T5', '1001EE1000000043G2TO', '1001A5100000003YABO2', 'kckm303', 'Industrial Accounting Practice V9.0--77', 'kuaiji'),
(277944, 11056943, '1001EE1000000043G2T5', '1001EE1000000043G2TO', '1001A5100000003YABO2', 'kckm303', 'Industrial Accounting Practice V9.0--88', 'kuaiji'),
(277945, 11056944, '1001EE1000000043G2T5', '1001EE1000000043G2TO', '1001A5100000003YABO2', 'kckm303', 'Industrial Accounting Practice V9.0--99', 'kuaiji')
ON DUPLICATE KEY UPDATE
course_name = 'Industrial Accounting Practice V9.0--77',
business_id = 'kuaiji';

    Pré-requisitos para carregar um conjunto de dados integrado

    O cluster deve ter pelo menos 24 ACUs de recursos de armazenamento reservados, e o grupo de recursos user_default deve ter pelo menos 16 ACUs de recursos de computação reservados.

    Verificação do carregamento de um conjunto de dados integrado

    Visualize o progresso do carregamento na página Job Development > SQL Development. O conjunto de dados foi carregado com sucesso se o ícone 1 no botão Load Built-in Dataset estiver esmaecido e o banco de dados ADB_SampleData_TPCH e suas tabelas estiverem visíveis na aba Databases and Tables.

    Tratamento de falhas ao carregar um conjunto de dados integrado

    Execute primeiro a instrução SQL DROP TABLE table_name; para exclua todas as tabelas do banco de dados. Em seguida, execute a instrução SQL DROP DATABASE ADB_SampleData_TPCH; para exclua o banco de dados do conjunto de dados integrado. Após a exclusão do banco de dados ADB_SampleData_TPCH, recarregue o conjunto de dados.

    Uso de um conjunto de dados integrado com uma conta padrão

    O recurso de conjunto de dados integrado segue as regras de gerenciamento de permissões do AnalyticDB for MySQL. Mesmo que um conjunto de dados integrado esteja carregado no cluster, uma conta de banco de dados padrão não poderá usá-lo sem permissões no banco de dados ADB_SampleData_TPCH. Uma conta privilegiada deve conceder as permissões necessárias à conta padrão executando a seguinte instrução:

    GRANT select ON ADB_SampleData_TPCH.* TO <user_name>;

    Teste de um conjunto de dados integrado

    Após o carregamento bem-sucedido do conjunto de dados, o AnalyticDB for MySQL fornece um conjunto de scripts de consulta correspondentes. Na página SQL Development, abra a aba Scripts e execute as instruções de consulta de exemplo. Para mais informações sobre as consultas, consulte TPC-H test queries.

    Importante

    Para garantir a integridade do conjunto de dados, recomendamos realizar apenas operações de leitura no banco de dados ADB_SampleData_TPCH. Se o status de carregamento do conjunto de dados estiver anormal devido a alterações DDL ou DML, exclua o banco de dados ADB_SampleData_TPCH e carregue o conjunto de dados novamente.