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).
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.13ou 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.14ou 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:
-
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; -
Converta
t_orderem uma tabela particionada por KEY usandoorder_idcomo 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:
-
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; -
Converta
t_order_1em 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:
-
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; -
Converta
t_order_2em 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 |
|
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.
-
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; -
Execute a alteração.
ALTER TABLE t_order_3 PARTITION BY KEY(buyer_id) PARTITIONS 16; -
Verifique o resultado. Como
buyer_idnão forma o prefixo mais à esquerda de nenhum índice existente, o sistema cria automaticamente um índice localauto_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.
-
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 ); -
Execute a alteração.
ALTER TABLE t_order_4 PARTITION BY KEY(order_id, buyer_id) PARTITIONS 16; -
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.
-
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; -
Execute a alteração.
ALTER TABLE t_order_5 PARTITION BY KEY(order_id) PARTITIONS 128; -
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.