Posted 29 сентября, 201410 yr comment_71995 Кто-то может подсказать, в чём отличая между ними, конкретно для ipboard? В каких случаях стоит выбирать именно InnoDB? С хабры за 2009г MyISAM транзакций нет макс. диск: 256Тб блокировка таблица полнотекстовый поиск работа в кластере: нет поддержание целостности, внешние ключи: нет репликация: да макс. индексов: 64 макс. записей: 2^32 макс. длина ключа: 1000 байт ключи занимают место на диске до (макс.): (key_length+4)/0.67 чувствительные к «падению» сервера, сложно восстанавливать при отсутствии «дырок» (gaps) — вставки не конкурентные (блокировок не происходит) возможно хранить файлы данных и индексов на разных устройствах каждый столбец может иметь свою кодировку макс. сумма длин VARCHAR и CHAR: 64к Static (Fixed-length) формат таблиц автоматически, если нет VARCHAR, VARBINARY, BLOB, TEXT столбцов быстрее, безопаснее (устойчивее), лучше кешируется, требует больше места на диске если указать принудительно, VARCHAR и CHAR заполняются пробелами, VARBINARY — нулями Dynamic length формат таблиц все строки длиной до 4 — VARCHAR пустые строки и ноль (0) не занимают места на диске (NULL это не ноль) запись (строка) фрагментируется автоматически при апдейтах (нужно запускать OPTIMIZE TABLE для дефрагментации) сложнее восстановить при сбоях Compressed создается утилитой myisampack read-only рекомендуется для очень медленных носителей может быть и fixed-length и dynamic-length посмотрите в сторону Archive table engine Советы: говорят, что MyISAM таблицы обязательно «ломаются» рано или поздно, так что будте готовы. (другой источник) Случается такое крайне редко, но и этого хватает. Поэтому с для MyISAM рекомендуется организовать периодический запуск mysqlcheck через cron. не убивайте сервер во время записи не изменяйте таблицы несколькими серверами одновременно не изменяйте таблицы утилитой и сервером одновременно Рекомендации: справочники InnoDB макс. диск: 64Тб полная поддержка транзакций (4 уровня изоляции) блокировка записи (не таблицы), два вида блокировок (SHARED, EXCLUSIVE) полнотекстовый индекс: нет безопасная для транзакций индексы кластеризуются для «типичных запросов» поддержка целостности (внешние ключи) может использоваться на ОС с ограниченным размером файла множество настроек для оптимизации позволяет использовать Raw Disk для таблиц в обход ФС по умолчанию включен AUTOCOMMIT (SET autocommit=1) автоматически детектит дэдлоки (deadlocks) Движок был разработан специально для больших таблиц. Разработчики заявляют, что InnoDB — самый быстрый из всех известных движков для БД основанных на дисках (множественные тесты это подтверждают) Советы: SELECT (*) FROM table работает гораздо медленнее, чем MyISAM — создавайте триггеры если нужно бэкап простым копирование файлов невозможен mysqldump работает медленно, для бэкапа используйте InnodDb Hot Backup следите за индексами, выгода InnoDB теряется, если для запросов нет индексов Рекомендации: высоконагруженные сайты, финансовые транзакции
29 сентября, 201410 yr Author comment_71996 Вот ещё Что хорошо в MyIsam - конечно, у этих таблич сулекты работают быстрее всего! В чем же водвох? При обрашении к MyIsam таблицам соответствующая таблица блокируется полностью, в InnoBD блокировка накладывается лиш на одну запись. Таким образом одним из критериев выбора типа таблиц служит степень обновляемости таблиц. При увеличении числа обращений на обновление таблица MyIsam может быть почти всегда заблокирована, что приведет к увеличению длительности запросов к нуй. Таблицы этого типа лучше использовать для данных типа "Словрь", т.е. тех которые почти никода не изменяются. Если же в таблицу планируется вести интенсивную запись, то все же лучше использовать InnoDb. Т.е. как я понимаю для форума, всё-таки лучше MyISAM. Т.к. он используется как "словарь". Т.е. изменений в сообщениях не происходит.
30 сентября, 201410 yr comment_72009 AlexBrtn, не скажи. Запись при постинге происходит в таблицу постов, которая в свою очередь в этот момент блокируется в MyISAM. Я сперва перевел таблицы постов в InnoDB, а со временем и всю БД. Выборка может и чуть медленнее, зато про потери данных падение MySQL забыл. InnoDB имеет смысл на крупных форумах с высокой посещаемостью. Переход на InnoDB несет в себе один существенный подводный камень - невозможность использования полнотекстового поиска, т.е. встроенный поиск по форуму станет совсем неадекватным (он и так-то кривой). Выход: ставить Sphinx. Edited 30 сентября, 201410 yr by motomac
30 сентября, 201410 yr Author comment_72017 motomac, Учту, спасибо. Все эти записи, выше, 2009г. Подумал, что в MyISAM, всё-таки, за 5 лет избавились от проблемы потери таблиц. По-поводу перевода в InnoDB: процесс вообще без болезненный? Как это делается? Как я понимаю для InnoDB можно будет использовать >гугл-поиск по сайту?
3 октября, 201410 yr comment_72131 AlexBrtn, да, вполне безболезнный. Только бэкап сперва сделайте. Гуглопоиск, конечно, будет работать. Но еще раз повторю, что это имеет смысл с посещаемостью от нескольких тысяч в сутки.
28 марта, 20159 yr comment_84182 Подумал, что в MyISAM, всё-таки, за 5 лет избавились от проблемы потери таблиц. Избавились в Aria - а-ля MyISAM в MariaDB. Как я понимаю для InnoDB можно будет использовать гугл-поиск по сайту? InnoDB не поддерживает полнотектовый поиск, поэтому необходимо юзать сторонние утилиты. Sphinx Search, Elastic Search (используем) или гуглопоиск.
28 марта, 20159 yr comment_84234 InnoDB не поддерживает полнотектовый поискс 5.6.4 вроде уже поддерживается
7 апреля, 20159 yr comment_84826 Только в самом движке поддержки полнотекстового InnoDB все равно нет, как мне сказали в техподдержке. Elastic Search (используем) А на IPB есть готовые решения? Расскажите поподробнее. Edited 7 апреля, 20159 yr by motomac
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.