MyISAM в InnoDB и наоборот

Оглавление (нажмите, чтобы открыть):

Как в MySQL преобразовать все таблицы во всех базах из MyISAM в InnoDB или обратно

Сначала о том, когда и зачем вам может потребоваться конвертировать движки базы данных. Во-первых, InnoDB (XtraDB) современнее (в данном случае читай «лучше для боевого использования»). Во-вторых, после аварийного падения или по итогам неумелого переноса файлов и логов СУБД, где уже используется InnoDB, можно получить примерно такую ошибку в error-логе мускула:

Если у вас возникла именно такая проблема, то можно попробовать решить её без остановки СУБД, а, точнее, с минимальным даунтаймом на перезапуск сервиса.
Сначала рассмотрим первый случай:

Есть и нормально работает MyISAM, но хочется, чтобы стало InnoDB

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

Проверить можно таким запросом:

В условии AND table_schema NOT IN. я исключаю системные базы (которые трогать вообще не надо). Если у вас MySQL версии меньше, чем 5.5, то база performance_schema может отсутствовать. Заранее проверьте есть она или нет и, при необходимости, уберите её из запроса.

Если запрос вернёт пустой результат, то всё ОК, у вас нет FULLTEXT-индексов, можно все таблицы перевести на InnoDB. Если результат непустой, то вы увидите имена таблиц, которые на InnoDB переводить нельзя, чтобы ничего не поломалось.

Например, если среди баз у вас есть БД для CMS WordPress, то, скорее всего, вы обнаружите, что FULLTEXT-индексы применяются в таблице wp_posts . Если очень хочется, то вы, конечно, можете остальные таблицы базы преобразовать в InnoDB руками, а wp_posts — не трогать. Чтобы сменить движок для таблицы wp_users в базе wordpressdb надо сделать следующее:

Но если вам повезло, и у вас нет таблиц с полнотекстовыми индексами (например, если вы используете для сайтов не WordPress, а Drupal), то можно одним запросом изменить движки сразу для всех таблиц во всех базах (кроме системных):

Снова напомню, что системная база performance_schema может отсутствовать. Проверьте заранее.

Теперь второй случай:

Все базы были на InnoDB, но с ним возникла проблема, надо получить InnoDB без проблем и почти без даунтайма

  1. Делаем дамп.
  2. Конвертируем все таблицы всех баз в MyISAM
  3. Удаляем файлы и логи InnoDB
  4. Перезапускаем MySQL, чтобы она создала новые пустые файлы и логи
  5. Конвертируем все таблицы всех баз обратно в InnoDB из MyISAM

Делаем дамп (это делаем не в mysql, а в bash):

mysqldump -u root -pPASSWORD —all-databases > mysql_full_dump.sql

Переводим все таблицы всех несистемных баз на MyISAM:

Удаляем файлы и логи InnoDB и перезапускаем MySQL (это мы делаем не в mysql, а в обычной системной консоли, в bash короче):

Простой будет минимальным: после установки сервера мы лишь удалим несколько файлов, а это быстро, и снова запустим сервер.

Переводим все таблицы назад на InnoDB:

Ещё можно решить проблему с помощью дампа. То есть в дампе меняем тип движка, а потом этот дамп вливаем обратно. Хитрость в том, чтобы не лезть с заменой подстроки MyISAM на InnoDB в данные, меняя только в схемах:

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

MyISAM в InnoDB и наоборот

Профиль
Группа: Участник
Сообщений: 408
Регистрация: 23.9.2006

Репутация: 1
Всего: 6

Часто у начинающих работать с MySQL программистов возникают вопросы в чем состоит отличие СУБД MyISAM от InnoDB и наоборот. Я собрал из различных источников в сети некоторое количество информации на данную тему с которой вы можете ознакомиться.

Цитата(MyISAM)
Быстрее выполняется большое количество запросов SELECT, INSERT, но при небольшом количестве запросов DELETE или UPDATE.
Также производительность падает при значительном количестве одновременных запросов на чтение/запись к таблице.
Цитата(InnoDB)
InnoDB предлагает кэширование данных, более высокий параллелизм, фоновую запись на диск, ухудшения производительности – более медленная запись, более медленная обработка BLOB, проблемы при работе с очень большим количеством таблиц, медленная загрузка данных и ALTER TABLE, низкая производительность COUNT(*) без WHERE, исправление данной проблемы требует модификации приложения.
Цитата(MyISAM)
Для каждой таблицы создается один файл данных.
Цитата(InnoDB)
Данные InnoDB в настройках по умолчанию хранятся в больших совместно используемых файлах (изменить это можно с помощью настроек опции innodb_file_per_table), что позволяет использовать постраничный кэш страниц базы данных.
Цитата(MyISAM)
Таблица может отказаться работать без явной на то причины. Необходимо выполнение REPAIR TABLE.
Для контроля целостности таблиц рекомендуется периодически запускать mysqlcheck через cron.
Отсутствие возможности самовосстановления по журналу при сбоях.
Цитата(InnoDB)
Формат данных InnoDB обеспечивает надежное хранение данных за счет транзакционности и блокирование данных на уровне СТРОКИ.
InnoDB обеспечивает также и быстрое самовосстановление после сбоев.
Цитата(MyISAM)
Отсутствие блокировок регионов, меньших, чем целые таблицы. Приводит к отсутствию масштабируемости, т.е. к сильной деградации производительности с повышением нагрузки.
Цитата(InnoDB)
Блокировка регионов, на уровне строк таблицы. Нет деградации производительности с повышением нагрузки.
Цитата(MyISAM)
Не поддерживаются.
Цитата(InnoDB)
Поддерживаются.
Цитата(InnoDB)
Могут возникать deadlocks, не свойственные MyISAM.
Цитата(MyISAM)
Поддерживается.
Цитата(InnoDB)
Полнотекстовый поиск не поддерживается.
Цитата(MyISAM)
Отсутствие средств резервного копирования. Утилита mysqldump, предлагаемая для создания резервных копий, является не инструментом резервного копирования, а инструментом экспорта в текст (в последовательность операторов INSERT, воссоздающих содержимое таблицы). Для выполнения задачи с сохранением целостности базы данных mysqldump захватывает блокировку таблицы, приводя к полной остановке работы системы на все время своего исполнения.
Останов процесса MySQL и создание копии инструментами копирования файлов из UNIX приводит к меньшему времени простоя системы. Особенно удачен для этого gzip в режиме минимальной компрессии, который при незначительной для современного оборудования нагрузке процессора снижает объем данных, подлежащих записи в полученный файл, и тем самым ускоряет операцию.
Цитата(MyISAM)
Как правило таблицы MyISAM компактней.
Цитата(InnoDB)
Без сжатия увеличение размера таблиц.

Это сообщение отредактировал(а) FiMa1 — 16.1.2010, 02:27

Профиль
Группа: Участник
Сообщений: 8
Регистрация: 14.4.2007

Репутация: нет
Всего: нет

тут можно писать?
я не эксперт но расскажу то что видел в своей жизни.

был случай когда innodb крашнулся. и никак не удалось его востановить(вохможно неопытность но не факт). но всеже «The storage engine for the table doesn’t support repair».
тогда как myisam хоть и отказывается работать чаше(как минимум потому что таких тамблиц у нас всегда было больше. особенно после того как мы одну таблицу innodb потеряли ) repair всегда нормально чинит его.

у myisam не эффективный бекап(mysqldump в .sql файл). лучше файлы таблицы скопировать.

для innodb не работает mysqlhotcopy.

нормального способа востановление innodb таблиц я та ки не видел. так что когда бывают таблице в которых нуна большая производительность read/write использую innodb но при условии что часто их бекапить. а вообше стараюсь строить системы так чтобы не приходилось юзать innodb

Это сообщение отредактировал(а) passer — 19.10.2010, 15:39

passer
Дата 19.10.2010, 15:24 (ссылка) | (голосов:1) Загрузка .
Мастер Йода рекомендует:  Гостевая книга на php и MySQL PHP

Профиль
Группа: Участник
Сообщений: 56
Регистрация: 17.3.2014

Репутация: нет
Всего: нет

mysql вообще часто ломается, особенно при больших объемах таблиц, MyISAM конечно ломается чаще но зато не так критично

единственным способом реально сохранить данные и повысить отказоустойчивость для реляционных баз данных остается репликация Мастер->Слэйв + регулярный бэкап слейва.

с noSQL таких проблем конечно нет =)

Отличия движков InnoDB от MyISAM в MySQL

Главное преимущество InnoDB в скорости работы — при выполнении запроса к базе InnoDB происходит блокировка строки, при выполнении же запроса к базе MyISAM блокируется таблица, это означает, что пока запрос выполнен не будет никакие другие обращения к таблице/строке будут невозможны. Поскольку строки значительно меньше InnoDB обрабатывается быстрее.

InnoDB в отличии от MyISAM поддерживает транзакции, а MyISAM имеет полнотекстовый поиск для всех версий Mysql (для InnoDB такая поддержка есть только для версий старше 5.6.4)

MyISAM таблицы можно без всяких трудностей конвертировать в InnoDB (как и выполнять преобразование в обратном направлении). Это делается при помощи ALTER TABLE или скриптом если таблиц много.

При ковертации стоит иметь в виду, что начиная с версии MySQL 5.6 и эквивалентной ей MariaDB 10 InnoDB является движком по умолчанию. Для ранних версий по умолчанию таблицы создавались в MyISAM.

В настоящее время InnoDB используется значительно чаще, но есть два важных момента:

Недостатки InnoDB:
  1. InnoDB также сложнее восстанавливать после сбоя в работе сервера, для MyISAMвосстановление заключается в применении утилиты myisamchk
  2. Изначально сами данные как составляющая таблиц хранятся в одном файле ibdata1. Информация из этого файла не удаляется. Т.е. если таблица добавлена, в нее загружен дамп, потом таблица удалена — в ibdata1 содержимое останется и будет накапливаться занимая дисковое пространство. Также хранение данных по всем таблицам в одном файле означает, что с таблицами сложнее работать, нельзя перемещать их и восстанавливать из резервных копий по отдельности.

Второй вопрос решается добавлением в конфигурационный файл директивы innodb_file_per_table = 1; (подробнее о хранении данных InnoDB)

innodb_file_per_table = 1;

Отличия InnoDB от MyISAM, таким образом, весьма значительные и какой движок использовать стоит решать в каждом конкретном случае, но почти всегда перевешивают плюсы InnoDB.

Скрипт конвертации БД из MyISAM в InnoDB

Делюсь скриптом для конвертации всех таблиц базы из MyISAM в InnoDB. Нашел когда-то где-то на просторах интернета.

Делюсь скриптом для конвертации всех таблиц базы из MyISAM в InnoDB. Нашел когда-то где-то на просторах интернета, на авторство не претендую совершенно.

Сохраните под любым именем, указав свои названия базы, логины и пароли, назначьте файлу права на выполнение либо запустите через bash. Все таблицы внутри указанной базы перейдут на движок InnoDB. В Ubuntu и Debian скрипт работает отлично.

Зачем нужна конвертация в InnoDB?

Строго говоря, если у вас нет такой надобности — смена движка не требуется. Конвертировать «на всякий случай» бессмысленно. Для сайтов с посещаемостью до десяти-тридцати тысяч человек в сутки нет никакой разницы, какой движок используют таблицы. Если сайт нагруженный, бездумная смена движка может навредить. Нужно смотреть, какие операции в БД происходят, искать медленные запросы и только тогда принимать соответствующее решение.

Есть специфический случай, для которого этот скрипт мне пригождался не раз: требовалось привести в порядок старый сайт на WordPress. Не раз замечал, что таблицы в таких сайтах используют и MyISAM, и InnoDB, да ещё и в разных кодировках. Возможно, при переносе с одного хостинга на другой менялись дефолтные параметры базы.

У InnoDB есть преимущество перед MyISAM, которое не раз сберегло нервы: автоматическое восстановление при сбоях. Когда сайт размещается на VPS какого-то не очень стабильного хостинга, сервер может зависать и перезагружаться в самые неожиданные моменты. Запускать каждый раз myisamchk для починки MyISAM таблиц накладно. В InnoDB это происходит автоматически по логам операций, лишь бы файловая система сервера не оказалась повреждена.

MyISAM в InnoDB и наоборот

Таблицы в InnoDB.
Гуглёж подсказал, что это с InnoDB не лечится (или через Ж)
Ну и поскольку для ВП всё же лучше MyISAM, то есть желание перегнать МуСкульные таблицы из InnoDB в MyISAM.

Нагуглил советчика, который пишет, что вот так конвертится дамп:

Хочется услышать мнения — какие подводные камни при такой конвертации?

Ну и попутно — мб есть какие-то просты способы вылечить траблы с InnoDB (как юзеру на шаредхостинге)

jexerrus
Дата 18.3.2014, 06:36 (ссылка) | (нет голосов) Загрузка .

А в чём именно траблы?
У таблиц InnoDB не возникает «накладных расходов» => нет нужды в оптимизации.
ВП вряд ли использует какие-то фишки MyISAM и для него вряд ли есть разница.

А поменять тип таблиц можно с помощью phpMyAdmin или просто SQL-ем
ALTER TABLE `table` ENGINE = MYISAM

Если это ВП-шные таблицы и там никаким образом не возникло внешних ключей, то подводных камней быть не должно.

07.03.2014, 01:03 #2
Сказали спасибо:

До этого из 5,5 мб получилось 1,1.

Как бэ уже в 5 раз. И ещё можно, но.. не даёт.

07.03.2014, 01:23 #3

Точно InnoDB? И phpMyAdmin это показывает?

Таблички InnoDB сами по себе жирнее.

Эээммм. SELECT? а что с ним не так в InnoDB?

В дампе посмотреть, есть ли упоминания об FOREIGN KEY.
Или в phpMyAdmin нажать «Связи» и посмотреть, есть ли они.

Абзац «InnoDB Details».

07.03.2014, 01:46 #4
Сказали спасибо:

Лично я бы до упора пытался оптимизировать InnoDB, чтобы не откатываться на MyISAM. Всё же движки разного уровня (сравнение «на пальцах» — как Win9x и WinNT).
Конвертация sed -i s/ENGINE=InnoDB/ENGINE=MyISAM/g dbname.sql > dbname.myisam.sql, в принципе, должна сработать, но нужно пробовать на коротком тестовом дампе в конкретной среде, с последующей заливкой и проверкой. Неожиданности случаются.
[umka] выдал более коррректный вариант, лучше менять запросом на самом сервере.

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

07.03.2014, 07:50 #5
Сказали спасибо:

Можно не обращать на эту запись внимания, это физический аналог оптимизации таблицы.

Никаких, если внутри данных не встречается подстрока «ENGINE=InnoDB» (если блог не посвящен работе с MySQL, то вероятность ее встретить стремится к нулю). Т.е. можно практически смело использовать.

А проблемы какого именно рода?

07.03.2014, 08:33 #6
Сказали спасибо:

Скрин не с ПМА, конечно, там чисто .
Но это показывают как минимум 3 плага (я больше не использовал).
Если бы один — я б забил, но 3! Нет оснований не верить. ПМА тоже ж не панацея и я вполне допускаю, что какие-то его настройки\возможности это не позволяют показывать.

SELECT же на MyISAM значительно быстрее чем на InnoDB.

Эм.. таблица УЖЕ в 5 раз больше чем могла бы быть. И это сайт ещё практически пустой (100 постов всего). Страшно представить что может быть дальше.

ну как бэ невозможность оптимизировать Ну т.е. в данном контексте — наверное не просто уменьшить объём, а важно удалить мусор\косяки, которые влияют на скорость работы и надёжность получения данных в целом.

Повторю — это только начало. Что будет когда сайт разрастётся (там претензии на нормальный такой портальчик)? Поэтому я и хочу сразу обрубить возможность роста косяков.
Конечно, MyISAM нужно периодически проверять-лечить, но ИМХО это лучше, чем отсутствие такой возможности при всех шансах роста косяков. Ну и опять же — скорость SELECTа..

07.03.2014, 11:25 #7

Разницу в производительности вы заметите только при бешеной интенсивности чтения и практически полном отсутствии записи.
Там же, где вы прочитали про SELECT-ы, наверняка написано про кучу преимуществ InnoDB.
И я рекомендовал бы использовать MyISAM только в том случае, когда вы чётко прдставляете, зачем вы это делаете.

07.03.2014, 12:09 #8

Я не первый раз сравниваю преимущества\недостатки. И не вижу каких-то особых преимуществ InnoDB, при основном недостатке — скорости селекта (да и др запросах).
Надёжность же InnoDB если и несколько выше, то ИМХО не на столько, что бы жертвовать скоростью (да и объёмами на серверах). Бекапы решают всё .

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

Если я не прав — с радостью выслушаю аргументы.

ЗЫ. ну как вылечить те 2 таблички в InnoDB — тоже интересно

В моей практике попадались ВП-шные базы и по 2 гб.

Точно помню, что БД на 800-900 мб после оптимизации уменьшилась в 16 раз!
Думаю, это стоит того, что бы заморачиваться подобными вопросам

Как преобразовать все таблицы из MyISAM в InnoDB?

Я знаю, что могу выпустить alter table индивидуально, чтобы изменить хранилище таблиц с MyISAM на InnoDB.

Мне интересно, есть ли способ быстро изменить все из них на InnoDB?

26 ответов

запустите эту инструкцию SQL (в клиенте MySQL, phpMyAdmin или где угодно), чтобы получить все таблицы MyISAM в вашей базе данных.

замените значение name_of_your_db переменная с именем базы данных.

затем скопируйте вывод и запустите его как новый SQL-запрос.

работает как шарм.

Это даст вам список всех таблиц с запросами alter, которые вы можете запустить в пакете

в приведенных ниже сценариях замените ,

и конкретными данными.

чтобы показать операторы, которые вы можете скопировать-вставить в сеанс клиента mysql, введите следующее:

чтобы просто выполнить изменение, используйте это:

кредит: это вариация того, что было изложено в в этой статье.

используйте это как sql-запрос в вашем phpMyAdmin

вы можете выполнить этот оператор в инструменте командной строки mysql:

вам может потребоваться указать имя пользователя и пароль, используя: mysql-u username -p Результатом является SQL-скрипт, который вы можете передать обратно в mysql:

заменить «имя базы данных» в приведенной выше инструкции и командной строке.

это еще не было упомянуто, поэтому я напишу это для потомков:

Если вы переходите между серверами БД (или имеете другую причину, по которой вы сбрасываете и перезагружаете свой dta), вы можете просто изменить вывод из mysqldump :

затем загрузите его снова:

(кроме того, в моем ограниченном опыте это может быть намного быстрее, чем изменение таблиц «live». Вероятно, это зависит от типа данных и индексов.)

Это очень просто есть только два шага, просто скопируйте и вставьте:

(скопируйте и вставьте все результаты на вкладке sql)

Шаг 2: (скопируйте все результаты на вкладке sql) и вставьте ниже в строку

например. НАЧАТЬ ТРАНЗАКЦИЮ;

ИЗМЕНИТЬ ТАБЛИЦУ admin_files ENGINE=InnoDB;

вот способ сделать это для пользователей Django:

добавьте это в свое приложение в разделе управление папками / команды/ затем вы можете конвертировать все свои таблицы с помощью manage.py команда:

изнутри mysql вы можете использовать поиск / замену с помощью текстового редактора:

Примечание: Вы, вероятно, должны игнорировать information_schema и mysql, потому что » базы данных mysql и information_schema, которые реализуют некоторые из внутренних MySQL, все еще используют MyISAM. В частности, нельзя переключить таблицы грантов на использование InnoDB.»( http://dev.mysql.com/doc/refman/5.5/en/innodb-default-se.html )

в любом случае, обратите внимание на столы в игнор беги:

теперь просто скопируйте / вставьте этот список в текстовый редактор и найдите/замените «|» на «ALTER TABLE» и т. д.

у вас будет такой список, который вы можете просто вставить в свой терминал mysql:

если ваш текстовый редактор не может сделать это легко, вот еще одно решение для получения аналогичного списка (который вы можете вставить в mysql) только для одного префикса вашей базы данных, из терминала linux:

чтобы создать операторы ALTER для всех таблиц во всех несистемных схемах, упорядоченных этими схемами / таблицами, выполните следующее:

после этого выполнить эти запросы через клиент, чтобы выполнить изменения.

  • ответ основан на приведенных выше ответах, но улучшает обработку схемы.

простая версия MySQL.

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

это преобразует все таблицы MyISAM в текущей базе данных в таблицы INNODB.

вы можете написать сценарий, чтобы сделать это на вашем любимом языке сценариев. Скрипт будет делать следующее:

  1. вопрос SHOW FULL TABLES .
  2. для каждой возвращенной строки проверьте, что второй столбец говорит ‘BASE TABLE’ , а не ‘VIEW’ .
  3. если это не ‘VIEW’ , выдать соответствующее .

попробуйте этот скрипт

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

вместо 1 команды на таблицу я подготовил десятки команд (готовых к копированию и вставке) сразу с помощью excel.

Как? разверните окно putty и введите mysql, а затем выполните команду «показать состояние таблицы»; и скопируйте / вставьте вывод в microsoft excel. Перейдите на вкладку Данные и используйте функцию «текст к столбцам», разделяющую столбцы пробелом. Затем отсортируйте столбцы по тому столбцу, который показывает ваши типы таблиц, и удалите все строки, которые таблицы уже находятся в формате InnoDb (потому что нам не нужно запускать команды против них, они уже сделаны). Затем добавьте 2 столбца слева от столбца таблицы и 2 столбца справа. Затем вставьте первую часть команды в столбец-1 (см. ниже). Столбец 2 должен содержать только пробел. Столбец 3-это столбец таблицы. Столбец 4 должен содержать только пробел. Колонка 5-Последняя часть команды. Это должно выглядеть так:

затем скопируйте и вставьте около 5 строк за раз в mysql. Это будет конвертировать около 5 сразу. Я заметил, что если я сделаю больше, чем это сразу, то команды потерпят неудачу.

некоторые исправления к этому скрипту util

в моем случае я переходил от экземпляра MySQL со значением по умолчанию MyISAM к экземпляру MariaDB со значением по умолчанию InnoDB.

на старом сервере запустите:

параметры —skip-create-гарантируют, что сервер баз данных использует механизм хранения по умолчанию при загрузке данных вместо MyISAM.

В чем разница между InnoDB и MyISAM?

В чем разница между движками MySQL — InnoDB и MyISAM? Каковы их слабые и сильные стороны?

4 ответа 4

  • MyISAM поддерживает сжатие таблиц в отличии от InnoDB.
  • MyISAM имеет встроенные полнотекстный поиск в отличии от InnoDB.
  • InnoDB поддерживает транзакции в отличии от MyISAM.
  • InnoDB поддерживает блокировки уровня строки (MyISAM — только уровня таблицы).
  • InnoDB поддерживает ограничения внешних ключей (MyISAM — нет).
  • InnoDB более надежна при больших объемах данных.
  • InnoDB в теории немного быстрее.

До недавнего времени InnoDB не поддерживала полнотекстовые индексы.
InnoDB не хранит ни количество строк в таблице, ни следующее значение автоинкрементного поля. Первое не так важно, поскольку мало кому бывает нужно считать все строки в таблице, без какого бы то ни было фильтра. А вот второе в теории чревато. Если после удаления последнего выданного id сервер будет перегружен, то id будет выделен повторно. Впрочем, я не слышал о случавшихся такого рода косяках на практике

Есть один очевидный (но не сразу) минус MyISAM, вытекающий из особенностей блокировок. Если в системе могут выполняться тяжелые SELECTы, то любой UPDATE на участвующие в нем таблицы будет ждать окончания SELECTа и блочить все дальнейшие запросы. Если с базой работают достаточно активно, то это не вариант.

Если коротко, то в InnoDB есть поддержка транзакций, а у MyISAM нету. И еще MyISAM в отличие от InnoDB поддерживает текстовую индексацию. В основном используется MyISAM .

Всё ещё ищете ответ? Посмотрите другие вопросы с метками mysql innodb myisam или задайте свой вопрос.

Связанные

Похожие

Подписаться на ленту

Для подписки на ленту скопируйте и вставьте эту ссылку в вашу программу для чтения RSS.

дизайн сайта / логотип © 2020 Stack Exchange Inc; пользовательское содержимое попадает под действие лицензии cc by-sa 4.0 с указанием ссылки на источник. rev 2020.11.9.35389

Когда MyISAM лучше, чем InnoDB?

Иногда меня спрашивали на некоторых интервью: какие преимущества имеет InnoDB против MyISAM и когда MyISAM лучше, чем InnoDB? Все ясно из первой части вопроса: InnoDB совместим с транзакциями, блокировкой на уровне строк вместо блокировки на уровне таблиц, поддержкой внешнего ключа и некоторыми другими, эти моменты просто напомнили о себе.

Но когда MyISAM действительно лучше, чем InnoDB?

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

InnoDB — разумный выбор, если вам нужно хранить данные с высокой степенью точности с сложными взаимодействиями и отношениями. MyISAM — разумный выбор, если вам нужно сохранить или загрузить большое количество записей за небольшой промежуток времени.

Я бы не рекомендовал использовать MyISAM для данных, которые имеют значение. Это отлично подходит для полей регистрации или комментариев или чего-то еще, где вам особенно неинтересно, если запись исчезает в скручивании. InnoDB хорош, когда вы заботитесь о своих данных, не нуждаетесь в быстром поиске и должны использовать MySQL.

Также стоит упомянуть, что InnoDB поддерживает блокировку на уровне строк, в то время как MyISAM поддерживает только блокировку на уровне таблиц — что означает, что для многих распространенных ситуаций InnoDB может быть значительно быстрее из-за большего количества запросов, выполняемых параллельно.

Нижняя строка: Используйте InnoDB, если вы не должны использовать MyISAM. В качестве альтернативы, создайте против PostgreSQL и получите лучшее из того и другого.

Как преобразовать все таблицы MySQL из MyISAM в InnoDB Storage Engine

У вас есть какие-то таблицы в базе данных MySQL, все еще использующие MyISAM, и вы хотели бы преобразовать их в механизм хранения InnoDB ?

Это руководство было написано, чтобы помочь вам преобразовать MyISAM в InnoDB Storage Engine.

InnoDB уделяет большое внимание производительности, поддержке транзакций и надежности.

Начиная с версии MySQL 5.5 это был механизм хранения MySQL по умолчанию.

Вы можете прочитать MyISAM для InnoDB: почему и как получить сводную информацию о том, почему вы должны выбрать InnoDB.

Во-первых, прежде чем вы сможете конвертировать таблицы, вам нужно получить список таблиц, которые используют MyISAM.

Для этого войдите в свою MySQL / MariaDB из CLI и выполните запрос ниже.

Замените mydb вашим реальным именем базы данных.

Это выдаст вам список таблиц в базе данных mydb с использованием MyISAM и запросы, которые необходимо использовать для преобразования их в InnoDB.

Вы должны получить вывод, аналогичный приведенному ниже.

Преобразование таблиц MySQL из MyISAM в хранилище InnoDB

Все, что вам нужно сделать сейчас, это скопировать и запустить команду ниже в вашей оболочке MySQL.

Переключитесь на базу данных, которую вы хотите использовать.

Затем запустите приведенные ранее команды преобразования.

Повторите первую команду, чтобы проверить, есть ли таблицы, возвращающие для MyISAM.

Хорошо, теперь у вас есть все таблицы базы данных с использованием механизма хранения данных InnoDB.

Любые ошибки при конвертации из MyISAM в InnoDB?

Я готов перейти от MyISAM к InnoDB, но хотел бы знать, есть ли полный список вещей, которые нужно искать? Например, я не видел упоминания о том, что запуск DISABLE KEYS в таблице InnoDB будет вызывать предупреждение, за исключением страницы руководства для —- +: = 1 =: + —-. Это то, о чем мне нужно знать, прежде чем переходить. Я думал, что с моими вопросами все будет в порядке, но, видимо, нет.

2 ответа

Вот некоторые gotchas

Использование памяти

MyISAM

  • только кэширует страницы индекса.
  • общий ключевой кеш (размер по key_buffer_size).
  • Вы также можете настроить выделенный ключевой кеш, одну или несколько таблиц на кеш таблица .

InnoDB

  • кэширует страницы данных и страницы индекса.
  • один буферный пул и один размер до MySQL 5.5
  • 1 или более пулов буферов, начиная с MySQL 5.5

Индексы FULLTEXT

MyISAM

  • Поддерживает индексы FULLTEXT

InnoDB

  • Начиная с MySQL 5.6, да, , но все еще в бета-версии (UPDATE: MySQL 5.6 существует и имеет индексы FULLTEXT. Если вы используете индексацию FULLTEXT в MySQL 5.6, убедитесь, что используете Параметры FULLTEXT, специфичные для InnoDB )
  • Перед MySQL 5.6 это означает, что вы не можете преобразовать MyISAM в InnoDB.

MySQL 5.5 и обратно

Чтобы определить, какие таблицы MyISAM имеют индекс FULLTEXT, выполните этот запрос:

Все, что выходит из этого запроса, не может быть преобразовано в InnoDB до тех пор, пока вы не перейдете на MySQL 5.6.

ОПТИМИЗАЦИЯ ТАБЛИЦЫ

MyISAM

  • Таблица MyISAM сжата
  • ANALYZE TABLE запускает статистику индекса по всем индексам

InnoDB

  • ANALYZE TABLE абсолютно бесполезна, потому что статистика индекса всегда вспоминается
  • С innodb_file_per_table отключен, ibdata1 будет расти больше
  • С innodb_file_per_table включено, табличное пространство (.ibd) сжат

Я думаю, что самая большая проблема будет заключаться в том, что innodb является транзакционным. Вы хотите знать, используют ли библиотеки MySQL, используемые вашими приложениями auto_commit по умолчанию или нет.

[Python | mysql-python.sourceforge.net/FAQ.html#my-data-disappeared-or-won-t-go-away], например, не выполняет автоматическую фиксацию. Это означает, что если приложение вставляло строку прямо перед закрытием своего соединения, теперь вставка будет отменена после того, как вы перейдете к innodb. Например, для скрипта python необходимо обязательно вызвать connection.commit ();

Еще одна точка различия может быть вокруг многострочных вставок или обновлений. Рассмотрим один многострочный слой

вставить в значения tbl (. row1 . ), (. row2 . ), (. rowN . );

Рассмотрим, что произойдет, если есть некоторая ошибка, такая как уникальное столкновение ключей в строке3. С MyISAM первые две строки были бы написаны, в соответствии с innodb все написанные строки будут отброшены назад, оставив ничего, что написано даже в такой ошибке.

С innodb вы войдете в мир тупиков. Они не являются по своей сути плохими, если они не встречаются с такой частотой, чтобы предотвратить любую работу. Однако ваши приложения должны быть закодированы таким образом, что они ожидают взаимоблокировки и обрабатывают их соответствующим образом (что, скорее всего, означает просто повторить попытку).

Учитывайте ограничения памяти /хранилища. Innodb намного более ресурсоемкий, чем MyISAM. Если у вас достаточно ОЗУ, чтобы ваши буферные пулы были достаточно большими, чтобы разместить все ваши таблицы, тогда вы золотые.

Ищите таблицы с большими первичными ключами. Индексирование кластеров Innodb означает, что каждый вторичный индекс содержит другую копию PK соответствующей строки. Если у вас есть 2 вторичных индекса, которые означают, что каждая строка PK хранится 3 раза (PK + каждый индекс). Если pk охватывает несколько столбцов и больших типов данных (например, char (N)), вы можете увидеть, как требования индекса могут быстро взорваться под innodb.

Мастер Йода рекомендует:  Как выучить Git с нуля
Добавить комментарий
07.03.2014, 12:39 #9