Existe-t-il un référentiel de performances MySQL pour mesurer l'impact de utf8_unicode_ci par rapport à utf8_general_ci?

J'ai lu ici et là que l'utilisation du utf8_unicode_ciclassement garantit un meilleur traitement du texte unicode (par exemple, il sait comment développer des caractères tels que `` œ '' en `` oe '' pour la recherche et la commande) par rapport à la valeur par défaut utf8_general_ciqui, essentiellement, supprime simplement les signes diacritiques. Malheureusement, les deux sources indiquent que utf8_unicode_cic'est légèrement plus lent que utf8_general_ci.

Ma question est donc la suivante: que signifie «légèrement plus lent»? Quelqu'un a-t-il exécuté des repères? Parlons-nous d'un impact sur les performances de -0,01% ou plutôt de quelque chose comme -25%?

Merci de votre aide.

Eh bien, je n'ai trouvé aucun repère sur Internet, j'ai donc décidé de le faire moi-même.

J'ai créé un tableau très simple avec 500000 lignes:

CREATE TABLE test(
  ID INT(11) DEFAULT NULL,
  Description VARCHAR(20) DEFAULT NULL
)
ENGINE = INNODB
CHARACTER SET utf8
COLLATE utf8_general_ci;

Ensuite, je l'ai rempli de données aléatoires en exécutant cette procédure stockée:

CREATE PROCEDURE randomizer()
BEGIN
  DECLARE i INT DEFAULT 0;
  DECLARE random CHAR(20) ;

  theloop: loop
    SET random = CONV(FLOOR(RAND() * 99999999999999), 20, 36);

    INSERT INTO test VALUES (i+1, random);

    SET i=i+1;

    IF i = 500000 THEN
      LEAVE theloop;
    END IF;

  END LOOP theloop;
END

Ensuite, j'ai créé les procédures stockées suivantes pour comparer les sélections simples SELECT, SELECT avec LIKE et le tri (SELECT avec ORDER BY):

CREATE benchmark_simple_select()
BEGIN
  DECLARE i INT DEFAULT 0;

  theloop: loop

    SELECT * FROM test WHERE Description = 'test' COLLATE utf8_general_ci;

    SET i = i + 1;

    IF i = 30 THEN
      LEAVE theloop;
      END IF;

  END LOOP theloop;

END

CREATE PROCEDURE benchmark_select_like()
BEGIN
  DECLARE i INT DEFAULT 0;

  theloop: loop

    SELECT * FROM test WHERE Description LIKE '%test' COLLATE utf8_general_ci;

    SET i = i + 1;

    IF i = 30 THEN
      LEAVE theloop;
      END IF;

  END LOOP theloop;

END

CREATE PROCEDURE benchmark_order_by()
BEGIN
  DECLARE i INT DEFAULT 0;

  theloop: loop

    SELECT * FROM test WHERE ID > FLOOR(1 + RAND() * (400000 - 1)) ORDER BY Description COLLATE utf8_general_ci LIMIT 1000;

    SET i = i + 1;

    IF i = 10 THEN
      LEAVE theloop;
      END IF;

  END LOOP theloop;

END

Dans les procédures stockées ci-dessus, le classement utf8_general_ci est utilisé, mais bien sûr, pendant les tests, j'ai utilisé à la fois utf8_general_ci et utf8_unicode_ci.

J'ai appelé chaque procédure stockée 5 fois pour chaque classement (5 fois pour utf8_general_ci et 5 fois pour utf8_unicode_ci), puis calculé les valeurs moyennes.

Voici les résultats:

benchmark_simple_select () avec utf8_general_ci: 9957 ms
benchmark_simple_select () avec utf8_unicode_ci: 10271 ms
Dans ce cas-test, utf8_unicode_ci est plus lent que utf8_general_ci de 3,2%.

benchmark_select_like () avec utf8_general_ci: 11441 ms
benchmark_select_like () avec utf8_unicode_ci: 12811 ms
Dans ce cas-test, utf8_unicode_ci est plus lent que utf8_general_ci de 12%.

benchmark_order_by () avec utf8_general_ci: 11944 ms
benchmark_order_by () avec utf8_unicode_ci: 12887 ms
Dans ce cas-test, utf8_unicode_ci est plus lent que utf8_general_ci de 7,9%.

Je n'ai vu aucun benchmark, mais vous pouvez exécuter le vôtre en utilisant la fonction BENCHMARK :

BENCHMARK (count, expr)

Comme conseillé par Matthew, vous pouvez exécuter une installation parallèle de MYSQL, mais considérez qu'il pourrait y avoir une énorme différence entre différentes architectures (sparc, intel, 32bit, 64bit, ...).