Почему InnoDB хранит все базы данных в одном файле?

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

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

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

50 голосов | спросил Googlebot 25 MarpmSun, 25 Mar 2012 17:49:16 +04002012-03-25T17:49:16+04:0005 2012, 17:49:16

3 ответа


63

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

  • Страницы данных таблицы
  • Табличные индексы страниц
  • Таблица MetaData
  • MVCC Данные (для поддержки изоляции транзакций и Соответствие ACID )
    • Откат сегментов
    • Отменить пробел
    • Буфер с двойной записью (фоновая запись для предотвращения использования кэширования ОС)
    • Вставить буфер (управление изменениями для неспецифических вторичных индексов)

См. графическое представление ibdata1

По умолчанию innodb_file_per_table отключен , Это приводит к тому, что все четыре типа информации страницы выгружают один файл с именем ibdata1. Многие люди пытаются распространять данные, создавая несколько файлов ibdata. Это может привести к фрагментации страниц данных и индексов.

Вот почему я часто рекомендую очистить инфраструктуру InnoDB, используя файл ibdata1 по умолчанию и не более .

Копирование очень опасно из-за инфраструктуры, в которой работает InnoDB. Существуют две основные инфраструктуры

  • innodb_file_per_table отключен
  • включен innodb_file_per_table

InnoDB ( innodb_file_per_table отключен)

С innodb_file_per_table отключены, все эти типы информации InnoDB живут в пределах ibdata1. Единственным проявлением любой таблицы InnoDB за пределами ibdata1 является файл .frm таблицы InnoDB. Копирование всех данных InnoDB сразу требует копирования всех /var /lib /mysql.

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

InnoDB ( innodb_file_per_table включен)

С innodb_file_per_table включен, данные таблицы и его индексы живут в папке базы данных рядом с файлом .frm. Например, для таблицы db1.mytable проявление этой таблицы InnoDB за пределами ibdata1 будет:

  • /var/lib/mysql/db1/mytable.frm
  • /var/lib/mysql/db1/mytable.ibd

Системное табличное пространство ibdata1

Все метаданные для db1.mytable все еще находятся в ibdata1 и нет абсолютно никакого пути вокруг этого . Повторные журналы и данные MVCC также по-прежнему живут с ibdata1.

Когда дело доходит до фрагментации таблицы, вот что происходит с ibdata1:

  • innodb_file_per_table включен : вы можете уменьшить db1.mytables с помощью ALTER TABLE db1.mytable ENGINE = InnoDB; или OPTIMIZE TABLE db1.mytable; . Это приводит к тому, что /var/lib/mysql/db1/mytable.ibd физически меньше без фрагментации.
  • innodb_file_per_table отключен : вы не можете сжимать db1.mytables с помощью ALTER TABLE db1.mytable ENGINE = InnoDB; или OPTIMIZE TABLE db1.mytable; , потому что он находится в ibdata1. Выполняя любую команду на самом деле, сделайте таблицу смежной и быстрой для чтения и записи. К сожалению, это происходит в конце ibdata1. Это делает ibdata1 быстро расти. Это полностью разрешено в моей учетной записи очистки InnoDB .

ПРЕДУПРЕЖДЕНИЕ (или ОПАСНО как робот скажет в Lost in Space )

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

Я написал две записи вDBA StackExchange об этой концепции идентификатора табличного пространства

Вот отличная ссылка о том, как повторно подключить любой .ibd-файл к ibdata1 в случае несогласованных идентификаторов табличного пространства: http://www.chriscalender.com/?tag=innodb-error-tablespace-id-in-file . Прочитав это, вы должны сразу понять, что копирование файлов .ibd просто безумно.

Для InnoDB вам нужно только что-то переместить

  CREATE TABLE db2.mytable LIKE db1.mytable;
INSERT INTO db2.mytable SELECT * FROM db1.mytable;
 

сделать копию таблицы InnoDB.

Если вы переносите его на другой сервер БД, используйте mysqldump.

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

ответил RolandoMySQLDBA 26 MaramMon, 26 Mar 2012 01:28:33 +04002012-03-26T01:28:33+04:0001 2012, 01:28:33
14

Вы можете переключать InnoDB на хранение таблиц на файл, добавив файл innodb-per-table в ваш cnf.

Innodb действительно просто заботится о страницах данных на базовом уровне. Фактически, вы можете настроить InnoDB на использование только необработанного блочного устройства без файловой системы. http://dev.mysql.com/doc/refman /5.5/en/innodb-raw-devices.html

Есть удобства для хранения таблиц для файла, таких как возможность более легко восстановить использованное пространство с помощью оптимизации.

Даже с файлами на таблицу вы не можете просто копировать файлы ibd так легко, так как InnoDB является транзакционным и хранит информацию о его состоянии в общедоступных файлах ibdata /log.

Это не значит, что это невозможно. Если таблица находится в автономном режиме, вы можете отменить /импортировать табличные пространства и скопировать .idbs вокруг http://dev.mysql.com/doc/refman/5.5/en/innodb-multiple-tablespaces.html

ответил atxdba 25 MarpmSun, 25 Mar 2012 18:55:22 +04002012-03-25T18:55:22+04:0006 2012, 18:55:22
10

Это поведение по умолчанию, но не обязательное. Из Документов MySQL, используя таблицы табличных таблиц :

  

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

Что касается причин, вероятно, это разные архитектуры двух двигателей (MyISAM и InnoDB). Например, в InnoDB вы не можете просто скопировать файл .ibd в другую базу данных или установку. Объяснение (с той же страницы):

  

Соображения переносимости для .ibd-файлов

     

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

ответил ypercubeᵀᴹ 25 MarpmSun, 25 Mar 2012 18:55:54 +04002012-03-25T18:55:54+04:0006 2012, 18:55:54

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132