Todos os produtos
Search
Central de documentação

Data Management:Limpeza de dados históricos

Última atualização: Oct 09, 2026

Use a limpeza de dados históricos no DMS para remover periodicamente dados antigos de tabelas grandes, liberar armazenamento e melhorar o desempenho das consultas.

Pré-requisitos

  • O banco de dados é MySQL.

  • A instância do banco de dados usa o modo Stable Change ou Security Collaboration control mode.

Procedimento

  1. Faça login no DMS 5.0.

  2. Na barra de navegação superior, escolha Database Development > Data Change > Historical Data Cleanup.

    Nota

    No modo simples do DMS, clique em ícone 2023-01-28_15-57-17.png no canto superior esquerdo e selecione All Features > Database Development > Environment Construction > Historical Data Cleanup.

  3. Na página de solicitação de ticket de Data Change, configure os parâmetros do ticket e clique em Submit.

    Principais parâmetros:

    Parâmetro

    Descrição

    Database

    Selecione um banco de dados no qual você tenha permissões de alteração. Permissões de somente leitura ou de nível de tabela não são suficientes. visualize My Permissions.

    Deletion Settings

    insira o Table Name, Time Field, Time Accuracy, Retention Period (Days) e Filter Condition (Nullable). O sistema gera automaticamente um script de limpeza com base nessas informações.

    Nota
    • Para tabelas lógicas, insira o nome da tabela lógica.

    • O período de retenção define quando o sistema exclui os dados automaticamente. Por exemplo, um período de retenção de 7 dias remove dados com mais de 7 dias.

    Por exemplo: se o Table Name for api_call_record_11, o Time Field for gmt_create, o Retention Period for 7 e o Filter Condition for status = 1 or status=2, o sistema gera a seguinte instrução SQL: DELETE FROM api_call_record_11 WHERE gmt_create < SUBDATE(CURDATE(),INTERVAL 7 DAY) AND (status = 1 or status=2);

    Schedule

    O DMS remove dados em lotes com base na chave primária ou em uma chave única não nula. Agende a limpeza para horários de baixa demanda e com baixa frequência para minimizar o impacto no desempenho.

    Nota
    • A execução real pode ter um desvio de até um minuto em relação ao horário agendado.

    • O intervalo mínimo para execução agendada é de uma hora. Por padrão, o sistema executa a tarefa às 02:00 todos os dias.

    Policy Configuration

    Especifique uma duração de execução. O sistema pausa a tarefa automaticamente após a duração especificada para evitar impactos nos serviços durante os horários de pico.

    • Execute Task Without End Time.

    • Specify End Time (Hours): defina um limite de duração para evitar impactos nos pipelines de sincronização downstream (como DTS ou AnalyticDB).

    Após especificar a duração, ative a opção Periodically Optimize Table (desfragmentação), desativada por padrão. Essa opção executa o OPTIMIZE TABLE após um número especificado de ciclos de limpeza. Padrão: a cada 60 ciclos.

    Nota
    • O recurso OPTIMIZE TABLE é compatível apenas com bancos de dados RDS for MySQL e PolarDB for MySQL.

    • A operação OPTIMIZE TABLE obedece à duração de execução na configuração da política. O sistema interrompe a operação OPTIMIZE TABLE quando essa duração termina.

    Change Stakeholder

    As partes interessadas especificadas podem visualizar e colaborar no ticket. Caso contrário, apenas administradores e DBAs podem acessá-lo.

  4. Após enviar o ticket, ative uma verificação de atraso de replicação, defina um limiar ou modifique o SQL.

    • (Opcional) Ative uma verificação de atraso de replicação para evitar que um atraso excessivo afete os failovers de primário/standby.

      Na seção Basic Information, clique em chunk option e defina um limiar de atraso de replicação em segundos. O sistema interrompe a execução do SQL se o atraso exceder esse limiar.

      Nota

      Atualmente, este recurso é compatível apenas com bancos de dados ApsaraDB RDS for MySQL.

    • (Opcional) Modifique o SQL.

      O sistema executa uma pré-verificação de SQL automaticamente. Se a pré-verificação falhar, modifique o SQL com base no motivo da falha e tente novamente.

    Nota

    Antes de enviar para aprovação, modifique as configurações de execução em lote e de agendamento. Após o envio, o sistema não permite a alteração dessas configurações.

  5. Clique em Submit. No modo Security Collaboration, o sistema envia o ticket para aprovação de acordo com as regras configuradas. No modo Stable Change, a aprovação é automática.

  6. Após a aprovação, o sistema gera uma tarefa agendada e envia um e-mail para o proprietário do ticket. Na seção Basic Information, clique em View Scheduled Tasks para visualizar os detalhes do agendamento. Você também pode:

    • Pausar agendamento

      Nota

      Para desativar permanentemente o agendamento, abra a página de detalhes do ticket, clique em Close Ticket no canto superior direito, insira um motivo e clique em Submit.

    • Retomar agendamento

      Nota

      Após o fechamento do ticket, envie um novo ticket para retomar o agendamento.

    • Alterar proprietário do ticket

      O solicitante é o proprietário do ticket por padrão. Apenas o proprietário pode pausar ou retomar o agendamento, e o sistema envia as notificações de execução exclusivamente para ele.

  7. O sistema executa o SQL de limpeza de acordo com a política de agendamento. Visualize os detalhes do agendamento e o histórico de execução no ticket.

    Nota

    Se uma tarefa de limpeza já estiver em execução no horário agendado, o sistema não cria uma nova tarefa. Configure a frequência de execução de acordo.

Perguntas frequentes

  • P: A execução de OPTIMIZE TABLE como parte de uma tarefa de limpeza de dados históricos afeta a operação?

    R: Depende. Com o Lock-free Schema Change ativado, o OPTIMIZE TABLE não afeta a operação. Sem ele, execute o OPTIMIZE TABLE durante horários de baixa demanda. Para ativar o Lock-free Schema Change, consulte ative and disable lock-free schema change.

  • P: Como interromper uma operação OPTIMIZE TABLE que está demorando muito?

    R: acesse a página Ticket Details e pause a tarefa na seção Execute.

  • P: É necessário pausar a limpeza de dados históricos ao executar o OPTIMIZE TABLE fora do DMS?

    R: Sim, pause a tarefa primeiro. O OPTIMIZE TABLE consome temporariamente de duas a três vezes o tamanho da tabela, e executar uma limpeza baseada em DELETE ao mesmo tempo aumenta a carga no disco e pode causar a falha da tarefa. Certifique-se de que a instância tenha pelo menos o mesmo espaço livre em disco que o espaço da tabela a ser liberado e execute o OPTIMIZE TABLE durante horários de baixa demanda. Retome a limpeza de dados históricos após a conclusão da operação.