Как ускорить выборку ( freeing items, cleaning up) из InnoDB по primary key?

Question

[Антон В.]

Добрый день!

Делаю запрос по таблице в которой 100 записей по полю id (PK)

select * from table_name where id = n

и результат 1.8ms - из которых 1ms - это freeing items и cleaning up.
Почему это может происходить, и как можно это ускорить?
Диск ssd nvme; Mysql 8; InnoDB;

Когда необходимо сделать 100 запросов это 100ms, что конкретно чувствуется... нагугить не удалось...

Profile:

Comments

[Everything_is_not_so_bad]

А запросы

select * from table_name where id = n

выполняются один за другим много раз?
А чего не просто where id in (1,2,3)?

[Антон В.]

Роман Мирр, конечно where in используется когда это возможно. но в данном случае данные нужно тянуть из разных таблицы, плюс некоторые структуры нужно рекурсивно распутывать...
но это уже предменая область, меня интересует, возможность настроить так что бы простые запросы на чтение работали быстрее. при том что в данном примере, половина времени уходит на чистку.

[Akina]

из которых 1ms - это freeing items и cleaning up

Вы хоть посмотрели, на что тратится это время, а? а зря... посмотрите - авось и спрашивать не потребуется.

MySQL 8.0 Reference Manual / ... / General Thr...

[Антон В.]

Akina, как понял, очистка памяти... и смотрел в других примерах эти показатели на порядок меньше... (статьи о profile)
freeing items 0.000020
cleaning up 0.000008

[Akina]

Антон В.,
Так всё зависит от того, что процессу нужно загрузить для исполнения и потом восстановить после исполнения. Если время на эти операции ненормально велико по сравнению с другими запросами - да, есть повод о переосмысливании. А если это характерный на текущем сервере уровень - то надо думать о тюнинге системы, а не запроса.

В любом случае подумайте хотя бы для начала - вот правда нужны ВСЕ поля из этой таблицы, а?

[FanatPHP]

Akina, я как-то давно искал ответ на простой вопрос, как переписать SHOW PROFILE на запрос к performance_schema.
К своему удивлению, так и не нашел.
Может быть у вас есть в заначке какой-то вариант?

[Slava Rozhnev]

Я так полагаю, что весь остальной код оптимизирован до предела, тогда да, больше нечего делать, придется переписать движок базы данных.

[FanatPHP]

Slava Rozhnev, не, ну движок-то давно уже переписали, для как раз таких запросов есть handler socket.
Но неужели не интересно, что там происходит такого страшного в этих стадиях?

[Антон В.]

Slava Rozhnev , попробовал обвернуть 590 запросов (read only) в transaction и получил прирост в скорости 50%

без transaction 258.55ms
с transaction 176.83ms

сделал еще пачку тестов, получилось в среднем прирост производительности 20%

Странно немного... Понять бы что происходит.

[FanatPHP]

пальцем в небо, general_log включен?

[Антон В.]

FanatPHP, general_log выключен

Answer 1

[ThunderCat]

Похоже что логичнее хранить ваши данные в каком-то кей-валуе хранилище, в том же редисе, например...

Comments

[Антон В.]

да спасибо, была мысль в редиску горячие данные пересадить... но все же есть надежда на mysql...
вот реально если надо сделать 300 запросов по id и разных таблиц, то ~200-300ms.. ну грустно это, неужели БД не может работать быстрее?

[Антон В.]

+ в данном случае время уходит именно на freeing items, cleaning up... что странно, не пойму как на это можно влиять...

[ThunderCat]

Антон В., не думаю что это вообще можно как-то поправить, это же вроде накладные расходы в системной обработке данных, очистка памяти и подчистка накладного мусора типа временных таблиц...
Мускуль как бы немного про другое - быстрые выборки массивов данных по пересечениям и вот это все, где накладные расходы на системные телодвижения вообще теряются на фоне объема выборки.

[Антон В.]

ThunderCat, благодарю за ответ!

[Антон В.]

Лентюй,

а вы хотя бы понимаете, что это за действия?

если подскажите, буду благодарен

Answer 2

[Антон Антон]

Вроде бы это все происходит уже после возврата данных клиенту, по этому сама обработка будет с точки зрения клиента быстрее. А там и серверов добавить можно, если что.
К тому же в некоторых библиотеках, вроде бы, можно делать выборку из разных таблиц одним запросом (не джоины и даже не юнионы, а именно несколько запросов через ; ).

Еще такое может быть, если лог файлы забиты, медленные диски и т.п.
Попробуй innodb_flush_log_at_trx_commit = 2

если что - во доки: https://dev.mysql.com/doc/refman/8.0/en/general-th...

Comments

[Антон В.]

можно делать выборку из разных таблиц одним запросом

ооо, а это очень интересно, спасибо!

[FanatPHP]

Антон В., а чем это поможет-то?! Я вам такую "библиотеку" на коленке нарисую на 5 минут. Какая разница, склько запросов выполняется за раз, если речь идет об уборке мусора за каждым запросом?
Антон Антон, вот зачем писать всякую чушь, если вы даже близко тему не нюхали? при чем здесь запись? при чем здесь "библиотеки"? При чем здесь ссылка на "доки" в которых ВООБЩЕ ничего внятного не написано пр эти статусы?

[Антон Антон]

FanatPHP,

уборке мусора за каждым запросом?

Ну и пусть себе убирает, управление-то отдано скрипту уже. а то, что таких уборок будет меньше - то позитивно скажется на производительности.

[FanatPHP]

о господи
откуда такое дурачьё-то берется?
С КАКОГО ПЕРЕПУГУ тут какое-то "управление" отдано скрипту, если он СВОИ ДАННЫЕ НЕ ПОЛУЧИЛ?
Вы вообще заметили что тут речь о запросе на выборку, а не на запись?

[Антон В.]

Антон Антон, логи тоже проверю, и на счет innodb_flush_log_at_trx_commit тоже спасибо за подсказку.
Вообще спасибо за полезный ответ! Как глоток свежей воды :) respect !

[FanatPHP]

ещё один клоун.
а это ничего что innodb_flush_log_at_trx_commit влияет только на запись, а вопрос про выборку?
или такие мелочи нас не волнуют, главное "глоточек воды" получить на халяву?

[Антон Антон]

FanatPHP, почему не получил? разве данные отдаются не в районе end и query end?
а про "ничего не пишет" - ну да. но вот буферы всякие выделяет, если транзакции есть - то всякие их счетчики пишет и прочее.

[Антон В.]

FanatPHP,

Параметр innodb_flush_log_at_trx_commit позволяет выбрать стратегию сброса данных на диск при работе MySQL.

Какого рода данные сбрасываются на диск?

[FanatPHP]

потому что надо определиться, или мы отваливаемся после первого запроса, или ждем все-таки пока выполнится последний, чтобы получить от него данные.
а машину времени ещё не изобрели, чтобы получить результат запроса, который еще не выполнился

[FanatPHP]

Антон В., какая разница? главное ведь - это глоток воды получить, а ответы по теме же вас не интересуют

[Антон В.]

FanatPHP, ответ очень интересует, по сравнению с другими комментариями, тут хоть есть темы по которым можно дополнительно почитать.

[FanatPHP]

ну так читайте, кто вам не даёт

[Антон В.]

Антон Антон , попробовал обвернуть 590 запросов (read only) в transaction и получил прирост в скорости 50%

без transaction 258.55ms
с transaction 176.83ms

и расход памяти упал с 14mb до 10mb...

[FanatPHP]

осталось понять, кому нужно приложение, которое делает 590 запросов на показ одной страницы, если даже 59 - это уже многовато.
и что делать с запросами, для которых на самом деле нужна транзакция
и что делать с ошибками измерения, когда "прирост" объясняется совсем другими факторами, а не взятыми с потолка хаотичными телодвижениями.

[Антон В.]

FanatPHP, какое влияние transaction оказывать за read only запросы с точки зрения скорости чтения?

Answer 3

[ky0]

Две миллисекунды вас не устраивают? А почему, позвольте спросить? У вас высоконагруженный проект, в котором выполняются тысячи подобных запросов в секунду или вы просто решили поиграть в преждевременную оптимизацию (с)?

Когда необходимо сделать 100 запросов это 100ms

Для read-only запросов это так не работает - даже если конкретно эти данные не хранятся в памяти, у вас SSD прекрасно может отдавать данные параллельно.

Comments

[Антон В.]

ky0, текущий проект ориентирован на высокие нагрузки, и выходит что 20 запросов к базе по ходу выполнения одного скрипта, занимает ~20ms, есть подозрение что это можно ускорить, но на текущий момент не нашел как это сделать.

Answer 4

[rPman]

where id in (...) работает не быстрее?
ок, залей нужные id в temporary table и делай from table,temp...

Comments

[FanatPHP]

Мне кажется, вы не совсем внимательно прочли вопрос

[Антон В.]

да спасибо, дело в том что у меня местами рекурсивно надо разбирать... можно конечно на этапы разбить, и подгадать что все что можно объединить в where in. просто немного удивился что именно столько времени уходит.
Почему то полагал что запрос на чтение одной строки по pk 0.1-0.01ms при таблице в 10тыс строк...

[FanatPHP]

Ого

Делаю запрос по таблице в которой 100 записей

Вчера было сто, а сегодня уже 10 тыс.
Впечатляющий рост

[rPman]

FanatPHP, да уже увидел, но польза от объединения нескольких запросов в один тоже есть

[Антон В.]

FanatPHP, в одной 100 в другой 10 тыс. \(-_-)/

[Антон В.]

rPman,

польза от объединения нескольких запросов в один тоже есть

да конечно, на данным момент вопрос не про алгоритм выборки, а о том, можно ли настроить базу что бы выборка была шустрее...

[Антон В.]

rPman, понимаете, у меня сомнения, что есть настройки которые могут влиять на скорость выборки,
например если выделить достаточно ОЗУ для базы итд

[Антон В.]

rPman, то есть вопрос

"и результат 1.8ms - из которых 1ms - это freeing items и cleaning up.
Почему это может происходить, и как можно это ускорить?"

вопрос к времени потраченному на выборку одной строки.
Хотя из общих ответов я понял, что походу это нормальное время... и можно играться только с объединением запросов...