Как оптимизировать выборку большого объёма данных?

Question

[netrox]

В одной из таблиц базы данных MySQL имеется большой объём данных (больше 35 000 записей). Запрос всех данных из таблицы занимает значительное время. Есть ли способ быстро получить все данные из данной таблицы?
Explain таблицы:

Comments

[DS28]

Есть.

[Виталий Архипов]

50000 записей - это очень мало. Куда и каким способом вы хотите получить эти данные?

[netrox]

Виталий Архипов, часть отобразить в теге table, а часть скрыть и потом осуществлять поиск с помощью Jquery.

[maiskiykot]

А про AJAX вы что-нибудь слышали? Зачем прятать, если можно выбирать только по необходимости?

[santaatnas]

Сделайте EXPLAIN запроса, посмотрите какие есть индексы, по каким идет выборка, если не хватает - добавьте. Посмотрите какой движок у таблицы, обычно MyIsam быстрее для операций на выборку. (Если речь идет о MySql, но есть ограничения на транзакции и внешние ключи). Ну и почитайте про оптимизацию запросов. Если все вышеперечисленное не помогает, тогда путь в пагинацию и/или кэширование.

[Виталий Архипов]

netrox, опишите исходную задачу, скорее всего, бессмысленно грузить на web-страницу все 50000 записей единовременно.

[netrox]

Виталий Архипов, Задача состоит в быстром поиске данных. Чтобы при наборе в поисковой строке не пришлось бы ждать вечность. Наберёт к слову пользователь пару букв и ему тут же в теге table отобразятся те записи, в которых какое либо поле совпадает с набранным в поисковой строке значением.

[Константин]

netrox, получается, сейчас пользователь ждёт вечность, пока прогрузится страница со всей таблицей из БД? Что если выбрать по 5-10 записей, которые стартуют с каждой из букв и передать при старте страницы, а когда пользователь начинает писать, отобразить эту начальную подсказку и отправить запрос в БД на получение более конкретизированной выборки с количеством записей на несколько порядков меньше? При 50 тыс записей, если данные селективны, выборка из БД может занимать сильно меньше, чем работа с сетью и рендер тяжёлых страниц.

[Adamos]

netrox,

Задача состоит в быстром поиске данных. Чтобы при наборе в поисковой строке не пришлось бы ждать вечность.

Ваша "оптимизация" на каком-нибудь смарте с ограниченной памятью просто уронит клиенту браузер.
Такие вещи делаются быстрыми запросами по AJAX, а не вытаскиванием всей базы на фронт.

[netrox]

Adamos, Допустим я загрузил часть данных и отобразил полбзователю(время незначилеьное). После ввода в поисковую строку , даже при использовании Ajax-a , php скрипт ведь всё равно должен пройтись по всей базе в поиске введёной строки ,что и повлечёт временные задержки. Поправьте если ошибаюсь

[Adamos]

netrox, РНР-скрипт не будет "проходиться по всей базе". Он пошлет один запрос к БД, который будет довольно быстро обработан, если БД нормально настроена.
Зато вы не будете гонять огромные массивы данных между БД и пользователем.

Такая примитивная, но пригодная для понимания базовой оптимизации схема: можно считать, что БД, РНР и браузер работают с бесконечной скоростью. Во всяком случае, в них не обязательно заранее продумывать оптимизацию, только в случае реальных тормозов. А вот соединения между ними - узкие и проблемные (особенно с браузером), и их нужно использовать настолько оптимально, насколько возможно. То есть не гонять лишних данных ни в коем случае. Тем более, что типовой сценарий их работы (а значит, и заложенные в них разработчиками оптимизации) именно на такие приоритеты и рассчитан.

Answer 1

[Everything_is_not_so_bad]

https://datatables.net/

Пример в https://datatables.net/manual/server-side
Параметры start и length определяют как сервер должен получать выборку из СУБД.

Comments

[Глеб Николаев]

Вариант не очень потому что все равно пойдет выборка из всех записей и пагинация только на фронте

[Everything_is_not_so_bad]

Глеб Николаев, откуда такая информация?

[Глеб Николаев]

Роман Мирр, так ведь прямо на сайте есть примеры

[netrox]

Глеб Николаев, Cогласен, не вариант

[Everything_is_not_so_bad]

netrox, Глеб Николаев, обновил ответ.