Todos os produtos
Search
Central de documentação

PolarDB:Particionamento CO_HASH

Última atualização: Jun 28, 2026

O particionamento CO_HASH direciona linhas com valores de chave de partição correlacionados para a mesma partição física. Por exemplo, em uma tabela de pedidos de e-commerce em que os campos order_id e buyer_id de cada linha terminam com os mesmos dígitos, o CO_HASH garante que leituras e gravações ocorram por qualquer uma das colunas sem cruzar limites de partição. Isso elimina transações entre bancos de dados.

Pré-requisitos

PolarDB-X 5.4.18-17047709 ou posterior.

Quando usar o CO_HASH

O CO_HASH foi projetado para tabelas em que duas ou mais colunas compartilham uma relação estrutural previsível, como um sufixo ou prefixo comum. Uma tabela particionada com CO_HASH permite direcionar dados por qualquer uma dessas colunas de forma independente. Assim, todos os valores correspondentes são armazenados na mesma partição, o que possibilita o pruning de partição em cada coluna separadamente.

Use o CO_HASH quando:

  • Pelo menos duas colunas sempre compartilharem o mesmo sufixo ou prefixo. Por exemplo, os últimos N dígitos são idênticos entre as linhas.

  • As consultas filtrarem por qualquer uma dessas colunas de forma independente e cada consulta precisar acessar apenas uma única partição.

Caso as colunas não tenham similaridade estrutural garantida, prefira o particionamento HASH ou KEY. O CO_HASH não verifica a similaridade no momento da gravação; ele apenas confirma se o resultado do roteamento é consistente. Para uma comparação completa, consulte a visão geral dos tipos e políticas de tabelas particionadas.

Sintaxe

CREATE TABLE ...
PARTITION BY CO_HASH(partition_expr_list)
PARTITIONS number;

partition_expr_list:
  partition_expr, partition_expr [, partition_expr, ...]

partition_expr:
    partition_column
  | partition_func(partition_column)

-- Supported partitioning functions:
partition_func:
    RIGHT
  | LEFT
  | SUBSTR
  | SUBSTRING

Funcionamento do roteamento

O CO_HASH extrai uma substring de cada coluna de chave de partição usando a função especificada, converte o resultado em um número inteiro e aplica uma operação de módulo com base na quantidade de partições para determinar a partição de destino.

Em uma tabela com 8 partições, o roteamento para order_id = 1001234 e buyer_id = 1001234 usando RIGHT(column, 6) ocorre da seguinte forma:

Etapa

**order_id**

**buyer_id**

Extrair os últimos 6 dígitos

001234

001234

Converter para inteiro (remover zeros à esquerda)

1234

1234

MOD(1234, 8)

2

2

Partição de destino

Partition 2

Partition 2

Ambas as colunas produzem o mesmo resultado de roteamento. Portanto, a linha é armazenada na mesma partição independentemente da coluna usada na consulta.

Nota

O PolarDB-X remove automaticamente os zeros à esquerda de colunas do tipo inteiro após o truncamento. Por exemplo, RIGHT(1000034, 4) resulta em 0034, convertido para 34 antes do roteamento. Isso garante que colunas inteiras com valores correspondentes sempre sejam direcionadas à mesma partição, mesmo quando o truncamento gerar uma string preenchida com zeros.

Crie uma tabela particionada com CO_HASH

O exemplo abaixo cria uma tabela de pedidos particionada com base nos últimos seis dígitos de order_id e buyer_id. Como esses dígitos coincidem em todas as linhas, a tabela roteia as consultas corretamente, independentemente da coluna utilizada.

CREATE TABLE t_orders (
  id         BIGINT NOT NULL AUTO_INCREMENT,
  seller_id  BIGINT,
  order_id   BIGINT,
  buyer_id   BIGINT,
  order_time DATETIME NOT NULL,
  PRIMARY KEY (id)
)
PARTITION BY CO_HASH(
  RIGHT(`order_id`, 6),  -- last 6 digits of order_id
  RIGHT(`buyer_id`, 6)   -- last 6 digits of buyer_id
)
PARTITIONS 8;

Para conhecer outras funções de particionamento, consulte Funções de particionamento.

Limitações

Limites gerais

Limite

Valor

Máximo de partições por tabela

8.192 (padrão)

Máximo de colunas de chave de partição por chave

5 (padrão)

Funções de particionamento suportadas

RIGHT, LEFT, SUBSTR, SUBSTRING

Restrições adicionais:

  • Não use funções de particionamento aninhadas. Por exemplo, SUBSTR(SUBSTR(c1, -6), 4) é inválido.

  • Todas as colunas de chave de partição devem ter conjuntos de caracteres, collation, comprimento e precisão idênticos.

Tipos de dados suportados

Categoria

Tipos

Inteiro

BIGINT, BIGINT UNSIGNED, INT, INT UNSIGNED, MEDIUMINT, MEDIUMINT UNSIGNED, SMALLINT, SMALLINT UNSIGNED, TINYINT, TINYINT UNSIGNED

Data e hora

DATETIME, DATE, TIMESTAMP

String

CHAR, VARCHAR

Ponto fixo

DECIMAL (dígitos fracionários devem ser 0)

Restrições de colunas de chave de partição

A similaridade é de sua responsabilidade. O PolarDB-X roteia as linhas com base nas expressões de partição definidas, mas não verifique se os valores das colunas realmente atendem à similaridade presumida. Se c1 = 1001234 e c2 = 1320 forem inseridos em uma tabela onde você defina RIGHT(c1, 4) e RIGHT(c2, 4) como expressões de partição, o PolarDB-X fará o roteamento com base em 1234 e 1320, respectivamente. Caso esses valores resultem em partições diferentes, a instrução INSERT falhará com um erro. Nenhuma validação semântica da premissa de similaridade ocorre antes do roteamento.

Restrições de DML

Como o CO_HASH depende da consistência dos valores de chave de partição entre as colunas, modificações nesses valores são restritas.

INSERT e REPLACE

Se os valores na cláusula VALUES direcionarem diferentes colunas de chave de partição para partições distintas, a instrução será rejeitada.

-- Invalid: last 4 digits of c1 (1234) and c2 (5678) route to different partitions
INSERT INTO t1 (c1, c2) VALUES (1001234, 1005678);

-- Valid: last 4 digits of c1 (1234) and c2 (1234) route to the same partition
INSERT INTO t1 (c1, c2) VALUES (1001234, 1001234);

UPDATE e UPSERT

Quando a cláusula SET modificar qualquer coluna de chave de partição, atualize todas as colunas de chave de partição na mesma instrução. Após a atualização, todas as colunas de chave de partição ainda devem ser roteadas para a mesma partição.

-- Invalid: only c1 is updated; c2 is not updated at the same time
UPDATE t1 SET c1 = 'xx' WHERE id = 1;

-- Valid: both partition key columns are updated together
UPDATE t1 SET c1 = 'xx', c2 = 'yy' WHERE id = 1;

A instrução será rejeitada caso os valores atualizados sejam direcionados para partições diferentes.

Índice secundário global (GSI)

Se uma operação DML em uma tabela primária, como INSERT ou UPDATE, fizer com que as colunas de chave de partição do GSI sejam roteadas para partições diferentes, a operação será rejeitada.

Próximos passos