Как оптимизировать выборку большого объёма данных?
В одной из таблиц базы данных MySQL имеется большой объём данных (больше 35 000 записей). Запрос всех данных из таблицы занимает значительное время. Есть ли способ быстро получить все данные из данной таблицы?
Explain таблицы:
Сделайте EXPLAIN запроса, посмотрите какие есть индексы, по каким идет выборка, если не хватает - добавьте. Посмотрите какой движок у таблицы, обычно MyIsam быстрее для операций на выборку. (Если речь идет о MySql, но есть ограничения на транзакции и внешние ключи). Ну и почитайте про оптимизацию запросов. Если все вышеперечисленное не помогает, тогда путь в пагинацию и/или кэширование.
Виталий Архипов, Задача состоит в быстром поиске данных. Чтобы при наборе в поисковой строке не пришлось бы ждать вечность. Наберёт к слову пользователь пару букв и ему тут же в теге table отобразятся те записи, в которых какое либо поле совпадает с набранным в поисковой строке значением.
netrox, получается, сейчас пользователь ждёт вечность, пока прогрузится страница со всей таблицей из БД? Что если выбрать по 5-10 записей, которые стартуют с каждой из букв и передать при старте страницы, а когда пользователь начинает писать, отобразить эту начальную подсказку и отправить запрос в БД на получение более конкретизированной выборки с количеством записей на несколько порядков меньше? При 50 тыс записей, если данные селективны, выборка из БД может занимать сильно меньше, чем работа с сетью и рендер тяжёлых страниц.
Задача состоит в быстром поиске данных. Чтобы при наборе в поисковой строке не пришлось бы ждать вечность.
Ваша "оптимизация" на каком-нибудь смарте с ограниченной памятью просто уронит клиенту браузер.
Такие вещи делаются быстрыми запросами по AJAX, а не вытаскиванием всей базы на фронт.
Adamos, Допустим я загрузил часть данных и отобразил полбзователю(время незначилеьное). После ввода в поисковую строку , даже при использовании Ajax-a , php скрипт ведь всё равно должен пройтись по всей базе в поиске введёной строки ,что и повлечёт временные задержки. Поправьте если ошибаюсь
netrox, РНР-скрипт не будет "проходиться по всей базе". Он пошлет один запрос к БД, который будет довольно быстро обработан, если БД нормально настроена.
Зато вы не будете гонять огромные массивы данных между БД и пользователем.
Такая примитивная, но пригодная для понимания базовой оптимизации схема: можно считать, что БД, РНР и браузер работают с бесконечной скоростью. Во всяком случае, в них не обязательно заранее продумывать оптимизацию, только в случае реальных тормозов. А вот соединения между ними - узкие и проблемные (особенно с браузером), и их нужно использовать настолько оптимально, насколько возможно. То есть не гонять лишних данных ни в коем случае. Тем более, что типовой сценарий их работы (а значит, и заложенные в них разработчиками оптимизации) именно на такие приоритеты и рассчитан.
Средний
