Что лучше myisam или innodb

Что лучше myisam или innodb

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

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

Отличия InnoDB от MyISAM

Главное преимущество 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:

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

innodb_file_per_table = 1;

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

Источник

Сравнение движков InnoDB и MyISAM

MySQL поддерживает два самых популярных движка InnoDB и MyISAM, но в чем же их отличия?

Давайте посмотрим более подробно и более понятно.

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

Более детальное описание терминов:
Транзакция (Transaction) – блок операторов SQL, который в случае ошибки в одном запросе, возвращается к предыдущему состоянию (Rollback), и только в случае выполнения всех запросов подтверждается (Commit);
Внешние ключи – это способ связать записи в двух таблицах по определенным полям так, что при обновлении поля в родительской автоматически происходит определенное изменение поля в дочерней (создается ключ в дочерней таблице, который ссылается на родительскую);
Блокировка на уровне строк — в ситуации когда процессу нужно обновить строку в таблице, то он блокирует только эту строку, позволяя другим обновлять другие строки параллельно;
Deadlock — ситуация в многозадачной среде или СУБД, при которой несколько процессов находятся в состоянии бесконечного ожидания ресурсов, захваченных самими этими процессами;

Выводы:
1. MyISAM стоит использовать, если нужен полнотекстовый поиск до версии MySQL 5.6.4
2. MyISAM подойдет, когда в таблице очень мало записей и большое количество чтений.
3. Во всех остальных случаях нужно использовать InnoDB.

На этом все, до скорых встреч. Если у Вас возникли вопросы или Вы хотите чтобы я помог Вам, то Вы всегда можете связаться со мной разными доступными способами.

Источник

Технарь

Блог о программировании и околопрограммерских штуках.

MySQL: отличия между MyISAM и InnoDB

Отличия между системами хранения данных MyISAM и InnoDB простым языком.

В данной таблице я попробовал показать разницу между MyISAM и InnoDB на простых примерах:

Выводы:

Что можно еще добавить? Что не понятно?

MySQL: отличия между MyISAM и InnoDB : 26 комментариев

Не хватает кратких итогов от автора 🙂

Шикарное сравнение, лучшее что находил на эту тему

Спасибо за статью! Приятно читать.

MySQL версия 5.6 К ключевым улучшения можно отнести: поддержка средств полнотекстового поиска, возможность доступа к данным через memcached API, увеличена производительность работы при интенсивной записи данных, а также увеличена масштабируемость при обработке большого числа одновременных запросов.

Четко, ёмко, понятно. Пять баллов!

Спасибо!
Очень доступно написано!

Добавьте в вывод, что MyISAM надо использовать, когда нужен полнотекстовой поиск

Бинарное копирование:
… Базу данных InnoDB можно перенести, просто скопировав все относящиеся к ней файлы … (7.5.7 Перенесение базы данных InnoDB на другой компьютер)

Лаконично и понятно.хорошая работа

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

Ну как бы никто не запрещает в одной БДе использовать и MyISAM и InnoBD… для разных таблиц свои цели…

Привет с 2017!
Спасибо за статью, просто и понятно 🙂

Привет с 2018!
Хорошая статья)

Отличная статья, спасибо!

Из 2019го. Спасибо, помогло детально разобраться.

Внатуре! Большое спасибо! Очень понятно!

Пожалуйста, рад, что Вам пригодилось)

Спасибо за инфу. Как-то не приходилось выбирать между движками, всё работал на поддержке уже готовых проектов. Сейчас стал вопрос с выбором движка для хранения кучи инфы, и но постоянной выборке данных для рендера и логики. Статья помогла, спасибо еще раз!

ДвижОк, а не движек.

привет из 2020. Статья супер. Открла глаза, теперь часть MyISAM, а часть innoDB

Источник

Правильная миграция с MyISAM на InnoDB

Давайте я отвлеку вас от котиков и расскажу, основываясь на своём опыте, какие подводные камни появляются при переходе с MyISAM на InnoDB, и как их избежать. Код приложения будет на PHP.

Этот пост я решил написать, прочитав огромное количество неправильных ответов на запрос из сабжа в интернете. По всему интернету разбросаны неграмотные или не полные ответы, в результате чего складывается впечатление о том, что смигрировать вашу базу данных на InnoDB — это очень просто. Нет, это не просто! Итак, начнем!

Зачем переходить на InnoDB

С этим вопросом, я думаю, всем всё ясно. Объяснять не буду — преимуществам InnoDB посвящены куча статей в интернете. Если ты читаешь эти строки, то значит ты осознанно пришел к этой мысли о переводе своего хозяйства на InnoDB, и ты, хабраюзер, гуглишь) Надеюсь, эта статья — то, что тебе надо.

Подготовительный этап

1. Из банального — это обеспечить необходимое количество свободного места на диске, где у нас развернута база. InnoDB занимает примерно в 1,5 раза больше места, чем MyISAM.

2. Очень важный момент — он вам пригодится в будущем при траблшутинге перформанс ишшусов в базе. Нужно прокомментировать каждый SQL запрос в вашем приложении с использованием уникального идентификатора, например, порядкового номера. Если у вас сотни или тысячи SQL запросов, то как вы жили до сих пор без этого?

Если так сделать, то запросы вида SHOW PROCESSLIST, а также дампы запросов в slow лог файлы будут содержать подсказку для вас — номер SQL запроса, и потом вы мгновенно сможете найти этот запрос в коде и оптимизировать его.

3. Прописываем в конфиг-файле my.cnf:

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

4. Настройка размера кэшей для InnoDB — в том же my.cnf файле:

5. Настройка способа работы базы с транзакциями

Я на своем приложении выставил уровень изоляции транзакций READ-COMMITTED, вместо выставляющегося по умолчанию REPEATABLE-READ, поскольку в противном случае в базе было бы чрезмерное количество дедлоков. Я для себя решил, что мое приложение может прочитать не самые свежие данные, ценой более быстрой работы, вместо абсолютно актуальных данных, но отягощенных множеством блокировок. Впрочем, для mission-критикал транзакции в коде можно повысить её уровень изоляции — этот эффект будет действовать только на одну транзакцию:

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

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

— если этого флага нет, то InnoDB, при наступлении таймаута (Error code 1205) будет откатывать только один этот затаймаутившийся стейтмент в вашей транзакции. То есть, вам нужно будет повторить только его, а не всю транзакцию с начала. Для меня этот вариант показался сложнее в реализации.

— если флаг выставлен, то откатывается вся транзакция, точно так же, как это делается при выявлении дедлока (Error code 1213). Я выбрал именно этот вариант, потому что это позволяет сделать код обработки ошибок унифицированным, т.е. повторять транзакцию с первого стейтмента, с начала, при получении любой из этих двух ошибок.

innodb_log_file_size придется увеличить из-за подводного камня №3 (ниже), поскольку этот лог должен быть достаточным для хранения как минимум нескольких записей, а при наличии записей типа MEDIUMTEXT их размер может превысить несколько мб, поэтому дефолтное значение в 5мб крайне мало. После изменения этого параметра базу нужно остановить, старые файлы ib_logfile0 и ib_logfile1 нужно удалить, и только потом поднимать базу.

Чего бояться в InnoDB

Собственно, в InnoDB нужно внимательно смотреть только за этими двумя кодами ошибок: 1205 (таймаут) и 1213 (дедлок), которых не было в MyISAM. При настройке сервера, приведенной выше, он будет сам откатывать ваши транзакции в обоих случаях. Вам надо будет их повторить сначала. При этом ваш прикладной код может состоять как из отдельных стейтментов — транзакций (при autocommit=1), так и из транзакций, состоящих из нескольких SQL стейтментов — в этом случае транзакция начинается с
и завершается

(Про mysqli_begin_transaction() знаю, но он только для MySQL >= 5.6, а не везде такие новые MySQL сервера).

Если у вас какой-то вызов mysqli_query() не обернут в for($i=0;$i

Источник

Различия индексов MySql, кластеризация, хранение данных в MyIsam и InnoDb

Как устроены индексы в MySql, чем отличается индексирование в двух наиболее популярных движках MyISAM и InnoDb, чем первичные ключи отличаются от простого индекса, что такое кластерные индексы и покрывающие индексы, как с помощью них можно ускорить запросы. Вот как мне кажется наиболее интересные темы которые раскрою в этой статье. Тут же постараюсь подробно раскрыть тему с позиции того как работает этот механизм внутри. Буквально на пальцах и с позиции абстракций а не конкретики. В общем чтоб было минимум текста и максимум понятно.

Что представляет из себя индекс в MySql

Скорость чтения из индекса

Отличия в индексах MyISAM и InnoDb

Первичные и «вторичные» индексы в чем отличия

Вводная информация

Что представляет из себя индекс в MySql

На рисунке изобразил схематично как устроен индекс. Имеются узловые элементы (квадраты) и листья (круги). Предположим у нас есть таблица с колонками «Val» и «ID» как на рисунке. В этой таблице индекс построен по числовому полю «ID». Тогда получается что в узловых элементах находятся значения индекса и ссылки на другой более нижний узел или лист. В листовых же элементах точно так же лежат значения индекса которые уже ссылаются непосредственно на данные из таблицы.

Процесс поиска происходит примерно следующим образом. Например нужно найти строку с индексом 11.

начинаем просмотр корневого (верхнего) узла

первое значение в нем 10

идем к следующему 19, оно уже больше чем нам нужно

по ссылке слева от 19 переходим к следующему нижнему узлу

там первое значение 13, оно больше чем нам нужно

опять по ссылке слева переходим к более нижнему элементу

это уже будет листовой элемент, в нем уже лежат непосредственно данные

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

переходим по ссылке непосредственно к строке в таблице.

Скорость чтения из индекса

Такое устройство индекса позволяет обеспечить логарифмическую скорость поиска O(log n). Это очень быстро. Вот таблица где для наглядности посчитал сколько сравнений нужно сделать для поиска записи в таблице с разным количеством данных:

Количество элементов в таблице

Количество сравнений

Отличия в индексах MyISAM и InnoDb

MyIsam это более старый движок чем InnoDb и все описанное выше хорошо описывает устройство индекса именно в MyIsam. Более того для MyIsam можно сказать что первичный индекс и просто обычный индекс ни чем между собой не отличаются. В целом таблицы построенные на движке MyIsam вполне себе могут существовать даже без первичного ключа и без всякого индекса в целом. А вот InnoDb уже более свежий и продвинутый движок, и тут как раз есть отличия первичного ключа и просто индекса. Создать таблицу InnoDb тоже можно не указав первичный ключ, но в этом случае первичный ключ все равно создастся. Это называется суррогатный первичный ключ. InnoDb сам выберет поле по которому нужно этот ключ создать, если ни одно поле не подходит, то создаст новое числовое поле, которое конечно же будет скрыто и в структуре его не увидеть. Для разбора индексов InnoDb первым делом нужно начать с кластеризации.

Кластерный индекс

Кластерный индекс отличается тем, что в отличии от предыдущей картинки, где от листьев шли ссылки непосредственно на строки в таблице, тут все данные строк хранятся непосредственно в самом индексе. Проиллюстрировал это на примере листьев 10, 11, 12. Это хорошо тем что позволяет избежать лишнего чтения диска при переходе по ссылке от листа на данные в строке. Тут непосредственно вся строка лежит в индексе. То есть получается что в InnoDb при создании таблицы и указании первичного ключа будет построено такое дерево, в котором все данные таблицы будут продублированы в листья индекса. Если первичный ключ не задать то колонка для него будет выбрана или создана автоматически и все равно по ней будет построен кластерный индекс.

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

Первичные и «вторичные» индексы в чем отличия

Выше было оговорено что для MyIsam нет разницы между первичными и «вторичными» ключами.

Первичный и вторичный индекс в MyIsam

На картинке нарисован первичный и вторичный ключ в MyIsam. Первичный ключ построен по полю «ID», вторичный по полю «Val». Видно что их структура одинакова. И в том и в другом в листьях расположены значения индекса и ссылки на строки в таблице.

В InnoDb это устроено немного по другому.

Первичный и вторичный индекс в InnoDb

Как уже говорил, таблица тут просто для наглядности. Все ее данные хранятся в первичном (кластерном ключе). Тут первичный ключ построен по полю «Id», вторичный по полю «Val». Видно что в листьях первичного ключа лежат значения индекса + все данные из строк таблицы. Во вторичном же ключе, в листьях лежат значения ключа + первичный ключ.

Можно резюмировать что для MyIsam нет различий между первичным и вторичными индексами. Для InnoDb первичный ключ содержит в себе все данные таблицы, вторичный же ключ содержит значения ключа плюс значение первичного ключа. Получается что при поиске по вторичному ключу, поиск будет произведен дважды. Первый раз непосредственно по самому индексу, будет найдено значение первичного индекса. И уже второй раз по найденому первичному индексу для поиска данных всей строки.

Покрывающие индексы

Смысл покрывающих индексов в том, что MySql может вытаскивать данные непосредственно из самого индекса, не читая при этом всю строку и вовсе не читая строку. Для такой оптимизации нужно чтобы все поля указанные в SELECT имелись в индексе. То есть например у нас имеется таблица с полями «id», «name», «surname», «age», «address». И мы проиндексировали ее по полю «id». В запросе мы хотим получить например «id» и «name». При таком условии MySql найдет по первичному ключу нужную строку, прочитает ее и отбросит все поля не указанные в SELECT. Если же мы немного оптимизируем этот запрос и построим индкес по двум полям «id» и «name», то в таком случае MySql найдя нужную строку по этому индексу не пойдет читать всю эту строку, а просто возьмет данные, которые нужны непосредственно из индекса. Правда есть обратная сторона такого подхода, а именно размер индекса в этом случае будет больше, по этому нужно грамотно подходить к построению покрывающих индексов.

Более подробно можно почитать в очень хорошей книге «MySQL по максимуму» Бэрон Шварц, Петр Зайцев, Вадим Ткаченко

Источник