Ainda sobre o tamanho dos campos VARCHAR…

Ouvir com webReader

Em Setembro escrevi sobre as consequências de deixar ao acaso o tamanho e character set de campos VARCHAR. Entretanto gostaria de complementar as observações com o que escrevo abaixo.

A mistura de charsets — como ter uma tabela num charset e um determinado campo dessa tabela com outro charset diferente, por exemplo — deve ser cuidadosamente analisada. Existe alguma probabilidade de ocorrerem complicações, caso se trate esta questão levianamente.

À parte do que se deve ou não fazer, o que eu gostaria era que se compreendesse o benefício que se pode atingir no caso particular da utilização de UUIDs. Já vimos que UTF-8 para este caso particular é um desperdício, mas o que gostaria de demonstrar são se, de facto, compensa alterar campos específicos quando nem todos podem ser alterados.

Vejamos: vão ser criadas 2 tabelas MyISAM em UTF-8, uma com um campo Latin1 e outra com o campo natural, em UTF-8. Vou usar uma tabela que tinha para aqui com 2M de UUIDs apenas para acelerar o processo. Essa tabela, table_uuid, é original Latin1, embora o foco não seja sobre o carregamento dos dados, mas sim do seu cruzamento entre as duas primeiras:

MySQL:
  1. mysql> CREATE TABLE charset_latin1 ( id CHAR(36) CHARSET latin1, PRIMARY KEY (id) ) CHARSET utf8;
  2. Query OK, 0 rows affected (0.01 sec)
  3.  
  4. mysql> CREATE TABLE charset_utf8 ( id CHAR(36) CHARSET utf8, PRIMARY KEY (id) ) CHARSET utf8;
  5. Query OK, 0 rows affected (0.01 sec)
  6.  
  7. mysql> INSERT INTO charset_utf8 SELECT id FROM table_uuid ;
  8. Query OK, 2097152 rows affected (2 min 29.77 sec)
  9. Records: 2097152  Duplicates: 0  WARNINGS: 0
  10.  
  11. mysql> INSERT INTO charset_latin1 SELECT id FROM table_uuid ;
  12. Query OK, 2097152 rows affected (50.15 sec)
  13. Records: 2097152  Duplicates: 0  WARNINGS: 0

Agora, suponhamos que a tabela charset_latin1 é uma tabela originalmente em UTF-8, para a qual já fizemos a transformação do campo (que vai albergar UUIDs) para Latin1. O que pretendemos demonstrar são os ganhos/prejuízos do cruzamento de tabelas com as mesmas características, e com diferentes:

MySQL:
  1. mysql> SELECT count(1) FROM charset_utf8 a, charset_latin1 b WHERE a.id = b.id;
  2. +----------+
  3. | count(1) |
  4. +----------+
  5. 2097152 |
  6. +----------+
  7. 1 row in SET (1 min 8.82 sec)
  8.  
  9. mysql> SELECT count(1) FROM charset_utf8 a, charset_utf8 b  WHERE a.id = b.id;
  10. +----------+
  11. | count(1) |
  12. +----------+
  13. 2097152 |
  14. +----------+
  15. 1 row in SET (58.00 sec)
  16.  
  17. mysql> SELECT count(1) FROM charset_latin1 a, charset_latin1 b  WHERE a.id = b.id;
  18. +----------+
  19. | count(1) |
  20. +----------+
  21. 2097152 |
  22. +----------+
  23. 1 row in SET (24.43 sec)

Ou seja, como já se disse, fazer JOINs com Latin1 é muito rápido, relativamente às outras opções. Mas repare-se quando se cruzam diferentes charsets (1º JOIN): ocorre uma degradação de 19% face ao pior caso.

Ou seja, tendo em conta que estas tabelas podem ser apenas tabelas de relação [quero com isto dizer que não contêm dados que não sirvam senão para cruzamentos/JOINs] é expectável que a performance se degrade sempre que sejam cruzadas com outras cuja chave não esteja no mesmo charset. Deduz-se daqui que existe, portanto, overhead relativo às conversões de charset durante o JOIN.

Apesar de estarmos perante um index scan (ie, com os dados todos em cache), ocorreu-me também experimentar com InnoDB.

MySQL:
  1. mysql> ALTER TABLE charset_utf8 engine=INNODB;
  2. Query OK, 2097152 rows affected (48.18 sec)
  3. Records: 2097152  Duplicates: 0  WARNINGS: 0
  4.  
  5. mysql> ALTER TABLE charset_latin1 engine=INNODB;
  6. Query OK, 2097152 rows affected (39.43 sec)
  7. Records: 2097152  Duplicates: 0  WARNINGS: 0

Convém ressalvar aqui que fiz uns SELECTs primeiro para ter a certeza que os datafiles estavam carregados na buffer pool.

MySQL:
  1. mysql> SELECT count(1) FROM charset_utf8 a, charset_latin1 b WHERE a.id = b.id;
  2. +----------+
  3. | count(1) |
  4. +----------+
  5. 2097152 |
  6. +----------+
  7. 1 row in SET (21.65 sec)
  8.  
  9. mysql> SELECT count(1) FROM charset_utf8 a, charset_utf8 b  WHERE a.id = b.id;
  10. +----------+
  11. | count(1) |
  12. +----------+
  13. 2097152 |
  14. +----------+
  15. 1 row in SET (12.61 sec)
  16.  
  17. mysql> SELECT count(1) FROM charset_latin1 a, charset_latin1 b  WHERE a.id = b.id;
  18. +----------+
  19. | count(1) |
  20. +----------+
  21. 2097152 |
  22. +----------+
  23. 1 row in SET (8.25 sec)

Ou seja, a conclusão que se pode tirar daqui é que: não só devemos pensar na optimização que se ganha com a escolha do charset, mas também devemos analisar o impacto de não podermos levar a tarefa de reconversão avante na totalidade. A necessidade de cruzar campos com charsets diferentes torna-se, efectivamente, mais penoso. Resta comparar, caso a caso, o benefício que se obtém em queries pouco/nada optimizadas versus o prejuízo de performance que poderá reflectir-se em cruzamentos/JOINs com campos em charsets diferentes.


You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

AddThis Social Bookmark Button

Leave a Reply