MySQL: MyISAM vs InnoDB

[feedbee]

MySQL: MyISAM vs InnoDB

я решил погуглить на тему, когда лучше MyISAM, а когда InnoDB. Выяснилось, что все пишут по-разному. Четкого мнения у меня не сформировалось.

Вопрос: по вашему опыту и знаниям, давайте четко сформулируем правила: в каком случае лучше выбрать движек MyISAM, а в каком InnoDB :?:

:idea: Внимание! Рассматриваем только случаи, когда не нужен ни полнотекстный поиск, ни транзакции. Потому что в этих случаях и так понятно, что надо юзать.

 

[camka]

Re: MySQL: MyISAM vs InnoDB

Автор оригинала: feedbee
... давайте четко сформулируем правила: в каком случае лучше выбрать движек MyISAM, а в каком InnoDB :?:

Давайте!

 

[feedbee]

Хорошо, начну я сам. Пишу то, чего начитался, не тестил. Так что исправляйте, где не прав.

1) MyISAM лучше справляется с SELECT'ами, InnoDB - с INSERT и UPDATE из-за того, что в MyISAM блокировка на всю таблицу, а в InnoDB - построчная.
2) Без нагрузки и/или с малыми таблицами быстрее работает MyISAM (проверял сам), под нагрузкой - InnoDB (почему - так и не понял; не проверял).
3) InnoDB надежнее, чем MyISAM и при загрузке умеет сама чинить поврежденные таблицы. Если приоритетна сохранность данных, а не скорость, то юзаем InnoDB.

Видел один отзыв, что использование сразу обоих видов таблиц может вызвать проблемы (ресурсы поделить они не могут). Кто-нибудь сталкивался?

Если таблица большая, но в ней селектов много больше, чем изменений, и нагрузка средняя (немалая), стоит ли делать таблицу InnoDB? - не понятно.

Если таблица большая и соотношение выборок/изменений близко к 1:1, нагрузка средняя - какой тип ывбрать?

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

 

[Апельсин]

> MyISAM лучше справляется с SELECT'ами, InnoDB - с INSERT и UPDATE из-за того, что в MyISAM блокировка на всю таблицу, а в InnoDB - построчная.

- Смотря с какими SELECT. SELECTы по первичному ключу в InnoDB работают хорошо, т.к. там записи все физически упорядочены по первичному ключу.
- Комбинация SELECT/INSERT с MyISAM при включенном concurrent_inserts тоже будет работать хорошо, потому что INSERTы не будут блокировать SELECTы.
- В InnoDB блокировка хоть и построчая, но блокироваться могут все строки таблицы. Зависит от запроса и кривости рук.

2. С маленькими таблицами и без нагрузки у вас хорошо будет работать все.

3. если таблица большая, но в основном read-only, то стоит смотреть в сторону кэширования.

 

[Mols]

afaik MyISAM - не поддерживает внешние ключи... так что если предпочитаете отслеживать целосность данных средствами СУБД InnoDB для вас.

 

[Сергей Тарасов]

Mols

Как бы запросто можно использовать для этого триггеры.
Их можно использовать и для MyISAM.

И все-таки, есть ли реальные цифры сравнения производительности? Допустим для разных вариантов таблиц?
Вопрос к Апельсин, как к большому специалисту... )

 

[Mols]

Автор оригинала: Сергей Тарасов
Как бы запросто можно использовать для этого триггеры.

как бы можно конечно, (удобней правда процедуры) но это уже не совсем то, что имелось в виду под сохранением целосности данных средствами СУБД.
Хотя конечно можно сказать что триггер это тоже средство СУБД... но не думаю,что мы будем здесь это обсуждать.
Ну и ещё... триггеры ещё очень сырые afair. Ссылку не приведу.. но была не так давно у меня ситуация, когда надо было выбирать использовать триггеры или нет (именно в МуСКЛ), и я отказался от их использования почитав если не ошибаюсь багфиксы на сайте МуСКЛ.

 

[Wicked]

про скрость: http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1/

 

[Krishna]

Если таблица большая и соотношение выборок/изменений близко к 1:1, нагрузка средняя - какой тип ывбрать?

InnoDB. 1 к 1 - это достаточно интенсивная запись.
Если есть тяжелые запросы на выборку - MyISAM может просто напросто встать колом. У него бывает прикольная проблема, когда выполняется тяжелый запрос на выборку, за ним в очередь встает запрос на изменение, но ждет первый, потому как версионности нет - а за ним мгновенно наваливается куча запросов на чтение, как снежный ком, которые ждут, пока исполнится запись. В результате БД может просто напросто зависнуть. Я такое наблюдал у себя не раз.

Видел один отзыв, что использование сразу обоих видов таблиц может вызвать проблемы (ресурсы поделить они не могут). Кто-нибудь сталкивался?

Ну разве что возможно потребуют больше памяти, так как буферы у них разные...

 

[Сергей Тарасов]

Mols
Да нет, сейчас вроде все нормально с триггерами. Тем более, что целостность БД можно поддерживать на более высоком логическом уровне, нежели простое каскадное обновление/удаление и т.п., которое предоставляет механизм InnoDB.

Wicked


Спасибо! Отличная ссылка. Хотя результаты несколько странные...

 

[feedbee]

Автор оригинала: Krishna
В результате БД может просто напросто зависнуть. Я такое наблюдал у себя не раз.

Я тоже наблюдал.

Автор оригинала: Wicked про скрость: http://www.mysqlperformanceblog.com...chmarks-part-1/

Я это видел. И данные у них между прочим расходятся с большей частью отзывов.