URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID8
Нить номер: 5426
[ Назад ]
Исходное сообщение
"Как ускорить подсчет кол-ва записей в выборке?"
Отправлено Urms , 18-Дек-07 15:18 
Возникла следующая проблема. Есть база данных MySQL с очень большим количеством записей. На сайте организован постраничный вывод данных, есть поиск, т.е. кол-во страниц может быть разное. Беда в том, что подсчет количества страниц работает очень медленно -- несколько секунд, а количество данных будет еще во много раз больше.

Каким образом можно решить данную проблему? Каким образом некоторые поисковые системы показывают приблизительное количество страниц?

Содержание
Сообщения в этом обсуждении
"Как ускорить подсчет кол-ва записей в выборке?"
Отправлено newser , 18-Дек-07 15:50 
>Возникла следующая проблема. Есть база данных MySQL с очень большим количеством записей.
>На сайте организован постраничный вывод данных, есть поиск, т.е. кол-во страниц
>может быть разное. Беда в том, что подсчет количества страниц работает
>очень медленно -- несколько секунд, а количество данных будет еще во
>много раз больше.
>
>Каким образом можно решить данную проблему? Каким образом некоторые поисковые системы показывают
>приблизительное количество страниц?

Может, пришло время пересмотреть структуру самой базы? ;)

"Как ускорить подсчет кол-ва записей в выборке?"
Отправлено Urms , 18-Дек-07 15:54 
>>Возникла следующая проблема. Есть база данных MySQL с очень большим количеством записей.
>>На сайте организован постраничный вывод данных, есть поиск, т.е. кол-во страниц
>>может быть разное. Беда в том, что подсчет количества страниц работает
>>очень медленно -- несколько секунд, а количество данных будет еще во
>>много раз больше.
>>
>>Каким образом можно решить данную проблему? Каким образом некоторые поисковые системы показывают
>>приблизительное количество страниц?
>
>Может, пришло время пересмотреть структуру самой базы? ;)

Спасибо конечно за полезный совет, но к делу он не относится. Там всего одна таблица.

"Как ускорить подсчет кол-ва записей в выборке?"
Отправлено anonymous , 04-Янв-08 05:55 
>>Может, пришло время пересмотреть структуру самой базы? ;)
>
>Спасибо конечно за полезный совет, но к делу он не относится. Там
>всего одна таблица.

Человек дело говорит.  Нормализация -- наше всё.  А вообще, лучше покажите структуру базы.

"Как ускорить подсчет кол-ва записей в выборке?"
Отправлено konst , 18-Дек-07 18:35 
>Возникла следующая проблема. Есть база данных MySQL с очень большим количеством записей.
>На сайте организован постраничный вывод данных, есть поиск, т.е. кол-во страниц
>может быть разное. Беда в том, что подсчет количества страниц работает
>очень медленно -- несколько секунд, а количество данных будет еще во
>много раз больше.
>
>Каким образом можно решить данную проблему? Каким образом некоторые поисковые системы показывают
>приблизительное количество страниц?

count (*) долго работает? А таблица с индексами?

"Как ускорить подсчет кол-ва записей в выборке?"
Отправлено Urms , 18-Дек-07 18:40 
>>Возникла следующая проблема. Есть база данных MySQL с очень большим количеством записей.
>>На сайте организован постраничный вывод данных, есть поиск, т.е. кол-во страниц
>>может быть разное. Беда в том, что подсчет количества страниц работает
>>очень медленно -- несколько секунд, а количество данных будет еще во
>>много раз больше.
>>
>>Каким образом можно решить данную проблему? Каким образом некоторые поисковые системы показывают
>>приблизительное количество страниц?
>
>count (*) долго работает? А таблица с индексами?

Конечно таблица с индексами, но в ней сотни тысяч записей

"Как ускорить подсчет кол-ва записей в выборке?"
Отправлено konst , 18-Дек-07 19:59 
>[оверквотинг удален]
>>>может быть разное. Беда в том, что подсчет количества страниц работает
>>>очень медленно -- несколько секунд, а количество данных будет еще во
>>>много раз больше.
>>>
>>>Каким образом можно решить данную проблему? Каким образом некоторые поисковые системы показывают
>>>приблизительное количество страниц?
>>
>>count (*) долго работает? А таблица с индексами?
>
>Конечно таблица с индексами, но в ней сотни тысяч записей

Если Вам нужно подсчитать кол-во записей в табл. Вы используете, напр: select count(id) from...
И этот запрос у Вас тормозит?
В любом случае полезная ссылка:
http://xpoint.ru/know-how/MySQL/Optimizatsiya/Indeksyi

analyze table <table_name>
optimize table <table_name>

"Как ускорить подсчет кол-ва записей в выборке?"
Отправлено angra , 18-Дек-07 21:59 
>И этот запрос у Вас тормозит?

Легко. Вы забываете про секцию where. Чистый "select count(*) from tablename" конечно отрабатывает мгновенно, но добавьте ему сложный where(а именно это упоминалось автором вопроса) и время его выполнения не будет сильно отличаться от выборки самих записей с этим же условием.

"Как ускорить подсчет кол-ва записей в выборке?"
Отправлено Urms , 18-Дек-07 22:14 
>>И этот запрос у Вас тормозит?
>
>Легко. Вы забываете про секцию where. Чистый "select count(*) from tablename" конечно
>отрабатывает мгновенно, но добавьте ему сложный where(а именно это упоминалось автором
>вопроса) и время его выполнения не будет сильно отличаться от выборки
>самих записей с этим же условием.

Именно, виноваты во всем дополнительные условия. К слову, его время отличается от выборки сильно, с учетом того, что выборка делается для одной страницы с LIMIT, время подсчета примерно раз в 300 больше времени выборки.

"Как ускорить подсчет кол-ва записей в выборке?"
Отправлено konst , 18-Дек-07 23:01 
>[оверквотинг удален]
>>
>>Легко. Вы забываете про секцию where. Чистый "select count(*) from tablename" конечно
>>отрабатывает мгновенно, но добавьте ему сложный where(а именно это упоминалось автором
>>вопроса) и время его выполнения не будет сильно отличаться от выборки
>>самих записей с этим же условием.
>
>Именно, виноваты во всем дополнительные условия. К слову, его время отличается от
>выборки сильно, с учетом того, что выборка делается для одной страницы
>с LIMIT, время подсчета примерно раз в 300 больше времени выборки.
>

Честно говоря с mysql особо не работал, но в postgres, oracle оптимизация играет большую роль (напр. analyze <запрос> в oracle повышает производительность в разы, то же - vacuum analyze в postgres). Кроме того большую роль играют индексы. Проиндексируйте те поля по которым производится выборка (where) ). Короче, выше я дал ссылку... А так - на Ваш subj можно ответить: правильная БД (с ПРАВИЛЬНЫМИ индексами) + средства оптимизации

"Как ускорить подсчет кол-ва записей в выборке?"
Отправлено konst , 18-Дек-07 23:03 
>[оверквотинг удален]
>>>отрабатывает мгновенно, но добавьте ему сложный where(а именно это упоминалось автором
>>>вопроса) и время его выполнения не будет сильно отличаться от выборки
>>>самих записей с этим же условием.
>>
>>Именно, виноваты во всем дополнительные условия. К слову, его время отличается от
>>выборки сильно, с учетом того, что выборка делается для одной страницы
>>с LIMIT, время подсчета примерно раз в 300 больше времени выборки.
>>
>
>Честно говоря с mysql особо не работал, но в postgres, oracle оптимизация играет большую роль (напр. analyze <запрос> в oracle повышает производительность в разы, то же - vacuum analyze в postgres). Кроме того большую роль играют индексы. Проиндексируйте те поля по которым производится выборка (where) ). Короче, выше я дал ссылку... А так - на Ваш subj можно ответить: правильная БД (с ПРАВИЛЬНЫМИ индексами) + средства оптимизации

+ могли бы explain table_name показать + пример тормозного запроса...

"Как ускорить подсчет кол-ва записей в выборке?"
Отправлено Urms , 18-Дек-07 23:15 
>[оверквотинг удален]
>>>>самих записей с этим же условием.
>>>
>>>Именно, виноваты во всем дополнительные условия. К слову, его время отличается от
>>>выборки сильно, с учетом того, что выборка делается для одной страницы
>>>с LIMIT, время подсчета примерно раз в 300 больше времени выборки.
>>>
>>
>>Честно говоря с mysql особо не работал, но в postgres, oracle оптимизация играет большую роль (напр. analyze <запрос> в oracle повышает производительность в разы, то же - vacuum analyze в postgres). Кроме того большую роль играют индексы. Проиндексируйте те поля по которым производится выборка (where) ). Короче, выше я дал ссылку... А так - на Ваш subj можно ответить: правильная БД (с ПРАВИЛЬНЫМИ индексами) + средства оптимизации
>
>+ могли бы explain table_name показать + пример тормозного запроса...

Индексы сделал и условия правильно расставил (в нужном порядке), но все равно не достаточно быстро. У меня родилась идея ограничить максимальное кол-во и писать на сайте, что записей больше, чем, скажем, 50000... вместо точного подсчета. Возникает новый вопрос, как совместить LIMIT и count, т.е. естественно, что выборка с LIMIT работает быстро, если лимит относительно небольшой, но если в запросе есть count, то LIMIT игнорируется

"Как ускорить подсчет кол-ва записей в выборке?"
Отправлено konst , 19-Дек-07 00:51 
>[оверквотинг удален]
>>>Честно говоря с mysql особо не работал, но в postgres, oracle оптимизация играет большую роль (напр. analyze <запрос> в oracle повышает производительность в разы, то же - vacuum analyze в postgres). Кроме того большую роль играют индексы. Проиндексируйте те поля по которым производится выборка (where) ). Короче, выше я дал ссылку... А так - на Ваш subj можно ответить: правильная БД (с ПРАВИЛЬНЫМИ индексами) + средства оптимизации
>>
>>+ могли бы explain table_name показать + пример тормозного запроса...
>
>Индексы сделал и условия правильно расставил (в нужном порядке), но все равно
>не достаточно быстро. У меня родилась идея ограничить максимальное кол-во и
>писать на сайте, что записей больше, чем, скажем, 50000... вместо точного
>подсчета. Возникает новый вопрос, как совместить LIMIT и count, т.е. естественно,
>что выборка с LIMIT работает быстро, если лимит относительно небольшой, но
>если в запросе есть count, то LIMIT игнорируется

1. если в запросе есть сортировка - то LIMIT все равно не поможет.
2. если Вы предпочитаете общаться с телепатами, то можно использовать телепатическую связь, а не тратить время на написание сообщений, подобных этому: "Ребята, у меня все сделано хорошо и правильно, но только почему-то плохо работает. Почему?"
3. Если, наконец, будете готовы сообщить о чем идет речь, то
3.1. тех. хар-ки сервера
3.2. описание таблицы и ключей
3.3. пример запросов, которые "медленно работают"
3.4. О каком типе www-приложении идет речь (чтобы было ясно, как часто обновляются таблицы и т.п.
3.5. Что было сделано для улучшения, и к чему это привело (желательно, использовать циферки для оценки)

"Как ускорить подсчет кол-ва записей в выборке?"
Отправлено angra , 18-Дек-07 21:32 
Если я не ошибаюсь в mysql можно получить количество записей вернутых предыдущим запросом (а точнее она равносильна выполнению count(*) с секцией where предыдущего запроса, но значительно быстрее). Как именно называется эта функция не помню, посмотрите в справочнике.
"Как ускорить подсчет кол-ва записей в выборке?"
Отправлено Urms , 18-Дек-07 22:11 
>Если я не ошибаюсь в mysql можно получить количество записей вернутых предыдущим
>запросом (а точнее она равносильна выполнению count(*) с секцией where предыдущего
>запроса, но значительно быстрее). Как именно называется эта функция не помню,
>посмотрите в справочнике.

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

"Как ускорить подсчет кол-ва записей в выборке?"
Отправлено Mighty , 27-Дек-07 15:59 
>>Если я не ошибаюсь в mysql можно получить количество записей вернутых предыдущим
>>запросом (а точнее она равносильна выполнению count(*) с секцией where предыдущего
>>запроса, но значительно быстрее). Как именно называется эта функция не помню,
>>посмотрите в справочнике.
>
>Есть опция SQL_CALC_FOUND_ROWS для запроса с выборкой, для того, чтобы сразу подсчитать
>и кол-во, после этого можно достать кол-во с помощью функции FOUND_ROWS().
>Наверное, вы об этом. Я пробовал такой подход, почему-то получается еще
>медленнее, чем сделать отельно выборку с лимитом, а потом сделать подсчет.
>

а как насчёт того,чтобы использовать mysqli класс
работает, как мне кажется, побыстрее

"Как ускорить подсчет кол-ва записей в выборке?"
Отправлено angra , 30-Дек-07 07:35 
>а как насчёт того,чтобы использовать mysqli класс
>работает, как мне кажется, побыстрее

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

"Как ускорить подсчет кол-ва записей в выборке?"
Отправлено BigHarry , 07-Янв-08 13:13 
>Я пробовал такой подход, почему-то получается еще
>медленнее, чем сделать отельно выборку с лимитом, а потом сделать подсчет.

С чего это вдруг запрос с SQL_CALC_FOUND_ROWS медленнее?
Просто с этой конструкцией сервер запоминает количество строк в специальной переменной, результат которой можно поглядеть через SELECT FOUND_ROWS()

"Как ускорить подсчет кол-ва записей в выборке?"
Отправлено Urms , 07-Янв-08 13:28 
>>Я пробовал такой подход, почему-то получается еще
>>медленнее, чем сделать отельно выборку с лимитом, а потом сделать подсчет.
>
>С чего это вдруг запрос с SQL_CALC_FOUND_ROWS медленнее?
>Просто с этой конструкцией сервер запоминает количество строк в специальной переменной, результат
>которой можно поглядеть через SELECT FOUND_ROWS()

Не совсем так.Если есть LIMIT и нет сортировки, заставляющей вытаскивать все результаты, удовлетворяющие данному условию, то сервер выводит только то количество строк, которое указано в

"Как ускорить подсчет кол-ва записей в выборке?"
Отправлено Urms , 07-Янв-08 13:31 
>>Я пробовал такой подход, почему-то получается еще
>>медленнее, чем сделать отельно выборку с лимитом, а потом сделать подсчет.
>
>С чего это вдруг запрос с SQL_CALC_FOUND_ROWS медленнее?
>Просто с этой конструкцией сервер запоминает количество строк в специальной переменной, результат
>которой можно поглядеть через SELECT FOUND_ROWS()

Не совсем так.Если есть LIMIT и нет сортировки, заставляющей вытаскивать все результаты, удовлетворяющие данному условию, то сервер выводит только то количество строк, которое указано в LIMIT, а при опции SQL_CALC_FOUND_ROWS он всегда вытаскивает все результаты для подсчета их количества.

"Как ускорить подсчет кол-ва записей в выборке?"
Отправлено BigHarry , 07-Янв-08 14:03 
>Не совсем так.Если есть LIMIT и нет сортировки, заставляющей вытаскивать все результаты,
>удовлетворяющие данному условию, то сервер выводит только то количество строк, которое
>указано в LIMIT, а при опции SQL_CALC_FOUND_ROWS он всегда вытаскивает все
>результаты для подсчета их количества.

Дык LIMIT нужен что бы тянуть только данные для вывода на одной странице, а не все сразу.
А FOUND_ROWS() вернет общее количество строк, что бы моно было подсчитать количество страниц.
Опция SQL_CALC_FOUND_ROWS правильно отрабатывает - она учитывает условия в WHERE, но не учитывает LIMIT.


"Как ускорить подсчет кол-ва записей в выборке?"
Отправлено Fisher , 30-Дек-07 20:44 
>Возникла следующая проблема. Есть база данных MySQL с очень большим количеством записей.
>На сайте организован постраничный вывод данных, есть поиск, т.е. кол-во страниц
>может быть разное. Беда в том, что подсчет количества страниц работает
>очень медленно -- несколько секунд, а количество данных будет еще во
>много раз больше.
>
>Каким образом можно решить данную проблему? Каким образом некоторые поисковые системы показывают
>приблизительное количество страниц?

Попробуй измерить продолжительность выполения запроса. Это можно сделать так:

$time_portions = explode(' ',microtime());
$start_time = $time_portions[1].substr($time_portions[0],1);

<Здесь запрос SELECT>

$time_portions = explode(' ',microtime());
$end_time = $time_portions[1].substr($time_portions[0],1);

$elapsect_time = bcsub($end_time,$start_time,6);
echo($elapsect_time);  //Результат в секундах

Для выполнения этого сценария расширение bcmath надо скомпилировать с
РНР с помощью параметра --enable-bc-math.