Todos os produtos
Search
Central de documentação

PolarDB:Alterar tipos de tabela e políticas de particionamento (modo AUTO)

Última atualização: Jun 28, 2026

Com o crescimento dos dados ou a mudança nos padrões de consulta, o schema original de uma tabela pode se tornar um gargalo de desempenho: tabelas únicas ficam lentas sob alto volume, ou uma chave de partição inadequada causa hot spots de dados. O PolarDB for Xscale permite converter tabelas entre os tipos única, broadcast e particionada, além de ajustar chaves de partição ou algoritmos de tabelas particionadas existentes. Todas essas operações ocorrem online, sem bloquear a tabela ou impedir operações DML (Data Manipulation Language).

Importante

Alterar o tipo de tabela ou a política de particionamento é uma tarefa DDL pesada. Ela realiza uma migração completa de dados online e consome recursos significativos de CPU, I/O e rede. O tempo necessário é proporcional ao volume de dados. Execute essas operações em horários de baixa demanda e monitore o progresso com comandos de gerenciamento de tarefas.

Pré-requisitos

Antes de começar, verifique se:

  • Modo do banco de dados: O banco de dados está no modo AUTO.

  • Versão da instância: A instância PolarDB-X 2.0 executa a versão secundária do mecanismo 5.4.13 ou posterior.

  • Índice secundário global (GSI): Para alterar a política de particionamento de uma tabela particionada que possui um GSI, a instância deve executar a versão 5.4.14 ou posterior. Durante a alteração, o sistema também redistribui os dados do GSI.

Para regras de nomenclatura de versões, consulte Notas de versão . Para verificar a versão da sua instância, consulte Visualizar e atualizar a versão de uma instância .

Como funciona

Todas as operações de alteração são executadas como DDL online. A tabela original não sofre bloqueio, e as operações DML e SELECT continuam normalmente durante todo o processo.

A base de qualquer alteração de tipo de tabela ou política de particionamento é a migração física de dados:

  • Converter uma tabela única em uma tabela particionada distribui os dados de um nó de dados (DN) para vários DNs.

  • Mudar uma chave de partição reequilibra os dados entre os DNs conforme a nova política. Essa é a principal source de consumo de recursos.

Toda a tarefa DDL é atômica. Se falhar — devido a conflito de chave única, espaço em disco insuficiente ou qualquer outro motivo — os dados da tabela original permanecem intactos e seus negócios não sofrem impacto. Use o comando CANCEL DDL para reverter uma tarefa com falha.

Alterar tipos de tabela

O PolarDB for Xscale oferece suporte a três tipos de tabela. Converta entre eles online conforme as necessidades do seu negócio mudarem. Para a sintaxe completa, consulte CREATE TABLE (modo AUTO).

Se a tabela original for particionada por chave (onde a chave de partição é igual à chave primária) e você a converter para uma tabela única, ela perderá os recursos de particionamento por chave primária, incluindo políticas de particionamento automático e regras de conversão de índice. Para obter detalhes, consulte Fragmentação automática no modo AUTO .

Converter uma tabela única ou broadcast em uma tabela particionada

Quando usar: O volume de dados de uma tabela única está crescendo e se aproximando de um gargalo de desempenho. Dividir a tabela horizontalmente melhora a escalabilidade e o desempenho das consultas.

Impacto: Alto. Envolve migração completa de dados entre DNs.

Sintaxe:

ALTER TABLE table_name PARTITION BY partition_options;

Para a sintaxe de partition_options, consulte Tabelas particionadas.

Exemplo:

  1. Crie uma tabela de exemplo t_order.

    CREATE TABLE t_order (
      `id` bigint(11) NOT NULL AUTO_INCREMENT,
      `order_id` varchar(20) DEFAULT NULL,
      `buyer_id` varchar(20) DEFAULT NULL,
      `seller_id` varchar(20) DEFAULT NULL,
      `order_snapshot` longtext DEFAULT NULL,
      `order_detail` longtext DEFAULT NULL,
      PRIMARY KEY (`id`),
      KEY `l_i_order` (`order_id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
  2. Converta t_order em uma tabela particionada por KEY usando order_id como chave de partição.

    -- Convert to a KEY partitioned table with order_id as the partition key.
    ALTER TABLE t_order PARTITION BY KEY(`order_id`);
    
    -- Optionally, specify the number of partitions.
    ALTER TABLE t_order PARTITION BY KEY(`order_id`) PARTITIONS 8;

Converter uma tabela particionada ou única em uma tabela broadcast

Quando usar: A tabela possui um conjunto de dados pequeno e relativamente estático, mas participa frequentemente de junções com tabelas grandes — por exemplo, tabelas de configuração ou dicionário. Replicar a tabela em cada DN elimina a sobrecarga de junção entre bancos de dados.

Impacto: Alto. Os dados são replicados para todos os DNs.

Tabelas broadcast armazenam uma réplica completa em cada DN, o que aumenta o uso de armazenamento.

Sintaxe:

ALTER TABLE table_name BROADCAST;

Exemplo:

  1. Crie uma tabela de exemplo t_order_1.

    CREATE TABLE t_order_1 (
      `id` bigint(11) NOT NULL AUTO_INCREMENT,
      `order_id` varchar(20) DEFAULT NULL,
      `buyer_id` varchar(20) DEFAULT NULL,
      `seller_id` varchar(20) DEFAULT NULL,
      `order_snapshot` longtext DEFAULT NULL,
      `order_detail` longtext DEFAULT NULL,
      PRIMARY KEY (`id`),
      KEY `l_i_order` (`order_id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
  2. Converta t_order_1 em uma tabela broadcast.

    ALTER TABLE t_order_1 BROADCAST;

Converter uma tabela particionada ou broadcast em uma tabela única

Quando usar: A tabela tem pouco volume de dados e não requer dimensionamento horizontal. Consolidar os dados em um único DN simplifica o schema.

Impacto: Alto. Todos os dados dos shards são consolidados em um único DN. Verifique se o nó de destino tem espaço em disco suficiente antes de executar esta operação.

Sintaxe:

ALTER TABLE table_name SINGLE;

Exemplo:

  1. Crie uma tabela particionada de exemplo t_order_2.

    CREATE TABLE t_order_2 (
      `id` bigint(11) NOT NULL AUTO_INCREMENT,
      `order_id` varchar(20) DEFAULT NULL,
      `buyer_id` varchar(20) DEFAULT NULL,
      `seller_id` varchar(20) DEFAULT NULL,
      `order_snapshot` longtext DEFAULT NULL,
      `order_detail` longtext DEFAULT NULL,
      PRIMARY KEY (`id`),
      KEY `l_i_order` (`order_id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8
    PARTITION BY KEY(`order_id`)
    PARTITIONS 8;
  2. Converta t_order_2 em uma tabela única.

    ALTER TABLE t_order_2 SINGLE;

Alterar a política de particionamento de uma tabela particionada

Quando a política de particionamento existente deixar de ser adequada — devido a desequilíbrio de dados causado por uma escolha ruim de chave de partição ou mudanças nos padrões de consulta — ajuste a chave de partição, a função de partição ou o número de partições online para reotimizar a distribuição física dos dados.

Impacto: Alto. Envolve migração completa de dados. Adicionar uma partição vazia a uma tabela particionada por RANGE ou LIST (ALTER TABLE ... ADD PARTITION) é uma operação leve de metadados concluída em segundos.

Sintaxe:

ALTER TABLE tbl_name PARTITION BY new_partition_options;

Comportamento do índice ao alterar a política de particionamento:

Condição

Comportamento

As novas colunas de chave de partição formam o prefixo mais à esquerda de um índice existente

O sistema reutiliza esse índice para poda de partições; nenhum novo índice é criado

As novas colunas de chave de partição não formam o prefixo mais à esquerda de nenhum índice existente

O sistema cria automaticamente um novo índice local chamado auto_shard_key_<column(s)>

A chave primária não inclui todas as colunas de chave de partição após a alteração

A chave primária torna-se local — única apenas dentro de uma partição, não globalmente. Consulte Chaves primárias e chaves únicas (modo AUTO)

A tabela original é particionada por chave e a nova chave de partição não é a chave primária

A tabela perde recursos de particionamento por chave primária, como a criação automática de partições. Consulte Fragmentação automática no modo AUTO

Alterar a chave de partição

Cenário: A tabela t_order_3 é particionada por order_id, mas a maioria das consultas filtra por buyer_id, causando consultas frequentes entre shards. Altere a chave de partição para buyer_id e aumente as partições para 16.

  1. Visualize o schema original da tabela.

    CREATE TABLE t_order_3 (
      `id` bigint(11) NOT NULL AUTO_INCREMENT,
      `order_id` varchar(20) DEFAULT NULL,
      `buyer_id` varchar(20) DEFAULT NULL,
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8
    PARTITION BY KEY(`order_id`)
    PARTITIONS 8;
  2. Execute a alteração.

    ALTER TABLE t_order_3 PARTITION BY KEY(buyer_id) PARTITIONS 16;
  3. Verifique o resultado. Como buyer_id não forma o prefixo mais à esquerda de nenhum índice existente, o sistema cria automaticamente um índice local auto_shard_key_buyer_id.

    SHOW FULL CREATE TABLE t_order_3;
    +-----------+-----------------------------------------------------------------------+
    | Table     | Create Table                                                          |
    +-----------+-----------------------------------------------------------------------+
    | t_order_3 | CREATE TABLE `t_order_3` (
            `id` bigint NOT NULL AUTO_INCREMENT,
            `order_id` varchar(20) DEFAULT NULL,
            `buyer_id` varchar(20) DEFAULT NULL,
            PRIMARY KEY (`id`),
            LOCAL KEY `auto_shard_key_buyer_id` USING BTREE (`buyer_id`)
    ) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 DEFAULT COLLATE = utf8mb4_0900_ai_ci
    PARTITION BY KEY(`buyer_id`)
    PARTITIONS 16
    /* tablegroup = `tg12` */ |
    +-----------+---------------------------------------------------------------------+

Alterar a estratégia de particionamento

Cenário: A tabela t_order_4 é particionada por RANGE em id, mas a maioria das consultas filtra por order_id e buyer_id. Altere para particionamento por KEY em ambas as colunas com 16 partições.

  1. Visualize o schema original da tabela.

    CREATE TABLE t_order_4 (
      `id` bigint(11) NOT NULL AUTO_INCREMENT,
      `order_id` varchar(20) DEFAULT NULL,
      `buyer_id` varchar(20) DEFAULT NULL,
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8
    PARTITION BY RANGE(`id`)
    (
      PARTITION p1 VALUES LESS THAN (100),
      PARTITION p2 VALUES LESS THAN (1000),
      PARTITION P3 VALUES LESS THAN MAXVALUE
    );
  2. Execute a alteração.

    ALTER TABLE t_order_4 PARTITION BY KEY(order_id, buyer_id) PARTITIONS 16;
  3. Verifique o resultado. O sistema cria um índice local composto auto_shard_key_order_id_buyer_id.

    SHOW FULL CREATE TABLE t_order_4;
    +-----------+--------------------------------------------------------------------------------+
    | Table     | Create Table                                                                   |
    +-----------+--------------------------------------------------------------------------------+
    | t_order_4 | CREATE TABLE `t_order_4` (
            `id` bigint NOT NULL AUTO_INCREMENT,
            `order_id` varchar(20) DEFAULT NULL,
            `buyer_id` varchar(20) DEFAULT NULL,
            PRIMARY KEY (`id`),
            LOCAL KEY `auto_shard_key_order_id_buyer_id` USING BTREE (`order_id`, `buyer_id`)
    ) ENGINE = InnoDB DEFAULT CHARSET = utf8mb3
    PARTITION BY KEY(`order_id`,`buyer_id`)
    PARTITIONS 16
    /* tablegroup = `tg15` */ |
    +-----------+------------------------------------------------------------------------------+

Aumentar o número de partições

Cenário: À medida que o volume de dados cresce, aumente as partições para distribuir os dados mais amplamente.

  1. Visualize o schema original da tabela.

    CREATE TABLE t_order_5 (
      `id` bigint(11) NOT NULL AUTO_INCREMENT,
      `order_id` varchar(20) DEFAULT NULL,
      `buyer_id` varchar(20) DEFAULT NULL,
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8
    PARTITION BY KEY(`order_id`)
    PARTITIONS 8;
  2. Execute a alteração.

    ALTER TABLE t_order_5 PARTITION BY KEY(order_id) PARTITIONS 128;
  3. Verifique o resultado. A contagem de partições aumenta de 8 para 128.

    SHOW FULL CREATE TABLE t_order_5;
    +-----------+----------------------------------------------------------+
    | Table     | Create Table                                             |
    +-----------+----------------------------------------------------------+
    | t_order_4 | CREATE TABLE `t_order_5` (
            `id` bigint NOT NULL AUTO_INCREMENT,
            `order_id` varchar(20) DEFAULT NULL,
            `buyer_id` varchar(20) DEFAULT NULL,
            PRIMARY KEY (`id`),
            LOCAL KEY `auto_shard_key_order_id` USING BTREE (`order_id`)
    ) ENGINE = InnoDB DEFAULT CHARSET = utf8mb3
    PARTITION BY KEY(`order_id`)
    PARTITIONS 128
    /* tablegroup = `tg13` */ |
    +-----------+---------------------------------------------------------+

Monitorar e gerenciar tarefas DDL

Use os seguintes comandos para gerencie tarefas de redistribuição de dados durante todo o ciclo de vida.

Monitorar o progresso da tarefa

Use SHOW DDL para visualizar tarefas DDL atuais e históricas.

SHOW DDL;

Pausar e retomar uma tarefa

Se uma tarefa em execução afetar o desempenho durante horários de pico, pause-a e retome-a em horários de baixa demanda.

-- Pause the task. Get <JobId> from SHOW DDL output.
PAUSE DDL <JobId>;

-- Resume the task.
CONTINUE DDL <JobId>;

Cancelar e reverter uma tarefa

Use CANCEL DDL para encerrar uma tarefa em execução ou com falha. O sistema reverte todas as alterações e restaura o schema e os dados da tabela para o estado anterior à tarefa.

-- Roll back the task. Get <JobId> from SHOW DDL output.
CANCEL DDL <JobId>;

Entrada em produção

  • Temporização: Execute alterações em horários de baixa demanda para minimizar o impacto na carga de trabalho de produção.

  • Planejamento de capacidade: Antes de executar uma alteração, verifique se os DNs de destino têm espaço em disco, CPU e IOPS suficientes — especialmente ao converter uma tabela particionada em uma tabela única ou ao redistribuir grandes conjuntos de dados.

  • Backup: Crie um backup completo dos dados antes de fazer alterações significativas no schema em ambiente de produção, mesmo sabendo que é possível reverter uma tarefa DDL com falha.

  • Verificação: Após a conclusão da tarefa, execute SHOW CREATE TABLE <tablename> para visualizar a nova definição da tabela ou use SHOW TOPOLOGY para visualizar a nova topologia de fragmentação de dados.

Perguntas frequentes

Por que minha alteração de chave de partição falhou e como me recuperar?

As causas mais comuns são espaço em disco insuficiente no DN de destino, conflitos de índice único durante a migração de dados ou falha na instância. Uma tarefa com falha não corrompe os dados da tabela original nem bloqueia operações DML e de consulta. Execute SHOW DDL para identificar o motivo da falha, corrija o problema subjacente (por exemplo, libere espaço em disco ou resolva linhas conflitantes) e use CANCEL DDL <JobId> para reverter a tarefa com falha antes de tentar novamente.

Adicionar uma nova partição é sempre tão lento quanto alterar uma chave de partição?

Não. Alterar um tipo de tabela ou política de particionamento é demorado porque envolve migração completa de dados. Adicionar uma partição vazia futura a uma tabela particionada por RANGE ou LIST (usando ALTER TABLE ... ADD PARTITION) é uma operação de metadados concluída em segundos com impacto mínimo na sua carga de trabalho.

Se já existir um índice nas novas colunas de chave de partição, o sistema ainda cria um índice auto_shard_key_...?

Não. O sistema verifica se as novas colunas de chave de partição formam o prefixo mais à esquerda de um índice existente. Em caso afirmativo, o sistema reutiliza esse índice para poda de partições e não cria um novo. Caso contrário, o sistema cria automaticamente um novo índice local para manter o desempenho das consultas.

Como verifico se um banco de dados está no modo AUTO?

Execute SHOW CREATE DATABASE <database_name>. A propriedade MODE no resultado indica o modo do banco de dados.