_sts_ писал(а):Извините за наивный вопрос, но мне надо срочно...
Мне надо постоянно выяснять текущее кол-во неких строк в базе,
вопрос: грозит ли постоянный вызов SELECT COUNT(FIELD) ...
тормозами, когда база разрастется?
А как же. Да ещё и возвращать будет хрен знает что, в concurrency - количество на момент старта, но не запроса, а транзакции (а их там с тех пор полторы тыщи удалили и полмульёна вставили), а в read_commited на длинной выборке не узнает, что половину из того, что уже сощытал, с тех пор поудаляли и закоммитили пока до конца таблицы добрался, а заместо них навставляли полстолька, но ещё не закоммитили.
_sts_ писал(а):
Т.е. выполняется ли он простым перебором строк
ога
_sts_ писал(а):
или как-то по-другому?
не-а
_sts_ писал(а):
(Блин, где-то ведь читал про это, но как понадобилось - так хрен найдешь где!)
В журнале Мурзилка, видать
_sts_ писал(а):
P.S. SELECT SUM(...)- тоже самое?
не-а. Sum - это сложить, а не сосчитать.
В общем, если агрегаты нужны постоянно - их делают хранимыми. В специятельно для этого создаваемой табличке. Если они нужны с пылу с жару, в онлайне - инкают/декают соответствующую запись в ней на триггерах оперативной таблицы. И разруливают конфликты, потому что вставляюшие-удаляющие транзакции начинают толкаться на записях таблицы агрегатов. И всё равно данные будут слега устаревши - прочитали мы агрегат, а он через микросекунду изменился. А если они нужны на какой-то момент, а потом на них начинаются какие-то расчёты-размышления - то собирают в эту табличку агрегатов либо регламентно, шедулером, либо по требованию. Так что если многопользовательская задача якобы требует постоянно точных онлайн-агрегатов - следует задуматься о консерватории.
