¿Existe una referencia de rendimiento de MySQL para medir el impacto de utf8_unicode_ci versus utf8_general_ci?

Leí aquí y allá que el uso de la utf8_unicode_ciclasificación garantiza un mejor tratamiento del texto unicode (por ejemplo, sabe cómo expandir caracteres como 'œ' en 'oe' para buscar y ordenar) en comparación con el valor predeterminado utf8_general_cique básicamente elimina los signos diacríticos. Lamentablemente, ambas fuentes indican que utf8_unicode_cies un poco más lento que utf8_general_ci.

Entonces mi pregunta es: ¿qué significa "un poco más lento"? ¿Alguien ha ejecutado puntos de referencia? ¿Estamos hablando de un impacto de rendimiento de -0.01% o más bien algo como -25%?

Gracias por tu ayuda.

Bueno, no encontré ningún punto de referencia en Internet, así que decidí hacer puntos de referencia yo mismo.

Creé una tabla muy simple con 500000 filas:

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

Luego lo llené con datos aleatorios ejecutando este procedimiento almacenado:

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

Luego creé los siguientes procedimientos almacenados para comparar con SELECT simple, SELECT con LIKE y ordenar (SELECT con 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

En los procedimientos almacenados anteriores se utiliza la colación utf8_general_ci, pero, por supuesto, durante las pruebas utilicé utf8_general_ci y utf8_unicode_ci.

Llamé a cada procedimiento almacenado 5 veces para cada colación (5 veces para utf8_general_ci y 5 veces para utf8_unicode_ci) y luego calculé los valores promedio.

Aquí están los resultados:

benchmark_simple_select () con utf8_general_ci: 9957 ms
benchmark_simple_select () con utf8_unicode_ci: 10271 ms
En este punto de referencia, el uso de utf8_unicode_ci es más lento que utf8_general_ci en un 3,2%.

benchmark_select_like () con utf8_general_ci: 11441 ms
benchmark_select_like () con utf8_unicode_ci: 12811 ms
En este punto de referencia, el uso de utf8_unicode_ci es un 12% más lento que utf8_general_ci.

benchmark_order_by () con utf8_general_ci: 11944 ms
benchmark_order_by () con utf8_unicode_ci: 12887 ms
En este punto de referencia, el uso de utf8_unicode_ci es más lento que utf8_general_ci en un 7,9%.

No vi ningún punto de referencia, pero puedes ejecutar el tuyo usando la función BENCHMARK :

BENCHMARK (cuenta, expr)

Según lo recomendado por Matthew, puede ejecutar una instalación paralela de MYSQL, pero considere que podría haber una gran diferencia entre diferentes arquitecturas (sparc, intel, 32bit, 64bit, ...).