Реализация разбиения результатов поиска в MySQL

Question

Реализация разбиения результатов поиска в MySQL

0

Это должно быть довольно распространенной проблемой. Я не смог найти решение в базе данных вопросов по stackoverflow. Я не уверен, что сделал правильный поиск.

Я запускаю сайт MySQL, CGI/Perl. Может быть 1000 хитов в день. Пользователь может выполнить поиск в базе данных для веб-сайта. Предложение where может стать довольно продолжительным. Я показываю 10 элементов на странице и даю ссылки на пользователя для перехода на следующую и предыдущие страницы. В настоящее время я делаю новый поиск, каждый раз, когда пользователь нажимает ссылку "prev" или "next". Я использую

LIMIT num-rows-to-fetch OFFSET num-rows-to-skip

вместе с запросом. Однако время ответа слишком много для последующих поисков. Это может только ухудшиться, так как я добавляю больше пользователей. Я пытаюсь понять, могу ли я реализовать это лучше.

Если вы можете дать мне несколько указателей, я был бы очень признателен.

rpat 21 фев. 2011, в 16:50

Источник

Теги:

mysql

perl

3 ответа

Ещё вопросы

Francisco R · Answer 1 · 2011-02-21T14-14-00.000Z

Если вы не против использования Javascript, вы должны проверить DataTables. Таким образом вы отправляете все строки клиенту, а разбиение на страницы выполняется на стороне клиента.

Если это не вариант, вы можете попробовать использовать mod_perl или CGI:: Session, чтобы сохранить результат запроса между запросами страниц, поэтому вам не нужно будет снова и снова запрашивать mysql.

Результирующий набор может содержать пару тысяч строк и включать изображения, поэтому я не уверен, как это будет работать с DataTables. Я посмотрю на все, что вы предложили. Спасибо

Hartmut Behrens · Answer 2 · 2011-02-23T05-51-00.000Z

Я никогда не использовал этот модуль, поэтому не могу поручиться за его производительность, но посмотрим DBI:: ResultPager

Позвольте мне взглянуть на это. Спасибо

Dirk Trilsbeek · Answer 3 · 2011-02-21T13-17-00.000Z

вы можете попробовать проанализировать запрос, чтобы узнать, какая часть вызывает наибольшую проблему для базы данных. Если есть объединения, вы можете создавать индексы, которые включают как поля ключа, так и возможные поля фильтра, используемые в запросе. Но это может в зависимости от формата и размера базы данных создавать множество индексов. И если запрос может значительно измениться, вы все равно можете быть в недоумении, если вы не создали индекс для конкретного случая. В любом случае я бы сначала проанализировал запрос, пытаясь выяснить, что делает запрос настолько медленным. Если есть одна серьезная причина плохой производительности, вы можете попробовать бросить на нее индексы.

Другим способом было бы кэшировать результаты поиска в памяти и делать разбивку на страницы, избегая при этом обращения к базе данных вообще. В зависимости от размера вашей базы данных вы можете ограничить результаты поиска разумным числом.

Попробуйте EXPLAIN SELECT... и посмотрите, что так долго. Убедитесь, что соответствующие столбцы проиндексированы.
Есть 2 части, чтобы улучшить это. Во-первых, улучшить сам запрос. Я смотрел на это и все еще смотрю на улучшение этого. Вторая часть действительно, где я нуждался в разъяснении. Должен ли я делать новый запрос каждый раз или я должен кэшировать результаты. Если я смогу кешировать результаты, это сэкономит мне кучу запросов.