Как ускорить выборку ( freeing items, cleaning up) из InnoDB по primary key?
Добрый день!
Делаю запрос по таблице в которой 100 записей по полю id (PK)
select * from table_name where id = n
и результат 1.8ms - из которых 1ms - это freeing items и cleaning up.
Почему это может происходить, и как можно это ускорить?
Диск ssd nvme; Mysql 8; InnoDB;
Когда необходимо сделать 100 запросов это 100ms, что конкретно чувствуется... нагугить не удалось...
Роман Мирр, конечно where in используется когда это возможно. но в данном случае данные нужно тянуть из разных таблицы, плюс некоторые структуры нужно рекурсивно распутывать...
но это уже предменая область, меня интересует, возможность настроить так что бы простые запросы на чтение работали быстрее. при том что в данном примере, половина времени уходит на чистку.
Akina, как понял, очистка памяти... и смотрел в других примерах эти показатели на порядок меньше... (статьи о profile)
freeing items 0.000020
cleaning up 0.000008
Антон В.,
Так всё зависит от того, что процессу нужно загрузить для исполнения и потом восстановить после исполнения. Если время на эти операции ненормально велико по сравнению с другими запросами - да, есть повод о переосмысливании. А если это характерный на текущем сервере уровень - то надо думать о тюнинге системы, а не запроса.
В любом случае подумайте хотя бы для начала - вот правда нужны ВСЕ поля из этой таблицы, а?
Akina, я как-то давно искал ответ на простой вопрос, как переписать SHOW PROFILE на запрос к performance_schema.
К своему удивлению, так и не нашел.
Может быть у вас есть в заначке какой-то вариант?
Slava Rozhnev, не, ну движок-то давно уже переписали, для как раз таких запросов есть handler socket.
Но неужели не интересно, что там происходит такого страшного в этих стадиях?
да спасибо, была мысль в редиску горячие данные пересадить... но все же есть надежда на mysql...
вот реально если надо сделать 300 запросов по id и разных таблиц, то ~200-300ms.. ну грустно это, неужели БД не может работать быстрее?
Антон В., не думаю что это вообще можно как-то поправить, это же вроде накладные расходы в системной обработке данных, очистка памяти и подчистка накладного мусора типа временных таблиц...
Мускуль как бы немного про другое - быстрые выборки массивов данных по пересечениям и вот это все, где накладные расходы на системные телодвижения вообще теряются на фоне объема выборки.
Вроде бы это все происходит уже после возврата данных клиенту, по этому сама обработка будет с точки зрения клиента быстрее. А там и серверов добавить можно, если что.
К тому же в некоторых библиотеках, вроде бы, можно делать выборку из разных таблиц одним запросом (не джоины и даже не юнионы, а именно несколько запросов через ; ).
Еще такое может быть, если лог файлы забиты, медленные диски и т.п.
Попробуй innodb_flush_log_at_trx_commit = 2
Антон В., а чем это поможет-то?! Я вам такую "библиотеку" на коленке нарисую на 5 минут. Какая разница, склько запросов выполняется за раз, если речь идет об уборке мусора за каждым запросом? Антон Антон, вот зачем писать всякую чушь, если вы даже близко тему не нюхали? при чем здесь запись? при чем здесь "библиотеки"? При чем здесь ссылка на "доки" в которых ВООБЩЕ ничего внятного не написано пр эти статусы?
о господи
откуда такое дурачьё-то берется?
С КАКОГО ПЕРЕПУГУ тут какое-то "управление" отдано скрипту, если он СВОИ ДАННЫЕ НЕ ПОЛУЧИЛ?
Вы вообще заметили что тут речь о запросе на выборку, а не на запись?
Антон Антон, логи тоже проверю, и на счет innodb_flush_log_at_trx_commit тоже спасибо за подсказку.
Вообще спасибо за полезный ответ! Как глоток свежей воды :) respect !
ещё один клоун.
а это ничего что innodb_flush_log_at_trx_commit влияет только на запись, а вопрос про выборку?
или такие мелочи нас не волнуют, главное "глоточек воды" получить на халяву?
FanatPHP, почему не получил? разве данные отдаются не в районе end и query end?
а про "ничего не пишет" - ну да. но вот буферы всякие выделяет, если транзакции есть - то всякие их счетчики пишет и прочее.
потому что надо определиться, или мы отваливаемся после первого запроса, или ждем все-таки пока выполнится последний, чтобы получить от него данные.
а машину времени ещё не изобрели, чтобы получить результат запроса, который еще не выполнился
осталось понять, кому нужно приложение, которое делает 590 запросов на показ одной страницы, если даже 59 - это уже многовато.
и что делать с запросами, для которых на самом деле нужна транзакция
и что делать с ошибками измерения, когда "прирост" объясняется совсем другими факторами, а не взятыми с потолка хаотичными телодвижениями.
Две миллисекунды вас не устраивают? А почему, позвольте спросить? У вас высоконагруженный проект, в котором выполняются тысячи подобных запросов в секунду или вы просто решили поиграть в преждевременную оптимизацию (с)?
Когда необходимо сделать 100 запросов это 100ms
Для read-only запросов это так не работает - даже если конкретно эти данные не хранятся в памяти, у вас SSD прекрасно может отдавать данные параллельно.
ky0, текущий проект ориентирован на высокие нагрузки, и выходит что 20 запросов к базе по ходу выполнения одного скрипта, занимает ~20ms, есть подозрение что это можно ускорить, но на текущий момент не нашел как это сделать.
да спасибо, дело в том что у меня местами рекурсивно надо разбирать... можно конечно на этапы разбить, и подгадать что все что можно объединить в where in. просто немного удивился что именно столько времени уходит.
Почему то полагал что запрос на чтение одной строки по pk 0.1-0.01ms при таблице в 10тыс строк...
"и результат 1.8ms - из которых 1ms - это freeing items и cleaning up.
Почему это может происходить, и как можно это ускорить?"
вопрос к времени потраченному на выборку одной строки.
Хотя из общих ответов я понял, что походу это нормальное время... и можно играться только с объединением запросов...
Простой
