Innodb что это

MySQL — выбираем тип хранения данных MyISAM или InnoDB

Самые популярные типы хранение в базе MySQL — это MyISAM и InnoBD. Неправильный выбор типа хранения приводит к тем же последствиям, что и неправильная структура таблиц, неправильные индексы и неправильные запросы. Тобишь – к падению производительности.

Самыми популярными на сегодня являются MyISAM и InnoDB.

MyISAM интересен тем, что дает просто безумную скорость на select-ах и insert-ах. С другой стороны, он не поддерживает транзакционность и блокировку на уровне строк, что в свою очередь приводит к страшным тормозам при использовании delete\update. Проще говоря, на таблицу допускается только одна одновременная delete или update операция, и остальные вынуждены ждать завершения текущей операции, что на больших объемах данных приводит к серьезным проблемам.

К преимуществам движка можно отнести поддержку полнотекстовый поиск, компрессию и GIS функции. Под хранение каждой таблицы отводятся два файла – имя_таблицы.MYD ( данные ) и имя_таблицы.MYI ( индексы ). Формат данных платформенно независимый, что позволяет переносить данные с сервера на сервер простым копированием таблиц – это еще один плюс.

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

Кроме транзакционности, к преимуществам этого движка можно отнести row-level блокировки, правда тут стоит учесть тот факт, что table-level блокировки тоже имеют место быть, например при использовании автоинкрементных полей. С этим борятся и время от времени выходят фиксы, уменьшающие количество table-level блокировок, но никто не отменял регулярный просмотр логов на предмет проблем с блокировками.

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

Что может повлиять на выбор тиха хранения данных? Ну во-первых необходимость транзакционности, ибо если пишется серьезный финансовый софт, например тот же биллинг или процессинг, то тут майсам использовать никак нельзя.

Кроме того, специфика работы с данными, накладывает свой отпечаток на выбор движка. Если речь идет о какой-то статистике, которую все просто напросто просматривают, то лучше майсам с этим никто не справится.

Про конкурентность забывать тоже не стоит. Если работа с данными идет всего в несколько потоков, то это вполне может нивелировать недостатки myisam в плане update\delete в пользу быстрых select.

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

• Многие жалуются на частые поломки MyISAM. Лично мне ни разу не доводилось с этим сталкиваться, потому ничего не могу сказать по этому поводу. Но надежность данных – это еще один аргумент в пользу innodb, который и крешит реже и восстанавливается быстрее.
• Каждый движок требует свой “кусок пирога”. Мало перекинуть данные в myisam – нужно чтобы сервер был сконфигурирован так, чтобы этому движку было выделено достаточно ресурсов, иначе поимеем те же самые тормоза. Впрочем, сводных данных для отчетов по статистике не обязательно будет много!
• Если данных немного, например той же статистики, то можно использовать тот же движок что и вся остальная база. По крайней мере лишите себя гемора поддержки двух движков.

Innodb что это

Таблицы InnoDB в MySQL снабжены обработчиком таблиц, обеспечивающим безопасные транзакции (уровня ACID ) с возможностями фиксации транзакции, отката и восстановления после сбоя. Для таблиц InnoDB осуществляется блокировка на уровне строки, а также используется метод чтения без блокировок в команде SELECT (наподобие применяющегося в Oracle). Перечисленные функции позволяют улучшить взаимную совместимость и повысить производительность в многопользовательском режиме. В InnoDB нет необходимости в расширении блокировки, так как блоки строк в InnoDB занимают очень мало места. Для таблиц InnoDB поддерживаются ограничивающие условия FOREIGN KEY .

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

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

Свежую информацию по InnoDB можно найти на http://www.innodb.com/. Здесь же находится последняя версия руководства по InnoDB. Кроме того, можно заказать коммерческие лицензии и поддержку для InnoDB.

В настоящий момент (октябрь 2001 года) таблицы InnoDB применяются на нескольких больших сайтах баз данных, для которых важна высокая производительность. Так, таблицы InnoDB используются на популярном сайте новостей Slashdot.org. Формат InnoDB применяется для хранения более 1Тб данных компании Mytrix, Inc; можно привести пример еще одного сайта, где при помощи при помощи InnoDB обрабатывается средняя нагрузка объемом в 800 вставок/обновлений в секунду.

Таблицы InnoDB входят в дистрибутив исходных текстов MySQL, начиная с версии 3.23.34a; они активизированы в исполняемом коде MySQL -Max. Для Windows исполняемые коды -Max находятся в стандартном дистрибутиве.

Если вы загрузили исполняемую версию MySQL, которая включает поддержку InnoDB, следует просто выполнить инструкции руководства MySQL по установке исполняемой версии MySQL. В случае, если у вас уже установлен MySQL-3.23, проще всего установить MySQL -Max, чтобы заменить исполняемый файл `mysqld' соответствующим файлом из дистрибутива -Max. Различными в MySQL и MySQL -Max являются только исполняемые файлы сервера. См. разделы section 2.2.10 Установка бинарного дистрибутива MySQL и See section 4.7.5 mysqld-max , расширенный сервер mysqld .

Чтобы произвести компиляцию MySQL с поддержкой InnoDB, загрузите MySQL-3.23.34a или более новую версию с http://www.mysql.com/ и настройте MySQL при помощи параметра —with-innodb . См. раздел руководства MySQL по установке дистрибутива исходного кода MySQL, See section 2.3 Установка исходного дистрибутива MySQL.

cd /path/to/source/of/mysql-3.23.37 ./configure --with-innodb

Чтобы использовать InnoDB, необходимо указать параметры запуска InnoDB в своем файле `my.cnf' или `my.ini'. Самый простой способ внести изменения — добавить в раздел [mysqld] строку

innodb_data_file_path=ibdata:30M

Однако чтобы добиться высокой скорости работы, лучше указать рекомендуемые параметры. See section 7.5.2 Параметры запуска InnoDB.

InnoDB распространяется на условиях общедоступной лицензии версии 2 (от июня 1991 года). В дистрибутиве исходного кода MySQL InnoDB находится в подкаталоге `innobase'.

InnoDB

InnoDB — одна из выбираемых подсистем низкого уровня в СУБД MySQL, входит во все стандартные сборки для различных операционных систем. Основным отличием InnoDB от других подсистем низкого уровня MySQL является наличие механизма транзакций и внешних ключей.

СУБД InnoDB была разработана Хейкки Туури (фин. Heikki Tuuri ) из компании Innobase — финского производителя программного обеспечения, специализирующегося на технологии реляционных баз данных. InnoDB представляет собой результат исследований, проводимых Хейкки в университете Хельсинки. После поглощения Innobase в 2005, InnoDB стала продуктом Sun Microsystems, впоследствии поглощённой Oracle Corporation [2] . Поддержка InnoDB появилась в MySQL версии 3.23, а начиная с версии 5.5 стал основным хранилищем по умолчанию [3] . Сама СУБД доступна на условиях открытой лицензии.

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

В последнее время из-за излишней закрытости разработки MySQL компанией Sun Microsystems, появилось много сторонних (например, от компании Google) патчей с улучшениями производительности и исправлениями ошибок, большинство из которых были включены в форк InnoDB под названием XtraDB [4] , созданный компанией Percona [источник не указан 660 дней] .

Примечания

1. ↑InnoDB Website » Products » InnoDB » License
2. ↑Oracle Announces the Acquisition of Open Source Software Company, Innobase. Oracle. Архивировано из первоисточника 18 февраля 2012.Проверено 31 июля 2008.
3. ↑What Is New in MySQL 5.5. Архивировано из первоисточника 18 февраля 2012.Проверено 15 декабря 2010.
4. ↑Understanding the MySQL forks «XtraDB draws a lot from the Google patches for MySQL/InnoDB»

Ссылки

• innodb.com (англ.)

• Найти и оформить в виде сносок ссылки на авторитетные источники, подтверждающие написанное.

14.2.1.1. InnoDB как Механизм Хранения MySQL Default

У MySQL есть заслуженная репутация быть удобным в работе и поставить производительность и масштабируемость. В предыдущих версиях MySQL MyISAM был механизмом хранения значения по умолчанию. В нашем опыте, большинство пользователей, никогда изменяемых настройки по умолчанию. С MySQL 5.5 InnoDB становится механизмом хранения значения по умолчанию. Снова, мы ожидаем, что большинство пользователей не будет изменять настройки по умолчанию. Но из-за InnoDB поставляют настройки по умолчанию, пользователи преимуществ ожидают от их RDBMS: Транзакции ACID, Ссылочная целостность, и Восстановление Катастрофического отказа. Давайте исследовать, как использование таблиц InnoDB улучшает Вашу жизнь как пользователя MySQL, DBA, или разработчика.

Тенденции в Использовании Механизма Хранения

В первых годах роста MySQL ранние веб-приложения не продвигали пределы параллелизма и доступности. В 2010 объем жесткого диска и емкость памяти и отношение производительности/цены все прошли через крышу. Пользователи, продвигающие границы производительности MySQL, заботятся много о восстановлении надежности и катастрофического отказа. Базы данных MySQL являются большими, занятыми, устойчивыми, распределяются, и важны.

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

MySQL продолжает работать над адресацией вариантов использования, которые прежде потребовали таблиц MyISAM. В MySQL 5.6 и выше:

• InnoDB может выполнить полнотекстовый поиск, используя FULLTEXT индексируйте тип. См. Раздел 14.2.3.12.3,» FULLTEXT Индексирует» для деталей.
• InnoDB теперь выполняет лучше с рабочими нагрузками чтения главным образом или только для чтения. Автоматическая оптимизация применяется к запросам InnoDB в режиме автоматической фиксации, и можно явно отметить транзакции как только для чтения с синтаксисом START TRANSACTION READ ONLY . См. Раздел 14.2.4.2.3, «Оптимизация для Транзакций Только для чтения» для деталей.
• Приложения, распределенные на носителях только для чтения, могут теперь использовать таблицы InnoDB. См. Раздел 14.2.5.1, «Поддержка Носителей Только для чтения» для деталей.

Последствия InnoDB как Механизм Хранения MySQL Default

Запускаясь с MySQL 5.5.5, механизмом хранения значения по умолчанию для новых таблиц является InnoDB. Это изменение применяется к недавно составленным таблицам, которые не определяют механизм хранения с пунктом такой как ENGINE=MyISAM . (Данный это изменение поведения значения по умолчанию, MySQL 5.5 мог бы быть логической точкой, чтобы оценить, могли ли Ваши таблицы, которые действительно используют MyISAM, извлечь выгоду от переключения до InnoDB.)

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

Преимущества Таблиц InnoDB

Если Вы используете MyISAM таблицы, но не связываются к ним для технических причин, Вы сочтете много вещей более удобными, когда Вы будете использовать InnoDB таблицы в MySQL 5.5:

• Если Ваш сервер отказывает из-за аппаратных средств или проблемы программного обеспечения, независимо от того, что происходило в базе данных в то время, Вы не должны сделать ничего специального после перезапуска базы данных. Восстановление катастрофического отказа InnoDB автоматически завершает любые изменения, которые фиксировались перед временем катастрофического отказа, и отменяет любые изменения, которые были в процессе, но не фиксировали. Только перезапустите и продолжайте, где Вы кончили. Этот процесс теперь намного быстрее чем в MySQL 5.1 и ранее.
• Таблица кэшей пула буферов InnoDB и индексирует данные, поскольку к данным получают доступ. Часто используемые данные обрабатываются непосредственно из памяти. Этот кэш применяется к очень многим типам информации, и ускоряет обработку так, что выделенные серверы баз данных присваивают до 80 % своей физической памяти к пулу буферов InnoDB.
• Если Вы разделяете связанные данные на различные таблицы, можно установить внешние ключи, которые осуществляют ссылочную целостность. Обновите или удалите данные, и связанные данные в других таблицах обновляются или удаляются автоматически. Попытайтесь вставить данные во вторичную таблицу без соответствующих данных в первичной таблице, и неправильные данные выгоняются автоматически.
• Если данные становятся поврежденными на диске или в памяти, механизм контрольной суммы предупреждает Вас к поддельным данным прежде, чем Вы будете использовать это.
• Когда Вы разрабатываете свою базу данных с соответствующими столбцами первичного ключа для каждой таблицы, операции, включающие те столбцы, автоматически оптимизируются. Это очень быстро, чтобы сослаться на столбцы первичного ключа в WHERE пункты, ORDER BY пункты, GROUP BY пункты, и операции соединения.
• Вставляет, обновления, удаляет, оптимизируются автоматическим механизмом, названным буферизацией изменения. InnoDB не только позволяет параллельный доступ для чтения и доступ для записи к той же самой таблице, это кэширует измененные данные, чтобы оптимизировать дисковый ввод-вывод.
• Выигрыши в производительности не ограничиваются гигантскими таблицами с продолжительными запросами. То, когда к тем же самым строкам получают доступ много раз от таблицы, функция, названная Адаптивным Хешем, Индексируют, вступает во владение, чтобы сделать эти поиски еще быстрее, как будто они вышли из хэш-таблицы.

Лучшие Методы для Таблиц InnoDB

Если Вы использовали InnoDB в течение долгого времени Вы уже знаете о функциях как транзакции и внешние ключи. В противном случае читайте о них всюду по этой главе. Короче говоря:

• Определите первичный ключ для каждой таблицы, используя наиболее часто запрашиваемый столбец или столбцы, или значение anauto-инкремента, если нет никакого очевидного первичного ключа.
• Охватите идею соединений, где данные вытягивают от многократных таблиц, основанных на идентичных Значениях идентификаторов от тех таблиц. Для быстрой производительности соединения определите внешние ключи на объединяющих столбцах, и объявите те столбцы с тем же самым типом данных в каждой таблице. Внешние ключи также распространяют, удаляет или обновляет ко всем таблицам, на которые влияют, и предотвратите вставку данных в дочерней таблице, если соответствующие ID не присутствуют в родительской таблице.
• Выключите автоматическую фиксацию. Фиксация сотен времен в секунду помещает прописную букву в производительность (ограниченный скоростью записи Вашего устройства хранения).
• Групповые наборы связанных операций DML в транзакции, заключая в скобки их с START TRANSACTION и COMMIT операторы. В то время как Вы не хотите фиксировать слишком часто, Вы также не хотите выпускать огромные пакеты INSERT , UPDATE , или DELETE операторы, которые работают в течение многих часов без фиксации.
• Прекратите использовать LOCK TABLE операторы. InnoDB может обработать многократные сеансы все чтение и запись в ту же самую таблицу сразу, не жертвуя надежностью или высокой производительностью. Чтобы получить монопольный доступ для записи к ряду строк, используйте SELECT . FOR UPDATE синтаксис, чтобы заблокировать только строки Вы намереваетесь обновить.
• Включите innodb_file_per_table опция, чтобы поместить данные и индексирует для отдельных таблиц в отдельные файлы, вместо в единственной гигантской системной табличной области. (Эта установка обязана использовать некоторые из других функций, таких как табличное сжатие и быстрое усечение.)
• Оцените, извлекают ли Ваши данные и схемы доступа выгоду из новой табличной функции сжатия InnoDB ( ROW_FORMAT=COMPRESSED на CREATE TABLE оператор. Можно сжать таблицы InnoDB, не жертвуя возможностью чтения-записи.
• Выполните свой сервер с опцией —sql_mode=NO_ENGINE_SUBSTITUTION предотвратить таблицы, создаваемые с различным механизмом хранения, если есть проблема с той, определенной в ENGINE= пункт CREATE TABLE .

Недавние Улучшения для Таблиц InnoDB

• Можно сжать таблицы, и связанный индексирует.
• Можно создать, и отбрасывание индексирует с намного меньшим количеством производительности или воздействия доступности чем прежде.
• Усечение таблицы очень быстро, и может освободить дисковое пространство для операционной системы к повторному использованию, вместо того, чтобы освободить пространство в пределах системной табличной области, которую только мог снова использовать InnoDB.
• Расположение хранения для табличных данных более эффективно для BLOB и длинных текстовых полей, с DYNAMIC формат строки.
• Можно контролировать внутренние работы механизма хранения, запрашивая INFORMATION_SCHEMA таблицы.
• Можно контролировать детали производительности механизма хранения, запрашивая performance_schema таблицы.
• Есть много много улучшений производительности. В частности восстановление катастрофического отказа, автоматический процесс, который делает все данные непротиворечивыми, когда база данных перезапускается, быстро и надежно. (Теперь очень намного быстрее чем долговременный InnoDB пользователи привыкли к.), Чем больше база данных, тем более существенный ускорение. Самые новые технические характеристики являются автоматическими, или самое большее требуют установки значения для параметра конфигурации. Для получения дополнительной информации см. Раздел 14.2.4.2,» InnoDB Производительность и Улучшения Масштабируемости». Для InnoDB-специфичных настраивающих методов можно применяться в своем коде программы, видеть Раздел 8.5, «Оптимизируя для InnoDB Таблицы». Усовершенствованные пользователи могут рассмотреть Раздел 14.2.6,» InnoDB Опции запуска и Системные Переменные».

Тестирование и Сравнительное тестирование с InnoDB как Механизм Хранения Значения по умолчанию

Даже прежде, чем завершить Ваше обновление от MySQL 5.1 или ранее к MySQL 5.5 или выше, можно предварительно просмотреть, работают ли Ваш сервер базы данных или приложение правильно с InnoDB как механизм хранения значения по умолчанию. Чтобы установить InnoDB как механизм хранения значения по умолчанию с более ранним выпуском MySQL, любой определяет на командной строке —default-storage-engine=InnoDB , или добавьте к Вашему my.cnf файл default-storage-engine=innodb в [mysqld] раздел, затем перезапустите сервер.

Начиная с изменения механизма хранения значения по умолчанию только влияет на новые таблицы, поскольку они создаются, выполняют всю Вашу установку приложения и устанавливают шаги, чтобы подтвердить, что все устанавливает должным образом. Затем осуществите все функции приложения, чтобы удостовериться вся загрузка данных, редактирование, и запросы работы функций. Если таблица положится на некоторую MyISAM-специфичную функцию, то Вы получите ошибку; добавьте ENGINE=MyISAM пункт к CREATE TABLE оператор, чтобы избежать ошибки. (Например, таблицы, которые полагаются на полнотекстовый поиск, должны быть таблицами MyISAM, а не InnoDB.)

Если Вы не принимали преднамеренное решение относительно механизма хранения, и Вы только хотите предварительно просмотреть, как определенные таблицы работают, когда они создаются под InnoDB, дают команду ALTER TABLE table_name ENGINE=InnoDB; для каждой таблицы. Или, чтобы выполнить тестовые запросы и другие операторы, не нарушая исходную таблицу, сделайте копию как так:

CREATE TABLE InnoDB_Table (. ) ENGINE=InnoDB AS SELECT * FROM MyISAM_Table;

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

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

Протестируйте любые конфигурации репликации, особенно если Вы используете различные версии MySQL и опции на ведущем устройстве и ведомых устройствах.

Проверка, что InnoDB является Механизмом Хранения Значения по умолчанию

Знать, каково состояние InnoDB, делаете ли Вы что — тестируя с более старым MySQL или при всестороннем тестировании с последним MySQL:

• Дайте команду SHOW ENGINES; видеть все различные механизмы хранения MySQL. Искать DEFAULT в строке InnoDB.
• Если InnoDB не присутствует вообще, у Вас есть a mysqld двоичный файл, который был скомпилирован без поддержки InnoDB и Вы должны получить различный.
• Если InnoDB присутствует, но отключенный, возвратитесь через свои опции запуска и конфигурационный файл и избавьтесь от любого skip-innodb опция.