Пара вопросов спецам по мускулу

1. При умелых действиях можно умудриться сломать мускул и на меньших объемах. При других умелых действиях у вас не хватит данных, чтобы сломать мускул. Хотя при идеальном железе можно не беспокоиться: оно на то и идеальное, что при любом раскладе любой запрос на любых данных выполняется мгновенно.

2. Нет, конечно.

"абстрактное идеальное железо" - самое распространненое заблуждение студентов и начинающих программистов, за которое они неизбежно получают в пятак от админов и заказчиков.

MySQL умеет работать быстро, но только если писать запросы со знанием дела.

Главу руководства "оптимизация" не просто желательно прочитать. Ее ОБЯЗАТЕЛЬНО нужно прочитать 11 раз, вникая в каждое слово, прежде чем садиться писать более менее большое приложение.

А "максимальный объем" ограничен по большей частью размером винта(ов).

Под абстрактным идеальным железом подразумевается, что такое же железо будет отдано под другую БД.

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

Оракл попродуктивнее будет МуСКуЛа, про интербейс забудте. У меня МуСКуЛ тянул 800 нагруженых таблиц ;) и всё ок было. Обязательно создавайте индексы по всем полям, которые фигурируют в поисковых запросах. С умом используйте тип индекса (хеши, бинарные и ЧБ-деревья).

Дык все дело в структуре базы и сложности запросов, а не в размере.

Если система использует только простые запросы с использованием индексов и т.п. - то есть то, что mysql УМЕЕТ делать ХОРОШО, то mysql даст фору любой базе.

А если программер навернет кучу субреквестов и join'ов по десятку таблиц - то это будет не вина мускула, что он будет тормозить ;)

У каждого продукта есть свои сильные и слабые стороны. Нужно просто уметь использовать одни и избегать других.

фултекстсерч у муксула самый сильный?

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

У вас не хватит дисков, чтобы хранить данные, не влезающий в мускль.

При действительно грамотном DBA и программерах с прямыми руками мусль прекрасно работает с базами в единицы терабайт.

Всё верно, больше от скрипта зависит, + можно ещё и кешировать много чего!

нехочу создавать новую тему, но есть у меня один интересный запрос на сайте, который смущёно требует 0.8сек, когда другие укладываются в 0.1 сек )

Вот сам запрос:

Смысл запроса такой что нужно выбрать все оценки 10 и соответствующие фотографии.

Индексы в поиске не участвуют, они стоят только на ID, участвуют только в сортировке.

Больше всего непонятно то что если убрать (f.ok=1 and f.view=0 and f.ero=0) из условия отсеивания, время запроса уменьшается в 10 раз.

Как же так? В чём тут загвозка? :(

Dimanych,

а теперь подумайте зачем тут left join ? очевидно не бывает оценок без фотографий. уберите слово left и все.

почему-то не первый раз встречаю у программистов мнение, что left join нужно использовать всегда, когда нужно соединить таблицы. различие в планах выполнения кардинальное. обычный join считывает индексы, а left - создает временную таблицу.

это какой-то заговор фрилансеров ?