Есть большая MySQL база с множеством таблиц и в каждой таблице до 10 млн. записей ($bd). Некоторые SQL($sql) запросы отрабатывается по несколько минут. Получаем некий результат: $ result = mysqli_query ($bd, $sql). В отдельном файле организуется вывод данных ($ result) в таблицу htmlв цикле: while ($myrow= mysqli_fetch_assoc ($result)) {…} Получается тысячи строк. Задача: организовать вывод величины $ result с разбиением постранично, типа: 1 2 3 4 5 6 7 8 ... > ОДНАКО: НЕЛЬЗЯ ИСПОЛЬЗОВАТЬ В ПОСТРАНИЧНОМ ВЫВОДЕ SQLЗАПРОСЫ К БАЗЕ ДАННЫХ, ТАК КАК КАЖДЫЙ ЗАПРОС И ЛЮБОЙ LIMITБУДЕТУТ ОТНИМАТЬ БОЛЬШОЕ ВРЕМЯ. Иными словами: запрос SQL($sql) должен случаться 1 раз, а результат этого запроса ($ result) должен разбиваться и выводиться в многостраничном формате.
Есть большая MySQL база с множеством таблиц и в каждой таблице до 10 млн. записей ($bd). Некоторые SQL($sql) запросы отрабатывается по несколько минут. Получаем некий результат: $ result = mysqli_query ($bd, $sql). В отдельном файле организуется вывод данных ($ result) в таблицу htmlв цикле: while ($myrow= mysqli_fetch_assoc ($result)) {…} Получается тысячи строк. Задача: организовать вывод величины $ result с разбиением постранично, типа: 1 2 3 4 5 6 7 8 ... > ОДНАКО: НЕЛЬЗЯ ИСПОЛЬЗОВАТЬ В ПОСТРАНИЧНОМ ВЫВОДЕ SQLЗАПРОСЫ К БАЗЕ ДАННЫХ, ТАК КАК КАЖДЫЙ ЗАПРОС И ЛЮБОЙ LIMITБУДЕТУТ ОТНИМАТЬ БОЛЬШОЕ ВРЕМЯ. Иными словами: запрос SQL($sql) должен случаться 1 раз, а результат этого запроса ($ result) должен разбиваться и выводиться в многостраничном формате.
Нужно кэшировать результаты, можно всю страницу или только запрос, можно в memcached, redis или в файл как PHP массив
Кстати(!), а генератор разве не помогут в этой ситуации? https://php.ru/manual/language.generators.syntax.html
Стоит сначала проверить/исследовать оптимальность существующего решения. После чего принимать обдуманное решение для каждой конкретной ситуации. Просто брать и все, что медленно работает загонять в кэш - это кривая дорожка, способная привести к печальным последствиям. В один прекрасный день произойдет перезагрузка сервера и он попросту не сможет подняться, т-к разогрев кэша потребует значительных ресурсов, превышающие существующие.
@bluser нету. Можешь просто в фоновом режиме, например через cron, для каждой страницы, данные из mysql сложить в PHP файл как массив, var_export($array, true), потом вместо того чтобы ждать выполнения запроса к базе, просто бери данные из массива который в PHP файле. array1.php PHP: <?php return [ 'test' => 'hello', ]; test.php PHP: <?php $data = include 'page1.php'; echo $data['test']; --- Добавлено --- @t1grok да, хорошее замечание
Проблема в том, что на такие вещи нет серебряной пули. К примеру кэширование может быть дороже, если таблица часто меняется, если же нет, то возможно будет лучшим вариантом индексы с условиями или вообще, секционирование (хотя хз, умеет ли такое мускуль). Возможно стоит строить запрос по одной таблице, а остальные данные добирать по id доп. запросами. Может быть бд стоит денормализовать, что бы уменьшить количество join`ов в запросе. Короче, вариантов много, но конкретики ни кто не даст, т.к. все данные есть лишь у тебя. Говори конкретные кейсы, может чего и придумаем )
Вангую, что с индексами полная беда. Ну и да, автор, код запроса, который несколько минут выполняется, в студию.
Можно выводить на страницу сразу все тысячи результатов, а на страницы разделить с помощью js: http://flaviusmatis.github.io/simplePagination.js/ Браузеры стали быстрыми, компьютеры мощными.
С мобилки еще лучше подгрузить сразу большой кусок, потому что классический переход между страницами может занимать несколько секунд вне зависимости от выполнения скрипта. Если данные пихать в JSON, то хотя бы в 100кб gzip-а можно уместить десятки тысяч итемов.
Я не трафик сейчас имел ввиду, а "компьютеры мощные, браузеры быстрые". Намекнул, что кроме мощных компьютеров с быстрыми браузерами есть клиенты, которым толстая логика с десятками тысяч итемов поперек горла стоит.
да забейте. давайте подождём загадочный запрос, структуру бд и индексы. А потом будет от чего отталкиваться.