MySQL запрос очень медленный при использовании nodejs / mysql2, но быстрый при использовании других клиентов - PullRequest
1 голос
/ 25 февраля 2020

У меня следующий запрос:

SELECT 
    `Job`.`id`, 
    `Job`.`serviceId`, 
    `Job`.`externalId`, 
    `Job`.`createdAt`,
    `Job`.`updatedAt`,
    `logs`.`id` AS `logs.id`,
    `logs`.`statusId` AS `logs.statusId`,
    `logs`.`createdAt` AS `logs.createdAt`
FROM `Jobs` AS `Job` 
LEFT OUTER JOIN (
    SELECT id, jobId, statusId, createdAt, updatedAt
    FROM JobLogs
    WHERE id IN (
        SELECT MAX(id)
        FROM JobLogs
        GROUP BY jobId
    )
) AS `logs` ON `Job`.`id` = `logs`.`jobId`
ORDER BY `Job`.`id` DESC;

Возвращает все Jobs только с самой последней JobLog. Он работает нормально и тестирует его, например, при подключении Sequel Pro к БД, работающей в контейнере, возвращается все 1000 заданий, которые я ранее добавил в + / - 10ms .

Поскольку мой API написан на узле и я использую sequelize / mysql2 под капотом, я только что скопировал вышеупомянутый запрос в sequelize.query() фрагмент (и для целей тестирования пустой фрагмент mysql2-query-snippet с тем же результатом) -> запрос принимает 35se c mysql Процесс остается на 100% ЦП.

Почему запрос намного медленнее при использовании node / mysql2 по сравнению, например, с Sequel Pro? Что мне здесь не хватает?

Это не LIMIT 1000, который добавляет клиент, поскольку в таблице только 1000 записей ...


edit

$ EXPLAIN <SQL> возвращает следующее:

+----+-------------+---------+------------+-------+---------------+---------+---------+-----------+------+----------+--------------------------+
| id | select_type | table   | partitions | type  | possible_keys | key     | key_len | ref       | rows | filtered | Extra                    |
+----+-------------+---------+------------+-------+---------------+---------+---------+-----------+------+----------+--------------------------+
|  1 | PRIMARY     | Job     | NULL       | index | NULL          | PRIMARY | 4       | NULL      | 1000 |   100.00 | NULL                     |
|  1 | PRIMARY     | JobLogs | NULL       | ref   | jobId         | jobId   | 4       | db.Job.id |   13 |   100.00 | Using where              |
|  3 | SUBQUERY    | JobLogs | NULL       | range | jobId         | jobId   | 4       | NULL      | 1000 |   100.00 | Using index for group-by |
+----+-------------+---------+------------+-------+---------------+---------+---------+-----------+------+----------+--------------------------+
3 rows in set, 1 warning (0.00 sec)

И я использую контейнер mysql:5.7.20 docker без какой-либо дополнительной конфигурации, о которой я знаю ...


edit 2

Не похоже, что это кеш. Удаление и воссоздание базы данных, а затем вставка новых (случайных) значений, а затем выполнение первого запроса с помощью Sequel Pro приводит к ответу ~ 30 мс.

...