Назад | Перейти на главную страницу

Есть ли тест производительности MySQL для измерения влияния utf8_unicode_ci по сравнению с utf8_general_ci?

Я читаю Вот и там что с помощью utf8_unicode_ci сопоставление обеспечивает лучшую обработку текста в Юникоде (например, он знает, как расширять символы, такие как 'œ' в 'oe' для поиска и упорядочивания) по сравнению со значением по умолчанию utf8_general_ci что в основном просто убирает диакритические знаки. К сожалению, оба источника указывают, что utf8_unicode_ci немного медленнее, чем utf8_general_ci.

Итак, мой вопрос: что означает «немного медленнее»? Кто-нибудь запускал тесты? Мы говорим о влиянии на производительность -0,01% или, скорее, о -25%?

Спасибо за вашу помощь.

Ну, бенчмарков в интернете не нашел, поэтому решил сам сделать бенчмарки.

Я создал очень простую таблицу с 500000 строками:

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

Затем я заполнил его случайными данными, запустив эту хранимую процедуру:

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

Затем я создал следующие хранимые процедуры для тестирования простого SELECT, SELECT с LIKE и сортировки (SELECT с 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

В приведенных выше хранимых процедурах используется сопоставление utf8_general_ci, но, конечно, во время тестов я использовал как utf8_general_ci, так и utf8_unicode_ci.

Я вызвал каждую хранимую процедуру 5 раз для каждого сопоставления (5 раз для utf8_general_ci и 5 раз для utf8_unicode_ci), а затем вычислил средние значения.

Вот результаты:

benchmark_simple_select () с utf8_general_ci: 9957 мс
benchmark_simple_select () с utf8_unicode_ci: 10271 мс
В этом тесте использование utf8_unicode_ci медленнее, чем utf8_general_ci на 3,2%.

benchmark_select_like () с utf8_general_ci: 11441 мс
benchmark_select_like () с utf8_unicode_ci: 12811 мс
В этом тесте использование utf8_unicode_ci медленнее, чем utf8_general_ci на 12%.

benchmark_order_by () с utf8_general_ci: 11944 мс
benchmark_order_by () с utf8_unicode_ci: 12887 мс
В этом тесте использование utf8_unicode_ci медленнее, чем utf8_general_ci на 7,9%.

Я не видел никаких тестов, но вы можете запустить свой собственный, используя ЭТАЛОН функция:

ЭТАЛОН (количество; выражение)

Как посоветовал Мэтью, вы можете запустить параллельную установку MYSQL, но учтите, что может быть огромная разница между разными архитектурами (sparc, intel, 32bit, 64bit, ...).