Início / dba / Perguntas / 20754
Accepted
Haluk
Asked: 2012-07-12 15:08:04 +0800 CST

MySQL, "particionamento de colunas" quando várias colunas são individualmente importantes

  • 772

MySQL 5.5 apresenta "particionamento de colunas".
http://dev.mysql.com/doc/refman/5.5/en/partitioning-columns.html

Estou tentando entender melhor como funciona quando duas colunas são importantes individualmente.

Digamos para uma tabela que contém as mensagens entre dois usuários do sistema. Teríamos potencialmente as colunas "sender_id" e "receiver_id" e poderíamos querer consultar essas colunas individualmente.

Se tivermos índices separados em ambas as colunas, podemos consultá-los individualmente quando necessário. Os resultados são rápidos.

Mas e se nossa tabela tiver 100 milhões de linhas e considerarmos o particionamento? Meu entendimento é que o particionamento de várias colunas se concentra na primeira coluna na definição de colunas e depois na segunda. Aqui está uma estrutura de tabela de exemplo:

CREATE TABLE messages (
         message_id INT,
         sender_id INT,
         receiver_id INT
     )
     PARTITION BY RANGE COLUMNS(sender_id,receiver_id) (
         PARTITION p0 VALUES LESS THAN (10,10),
         PARTITION p1 VALUES LESS THAN (20,20),
         PARTITION p3 VALUES LESS THAN (MAXVALUE,MAXVALUE)

Se consultarmos "WHERE receiver_id=5", a remoção de partição não será ativada, certo? Será necessário pesquisar todas as partições. Mas se procurássemos por "WHERE sender_id=5", saberíamos imediatamente que o resultado está em p0.

Portanto, para uma tabela em que duas colunas podem ser individualmente importantes, o particionamento pode não ser a melhor solução, pois agora perdemos o benefício de um índice de tabela completa para a coluna secundária (receiver_id, neste caso) no parâmetro de colunas. Isso está certo?

mysql partitioning

1 respostas

  1. Best Answer

    Você está certo que o mysql verificará apenas uma partição para um sender_id específico, mas verifica todas as partições para um receiver_id específico, conforme mostrado aqui:

    mysql> explain partitions select * from messages where sender_id =5;
+----+-------------+----------+------------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table    | partitions | type | possible_keys | key  | key_len | ref  | rows | Extra       |
+----+-------------+----------+------------+------+---------------+------+---------+------+------+-------------+
|  1 | SIMPLE      | messages | p0         | ALL  | NULL          | NULL | NULL    | NULL |    2 | Using where |
+----+-------------+----------+------------+------+---------------+------+---------+------+------+-------------+
1 row in set (0.00 sec)

mysql> explain partitions select * from messages where receiver_id =5;
+----+-------------+----------+------------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table    | partitions | type | possible_keys | key  | key_len | ref  | rows | Extra       |
+----+-------------+----------+------------+------+---------------+------+---------+------+------+-------------+
|  1 | SIMPLE      | messages | p0,p1,p3   | ALL  | NULL          | NULL | NULL    | NULL |    3 | Using where |
+----+-------------+----------+------------+------+---------------+------+---------+------+------+-------------+
1 row in set (0.00 sec)

    No entanto, ainda há benefícios nesse particionamento, dependendo do seu hardware. Ao procurar em todas as partições por um receiver_id, o mysql está realmente executando 3 instruções select, uma para cada partição. Pode ser capaz de paralelizar essas instruções select. Além disso, se você indexar receiver_id, ele acessará 3 índices menores.

    No final, você só precisa fazer testes de desempenho e ver se está valendo a pena para o seu caso de uso. Visto que 100 MB cabem na RAM com bastante facilidade hoje em dia, não consideraria particionar uma tabela tão pequena, a menos que você tenha motivos específicos para fazê-lo.

    • 2

relate perguntas