Асинхронные запросы к MySQL

[@Indexator]

В случае синхронного выполнения запросов, Вы сможете получить результаты их выполнения через t1 + t2 + t3 (ex: 6 секунд), а в случае асинхронного выполнения запросов уже за max(t1, t2, t3) (ex: 3 секунды)

Конечно, т.к. в приведенном случае они (запросы) ничего не делают. А для реально выполняющихся запросов понадобится все 6 секунд плюс время на переключения потоков (в случае, если у нас одно ядро)…

[@aeryaguzov]

Ох уж эта Ваша реальность:-)

Согласен с тем, что пример не реален, а идеален. Но считаю, что именно от этого надо плясать, поэтому и придумал именно такой пример. Насчет цифр — есть пример на гибхабе, туда вставляйте свой запрос и смотрите, для каждого цифры будут разные, например, у меня асинхронный вариант, все равно(но не всегда) выполняется немного быстрее

[@Illorian]

Т.е я могу во время загрузки страницы кинуть AJAX-запрос и асинхронно сделать асинхронные запросы и всё будет супер быстро?

Как я понял, они буду выполняться одновременно, а не последовательно?

[@aeryaguzov]

В целом такой вариант использования скорее анти-паттерн и использовать этот функционал таким образом — нехорошо, потому что надо дождаться результата выполнения запроса, а не оставлять его на произвол судьбы. Однако основная мысль именно такая: если в скрипте присутствует только выполнение запроса, то да, все будет очень быстро, но потом новый запрос в том же соединении не заработает(Commands out of sync) пока не будут получены результаты текущего, то есть надо будет сотворить что-то в стиле: выполнил запрос асинхронно, закрыл соединение. Остается вопрос: что будет если закрыть соединение у выполняющегося асинхронно апдейта например? Думаю, что ничего хорошего, а оставлять соединение открытым вообще плохо.

Если Вы про пример, то одновременно, так как разные соединения.

[@nick4fake]

для этого не нужен mysqlnd

[@ngreduce]

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

[@nick4fake]

Это… странный способ. Если запрос тяжелый, можно кешироватью

[@Aiii]

Рабочие примеры есть?

[@seriyPS]

Учитывая то, что оно требует отдельное подключение к MySQL для каждого параллельно выполняющегося запроса вместо пайплайнинга, выглядит абсолютно бесполезно в 99% случаев.
Может пригодиться только если вы пишете на PHP демонов и держите пул подключений.

[@youROCK]

Подключение к MySQL выполняется весьма быстро, порядка 1 мс, но для обычной веб-страницы это всё равно изврат, конечно :)).

[@warsoul]

Есть у вас импорт например… Построчный… Лучше же делать в 20 потоков чем в 1, не?

[@DmitriyEntelis]

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

[@warsoul]

А на примере PDO показать не лучше было? Или поддержка только в mysqli?

[@aeryaguzov]

При использовании mysqlnd доп. функции появляются только в mysqli

[@warsoul]

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

[@youROCK]

Я бы сказал наоборот, уж слишком много фич из mysqli в PDO нет…