Подбор СУБД

select count(*) from DATABASE

(Строка суммарно насчитывает ~170байт)

Sybase справился с такой же задачей гораздо быстрее...

Не смогу я вам помочь с нахождением истины, если вы будите скрывать изначальные параметры. Не думал, что в вашем запросе есть коммерческая тайна. А то что MySQL выполняет запросы SELECT COUNT(*) - по 10-ть минут, говорит только о неправильной организации хранении данных или о неправильной организации построения индекса.

P.S. При желании и/или неграмотности можно любую БД подгрузить на несколько дней.

Максим, вообще-то при обработке запросов с функциями вроде count, avg, sum индексы никак не используются. ;)

Да ну, в запросе:

select count(*) from tablename where id > 134277; очень даже используются.

В таком запросе индексы некуда прикладывать. :)

Извиняюсь наверное неправильно понял ваше сообщение...

А вообще мне кажется что такая ситуация возможна, если где то используются разреженные структуры данных(имею в виду при разработке БД), для которых действительно можно не знать без полного пересчета числа записей. Но приведенный пример имхо не сильно критичен...

Господа, я спорить с модераторами не буду. Тем более, не считаю себя профи по БД MySQL. Спасибо, trink, разъяснил. А для желающих действительно Выжать всё возможное из MySQL, рекомендую изучить документацию и её специальный раздел: "Оптимизация в MySQL" http://www.mysql.ru/docs/man/MySQL_Optimisation.html

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

Ну вот могу сказать что когда меня не удовлетворяли алгоритмы баз данных(например какая нибудь хитрая многомерная сортировка), я их реализовывал сам на уровне бизнес логики с применением классических подходов теории алгоритмов :) А вообще я думаю что у нас достастаточно разные задачи что бы мерятся в скорости...

ПС И кстати мне кажется что в том случае все таки индекс мог бы существенно ускорить выполнение запроса...

Для информации, скорее всего известный вам поисковый движок "Сова" использует базу данных MySQL.

Вчера я задумался, а почему так сложилось, что в большей степени поисковики сидят на своих БД ? Теперь давайте вспомним, когда начинали разрабатывать Яндекс, Рамблер, Гугол. Примерный временной интервал 1994-1996 гг. Вы помните, что тогда могли делать БД ? Тот же MySQL ? А я помню, вопросов о том, стоит или не стоит использовать БД было значительно меньше. Скорее всего, на тот момент функциональность и надёжность не устроили разработчиков поисковиков и им пришлось разрабатывать свои варианты. Но время шло. Компании производящие БД тоже не сидели на месте, а усердно развивались. Сейчас ситуация поменялась. Крупные поисковики даже при большом желании уже не смогут быстро перейти на нынешние БД. Т.к. придётся полностью перерабатывать движок. Да и зачем, когда старый проще совершенствовать и затачивать под себя.

Совершенно иная ситуация для молодых компаний. Которые могут съэкономить большие деньги, не разрабатывая и развивая свои варианты БД. Ведь вдумайтесь, на MySQL потрачено десятки тысяч человеко-часов, код написан на языке Си. Оптимизируют под супер производительность, проверяют коммерческими детекторами утечки памяти и т.д и т.п. Разве такой продукт не может удовлетворить потребности молодых разработчиков поисковиков ?

На мой взгляд, сейчас надо акцентировать внимание на алгоритмы работы с информацией, а вопрос хранения информации предоставить решать специализированным фирмам.

В простом случае - есть алгоритм поиска F его сложность O(n), где n-количество данных. Существуют алгоритмы индеферентные к оличеству данных, есть те которые очень легко работают с добавлением/удалением и.т.п

Какие из них используются в СУБД - не всегда известно.

Остается либо занижать n либо искать более приемлемый алгоритм F.