Интересное поведение MySQL во время бенчмаркинга - PullRequest
Новая
       9

Интересное поведение MySQL во время бенчмаркинга

0 голосов
/ 06 января 2019

Я пытаюсь понять разницу в производительности MySQL между ВЫБОРОМ данных сразу после заполнения данных и несколькими минутами позже.

Я написал код, который:

  1. СОЗДАЕТ пять таблиц с целочисленным первичным ключом, несколько столбцов varchar (50), а для четырех таблиц - целочисленный внешний ключ к предыдущей таблице.

  2. Заполняет таблицы случайными данными, например, 10 тыс. Строк на таблицу.

Затем он ВЫБИРАЕТ данные из всех таблиц двумя способами:

Способ № 1: с помощью ЛЕВОГО ВНЕШНЕГО СОЕДИНЕНИЯ, например ::

SELECT SQL_NO_CACHE
       Bench1.id AS a_id, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10,
       Bench2.id AS b_id, b1, b2, b3, b4, b5, b6, b7, b8, b9, b10,
       Bench3.id AS c_id, c1, c2, c3, c4, c5, c6, c7, c8, c9, c10,
       Bench4.id AS d_id, d1, d2, d3, d4, d5, d6, d7, d8, d9, d10,
       Bench5.id AS e_id, e1, e2, e3, e4, e5, e6, e7, e8, e9, e10
   FROM Bench1 
    LEFT OUTER JOIN Bench2 ON Bench2.bench1Id = Bench1.id
    LEFT OUTER JOIN Bench3 ON Bench3.bench2Id = Bench2.id
    LEFT OUTER JOIN Bench4 ON Bench4.bench3Id = Bench3.id
    LEFT OUTER JOIN Bench5 ON Bench5.bench4Id = Bench4.id
    WHERE Bench1.id IN (342, 452, 81, 405, ...)

Метод № 2: с пятью отдельными запросами SELECT, например ::

SELECT SQL_NO_CACHE id, a1, a2, a3, ... FROM Bench1
         WHERE id IN (342, 452, 81, 405, ...)
SELECT SQL_NO_CACHE id, b1, b2, b3, ... FROM Bench2 WHERE bench1Id IN (...)
SELECT SQL_NO_CACHE id, c1, c2, c3, ... FROM Bench3 WHERE bench2Id IN (...)
SELECT SQL_NO_CACHE id, d1, d2, d3, ... FROM Bench4 WHERE bench3Id IN (...)
SELECT SQL_NO_CACHE id, e1, e2, e3, ... FROM Bench5 WHERE bench4Id IN (...)
...

Оба метода дают одну и ту же информацию (но очевидно, что ответ JOIN больше из-за дублирования данных).

Теперь самое интересное. Кажется, существует огромная разница в производительности, в зависимости от того, как долго после заполнения данных выполняется SELECT.

Если я заполняю данные, жду 10 минут и затем запускаю тест, я получаю довольно последовательные результаты, где метод JOIN примерно на 40% медленнее, чем множественные запросы.

Однако, если я заполняю данные, а затем сразу же запускаю эталонный тест - СОЕДИНЕНИЯ становятся в несколько сотен раз медленнее, чем множественные запросы (обычно в 500 раз медленнее, я также видел, что это более чем в 1000 раз медленнее).

Я также упомяну, что производительность многопользовательских запросов, по-видимому, (существенно) не зависит от времени ожидания после заполнения. Похоже, что это влияет только на соединения.

Я также пытался изменить порядок SELECT (то есть делать SELECTs с несколькими запросами до JOIN) - это не имело никакого значения.

Мне удалось воспроизвести это поведение на локальной установке MySQL 5.7, а также на AWS RDS MySQL (при запуске кода на EC2).

Кто-нибудь может объяснить это поведение? Что происходит через несколько минут после ВСТАВКИ большого количества данных, которые так сильно влияют на производительность?

Я думал о некоторой фоновой перестройке или оптимизации индексов, но если это так, то почему это не влияет на метод множественных запросов? Эти запросы зависят от одинаковых индексов ...

UPDATE:

Дополнительная информация: CREATE TABLE, SHOW TABLE STATUS, innodb_buffer_pool_size и размер оперативной памяти:

CREATE TABLE 

CREATE TABLE Bench1 (
    id int(11) NOT NULL,
    a1 varchar(50) DEFAULT NULL,
    a2 varchar(50) DEFAULT NULL,
    a3 varchar(50) DEFAULT NULL,
    PRIMARY KEY (id)
)

CREATE TABLE Bench2 (
    id int(11) NOT NULL,
    bench1Id int(11) DEFAULT NULL,
    b1 varchar(50) DEFAULT NULL,
    b2 varchar(50) DEFAULT NULL,
    b3 varchar(50) DEFAULT NULL,
    PRIMARY KEY (id),
    KEY bench1Id (bench1Id),
    CONSTRAINT Bench2_ibfk_1 FOREIGN KEY (bench1Id) REFERENCES Bench1 (id)
)

CREATE TABLE Bench3 (
    id int(11) NOT NULL,
    bench2Id int(11) DEFAULT NULL,
    c1 varchar(50) DEFAULT NULL,
    c2 varchar(50) DEFAULT NULL,
    c3 varchar(50) DEFAULT NULL,
    PRIMARY KEY (id),
    KEY bench2Id (bench2Id),
    CONSTRAINT Bench3_ibfk_1 FOREIGN KEY (bench2Id) REFERENCES Bench2 (id)
)

CREATE TABLE Bench4 (
    id int(11) NOT NULL,
    bench3Id int(11) DEFAULT NULL,
    d1 varchar(50) DEFAULT NULL,
    d2 varchar(50) DEFAULT NULL,
    d3 varchar(50) DEFAULT NULL,
    PRIMARY KEY (id),
    KEY bench3Id (bench3Id),
    CONSTRAINT Bench4_ibfk_1 FOREIGN KEY (bench3Id) REFERENCES Bench3 (id)
)

CREATE TABLE Bench5 (
    id int(11) NOT NULL,
    bench4Id int(11) DEFAULT NULL,
    e1 varchar(50) DEFAULT NULL,
    e2 varchar(50) DEFAULT NULL,
    e3 varchar(50) DEFAULT NULL,
    PRIMARY KEY (id),
    KEY bench4Id (bench4Id),
    CONSTRAINT Bench5_ibfk_1 FOREIGN KEY (bench4Id) REFERENCES Bench4 (id)
)
* * `Тысяча сорок-девять

ПОКАЗАТЬ СТАТУС СТАТУС 

Name    Engine  Version  Row_format  Rows   Avg_row_length  Data_length  Max_data_length  Index_length  Data_free  Auto_increment  Create_time          Update_time          Check_time  Collation        Checksum  Create_options  Comment                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           
Bench1  InnoDB  10       Dynamic     500    163             81920        0                0             0                          2019-01-06 21:36:39  2019-01-06 21:36:39              utf8_general_ci
Bench2  InnoDB  10       Dynamic     4964   320             1589248      0                147456        4194304                    2019-01-06 21:36:39  2019-01-06 21:36:39              utf8_general_ci
Bench3  InnoDB  10       Dynamic     25045  147             3686400      0                540672        4194304                    2019-01-06 21:36:39  2019-01-06 21:36:40              utf8_general_ci
Bench4  InnoDB  10       Dynamic     49914  136             6832128      0                1589248       4194304                    2019-01-06 21:36:39  2019-01-06 21:36:41              utf8_general_ci
Bench5  InnoDB  10       Dynamic     49259  138             6832128      0                1589248       4194304                    2019-01-06 21:36:39  2019-01-06 21:36:42              utf8_general_ci

ПОКАЗАТЬ ПЕРЕМЕННЫЕ, КАК 'innodb_buffer_pool_size'

Значение переменной_имя
innodb_buffer_pool_size 25769803776

размер оперативной памяти

32 ГБ (при использовании AWS RDS db.m4.2xlarge)

ОБНОВЛЕНИЕ 2:

Дополнительная информация: ОБЪЯСНЯЕТ

Метод 1: 

EXPLAIN
SELECT SQL_NO_CACHE Bench1.id AS a_id, a1, a2, a3, Bench2.id AS b_id, b1, b2, b3, Bench3.id AS c_id, c1, c2, c3, Bench4.id AS d_id, d1, d2, d3, Bench5.id AS e_id, e1, e2, e3 FROM Bench1
LEFT OUTER JOIN Bench2 ON Bench2.bench1Id = Bench1.id
LEFT OUTER JOIN Bench3 ON Bench3.bench2Id = Bench2.id
LEFT OUTER JOIN Bench4 ON Bench4.bench3Id = Bench3.id
LEFT OUTER JOIN Bench5 ON Bench5.bench4Id = Bench4.id
WHERE Bench1.id IN (27, 315, 429, 371, 126, 104, 3, 176, 376, 128)

Урожайность: 

id  select_type  table   type   possible_keys  key       key_len  ref           rows   filtered  Extra                                               
1   SIMPLE       Bench1  range  PRIMARY        PRIMARY   4                      10     100.00    Using where                                         
1   SIMPLE       Bench2  ref    bench1Id       bench1Id  5        pm.Bench1.id  9      100.00                                                        
1   SIMPLE       Bench3  ref    bench2Id       bench2Id  5        pm.Bench2.id  4      100.00                                                        
1   SIMPLE       Bench4  ref    bench3Id       bench3Id  5        pm.Bench3.id  2      100.00                                                        
1   SIMPLE       Bench5  ALL    bench4Id                                        49860  100.00    Using where; Using join buffer (Block Nested Loop)

Метод 2:

(Я сократил список аргументов IN() для запросов на Bench2 (и на остальных), но результаты EXPLAIN - полных запросов. 

EXPLAIN SELECT SQL_NO_CACHE id, a1, a2, a3 FROM Bench1 WHERE id IN (271, 480, 422, 431, 256, 491, 440, 496, 225, 456);
EXPLAIN SELECT SQL_NO_CACHE id, b1, b2, b3 FROM Bench2 WHERE bench1Id IN (225, 256, 271, 422, 431, 440, 456, 480, 491, 496);
EXPLAIN SELECT SQL_NO_CACHE id, c1, c2, c3 FROM Bench3 WHERE bench2Id IN (323, 402, 1254, 1378, 1965, 2153, 2245, 2518, 2756);
EXPLAIN SELECT SQL_NO_CACHE id, d1, d2, d3 FROM Bench4 WHERE bench3Id IN (3429, 6746, 13014, 18942, 24579, 2269, 6805, 6850);
EXPLAIN SELECT SQL_NO_CACHE id, e1, e2, e3 FROM Bench5 WHERE bench4Id IN (36481, 40044, 11505, 4504, 20798, 4520, 48448, 24305);

Урожайность: 

id  select_type  table   type   possible_keys  key      key_len  ref  rows  filtered  Extra        
1   SIMPLE       Bench1  range  PRIMARY        PRIMARY  4             10    100.00    Using where  
1   SIMPLE       Bench2  range  bench1Id       bench1Id  5             96    100.00    Using index condition  
1   SIMPLE       Bench3  range  bench2Id       bench2Id  5             484   100.00    Using index condition  
1   SIMPLE       Bench4  range  bench3Id       bench3Id  5             966   100.00    Using index condition  
1   SIMPLE       Bench5  ALL   bench4Id                          49860  100.00    Using where

1 Ответ

0 голосов
/ 07 января 2019

В 5.7.4, eq_range_index_dive_limit значение по умолчанию увеличено с 10 (при введении в 5.6.5) до 200. Это влияет на IN ().

Поэкспериментируйте с этим числом по отношению к количеству предметов в IN(list) для Bench5. Я думаю, что вы обнаружите «причину» изменения.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.

Похожие темы

...