Gibt es einen MySQL-Leistungsbenchmark, um die Auswirkung von utf8_unicode_ci auf utf8_general_ci zu messen?

Ich habe hier und da gelesen , dass die Verwendung der utf8_unicode_ciKollatierung eine bessere Behandlung von Unicode-Text gewährleistet (z. B., dass Zeichen wie "œ" beim Suchen und Ordnen in "oe" umgewandelt werden) als die Standardeinstellung, bei utf8_general_cider im Grunde nur diakritische Zeichen entfernt werden. Leider geben beide Quellen an, dass utf8_unicode_cietwas langsamer ist als utf8_general_ci.

Meine Frage lautet also: Was bedeutet "etwas langsamer"? Hat jemand Benchmarks durchgeführt? Sprechen wir von einer Leistungsbeeinträchtigung von -0,01% oder eher von -25%?

Danke für Ihre Hilfe.

Nun, ich habe im Internet keine Benchmarks gefunden, also habe ich beschlossen, selbst Benchmarks zu erstellen.

Ich habe eine sehr einfache Tabelle mit 500000 Zeilen erstellt:

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

Dann habe ich es mit zufälligen Daten gefüllt, indem ich diese gespeicherte Prozedur ausgeführt habe:

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

Dann habe ich die folgenden gespeicherten Prozeduren erstellt, um einfaches SELECT, SELECT mit LIKE und Sortieren (SELECT mit ORDER BY) zu vergleichen:

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

In den obigen gespeicherten Prozeduren wird die Kollatierung utf8_general_ci verwendet, aber natürlich habe ich während der Tests sowohl utf8_general_ci als auch utf8_unicode_ci verwendet.

Ich habe jede gespeicherte Prozedur fünfmal für jede Kollatierung aufgerufen (fünfmal für utf8_general_ci und fünfmal für utf8_unicode_ci) und dann die Durchschnittswerte berechnet.

Hier sind die Ergebnisse:

benchmark_simple_select () mit utf8_general_ci: 9957 ms
benchmark_simple_select () mit utf8_unicode_ci: 10271 ms
In diesem Benchmark ist die Verwendung von utf8_unicode_ci um 3,2% langsamer als utf8_general_ci.

benchmark_select_like () mit utf8_general_ci: 11441 ms
benchmark_select_like () mit utf8_unicode_ci: 12811 ms
In diesem Benchmark ist die Verwendung von utf8_unicode_ci um 12% langsamer als utf8_general_ci.

benchmark_order_by () mit utf8_general_ci: 11944 ms
benchmark_order_by () mit utf8_unicode_ci: 12887 ms
In diesem Benchmark ist die Verwendung von utf8_unicode_ci um 7,9% langsamer als utf8_general_ci.

Ich habe keine Benchmark gesehen, aber Sie können Ihre eigene Benchmark mit der BENCHMARK- Funktion ausführen :

BENCHMARK (Anzahl, Ausdruck)

Wie von Matthew empfohlen, können Sie eine parallele Installation von MYSQL ausführen. Beachten Sie jedoch, dass es einen großen Unterschied zwischen verschiedenen Architekturen geben kann (sparc, intel, 32bit, 64bit, ...).