Суть проблемы такова: есть сайт, на котором крутится база. В базе десяток таблиц со сложной структурой связи "один к одному". Связь осуществляется стандартно, через ID.
На одной из страниц используется сложный запрос для выборки всех элементов, совпадающих с тем, имеющих то-то и то-то. Короче, в запросе используется четыре left join по четырем различным таблицам + пятая таблица как первоначальная сложное условие и group by по двум полям. Две из пяти таблиц имеют несколько десятков тысяч записей. Естественно, что результаты выводятся постранично, и на каждой странице мне необходимо знать общее количество получаемых строк, прежде чем выбрать нужные значения и еще показать меню с переходом на другие страницы. Работает суммирование относительно медленно, даже на докалном серваке с иксами. Понятно,Ючто на хостинге на одного клиента будет приходится еще больше тормозов.
Так запрос вида

Код

select SQL_CACHE count(*) from subservice  left join bank_service on bank_service.subservice_id=subservice.id left join bank_office on bank_office.id=bank_service.office_id  left join city on city.id=bank_office.city_id left join bank on bank.id=bank_office.bank_id where subservice.service_id=51 and bank_office.bank_id=6442 ;

для результута в двадцать тысяч строк обрабатывается первый раз порядка трех секунд.

Если бы я мог предварительно оценить, что результат содержит очень большое кол-во строк, то вместо их постраничного представления я могу заставить пользоватля ужесточить сузить критерии поиска. Но для этого мне необходимо знать, что кол-во строк будет превышать некоторую пороговую величину.
Отсюда вопрос: можно ли модифицировать приведенный запрос так, чтоб сервер БД не выполнял подсчет всех строк, а только указал, что они превышают некоторую величину.
Пока что ситуация получается следующая: гораздо легче выбрать скажем первые тысячу строк вот так:

Код

select bank_office.id from subservice left join bank_service on bank_service.subservice_id=subservice.id  left join bank_office on bank_office.id=bank_service.office_id left join city on city.id=bank_office.city_id  left join bank on bank.id=bank_office.bank_id  where subservice.service_id=51 and bank_office.bank_id=6442 limit 1000;

Результат - выборка из 1000 строк выполняется всего за 0.23 секунды. Т.е, я знаю, что как минимум тысяча строк результата у меня есть. Но, если задуматься - выход крайне идиотский: все эти тысячи строк результата могут где-то буферизироваться, хотя они мне в этом сеансе связи не понадобятся.

Беспокоюсь потому, что хостинг типичный - то есть не на своем железе, а просто этот сервер у хостера держит еще другие сайты и с каждым новым посетителем ресурсов может недоставать заметно сильнее.

Это сообщение отредактировал(а) DENNN - 30.9.2005, 15:14

Цитата(DENNN @ 30.9.2005, 16:12)

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

Ну вообще-то у сервера телепатические способности отсутствуют - он способне только посчитать, сравнить и выдать результат.

Цитата(DENNN @ 30.9.2005, 16:12)

В базе десяток таблиц со сложной структурой связи "один к одному". Связь осуществляется стандартно, через ID.

Вот ЭТОГО я понять не способен в принципе. Связь 1:1 оправдана очень редко - только при наличии в таблице части редко используемых данных их имеет смысл выносить в такую связанную таблицу. Применительно к твоему вопросу - что мешает вместо жуткообразной сложной структуры связей собрать все в одну таблицу? или ты что-то сильно недоговариваешь...

Цитата(Akina @ 30.9.2005, 15:40)

Ну вообще-то у сервера телепатические способности отсутствуют - он способне только посчитать, сравнить и выдать результат.

Ну вообще-то ты недопонимаешь. Для того чтоб подсчитать все строки, нужно найти все строки, удовлетворяющие указанному условию. То есть перебрать все строки, инкременируя счетчик на каждой (это простейший, не оптимальный алгоритм). Но мне не нужно пересчитывать 20000 строк, достточно при достижении счетчика скажем 1000 остановиться. Т.е. в моем примере вместо затрачивания 3 секунд хватило бы и 0.3 секунды.

Цитата(Akina @ 30.9.2005, 15:40)

Вот ЭТОГО я понять не способен в принципе. Связь 1:1 оправдана очень редко - только при наличии в таблице части редко используемых данных их имеет смысл выносить в такую связанную таблицу. Применительно к твоему вопросу - что мешает вместо жуткообразной сложной структуры связей собрать все в одну таблицу? или ты что-то сильно недоговариваешь...

Скорей запутался в терминологии. Например, есть таблица, содержащая запись о каждом офисе. Есть таблица, содержащая запись видов банковских услуг. А есть таблица содержащая два поля: ID офиса и ID услуги. Т.е. если офис оказывает 10 видов услуг, то в этой таблице будет десять записей с идентификатором этого офиса.
Добавлено @ 18:06
P.S. Не надо говрить, что это не нужно. Вот например в STL есть масса алгоритмов частичной сортировки, частичного перебора и т.д как раз для побобных задач, когда нет необходимости перетряхивать весь контейнер.

Цитата(DENNN @ 30.9.2005, 19:05)

достточно при достижении счетчика скажем 1000 остановиться.

У Мускула нет такого механизма... то есть можно посмотреть как именно работает LIMIT - но мне кажется что сперва все одно получаем всю выборку.

Цитата(DENNN @ 30.9.2005, 19:05)

есть таблица содержащая два поля: ID офиса и ID услуги

Это нормально. Но это совсем даже не 1:1.

Akina LIMIT не выход. Я выдаю запросы по 30 на страницу, а время выполнения как у всех сразу

Secandr
Не, ну делай временную таблицу на текущий ID совокупности реквизитов - первый запрос будет долгий (как, впрочем, в любой мощной системе поиска), а листание по страницам - быстрое.

Цитата(Akina @ 3.10.2005, 09:54)

первый запрос будет долгий (как, впрочем, в любой мощной системе поиска), а листание по страницам - быстрое.

Для вебтехнологий это автоматически означает необходимость persistent connection вместо обычного (иначе временные таблицы удалятся после разрыва соединения).

Это сообщение отредактировал(а) DENNN - 3.10.2005, 12:44

Цитата(DENNN @ 3.10.2005, 13:44)

Для вебтехнологий это автоматически означает необходимость persistent connection вместо обычного (иначе временные таблицы удалятся после разрыва соединения).

не-а... как организовать... просто добавляется
1) таблица реквизитов запроса
2) статические таблицы выборок по этим запросам.
Первым делом выполняется проверка, нет ли ЭТИХ реквизитов в таблице реквизитов запроса. Если есть - просто берется необходимая таблица выборки. А вот если нет - то делается выборка в новую статическую таблицу, и реквизиты заносятся в таблицу реквизитов. При необходимости (достижение порога по кол-ву или объему) удаляется самая старая таблица выборки и соотв. ей строка таблицы реквизитов.

Akina когда писал пост, я об этом подумал. Хотя не всё то долото, что блестит.
База обновляется быстро - стол заявок. Хранить запросы имеет смысл только для одной сессии, слава богу что время посещения строго запоминается

Цитата(Akina @ 3.10.2005, 14:00)

1) таблица реквизитов запроса 2) статические таблицы выборок по этим запросам. Первым делом выполняется проверка, нет ли ЭТИХ реквизитов в таблице реквизитов запроса. Если есть - просто берется необходимая таблица выборки. А вот если нет - то делается выборка в новую статическую таблицу, и реквизиты заносятся в таблицу реквизитов. При необходимости (достижение порога по кол-ву или объему) удаляется самая старая таблица выборки и соотв. ей строка таблицы реквизитов.

Фигня какя-то получается для выборки из нескольких таблиц. Потому что варианты запросов самые разные и хранить выбоорку из 20 тысяч строк примерно так для 2-3 тысяч вариантов выборок - на кой тогда БД нужна? Я же каким-нибудь движком могу раз в 2-3 часа сотню тысяч HTML страниц сгенерить - все проще

Это сообщение отредактировал(а) DENNN - 3.10.2005, 17:17