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

Когда Использовать MEMORY или MySQL Cluster. Разработчики, надеющиеся развертывать приложения, которые используют MEMORY механизм хранения для важных, высоконадежных, или часто обновляемых данных должен рассмотреть, является ли MySQL Cluster лучшим выбором. Типичный вариант использования для MEMORY механизм включает эти характеристики:

MySQL Cluster предлагает те же самые функции как MEMORY механизм с более высокими уровнями производительности, и обеспечивает дополнительные функции, не доступные с MEMORY:

Для отчета с более подробным сравнением MEMORY механизм хранения и MySQL Cluster, см. Масштабирующиеся Веб-сервисы с MySQL Cluster: Альтернатива MySQL Memory Storage Engine. Этот отчет включает исследование качества работы этих двух технологий и пошагового руководства, описывающего как существующий MEMORY пользователи могут перейти на MySQL Cluster.

Показатели производительности

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

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

В зависимости от видов запросов, выполняемых на a MEMORY таблица, Вы могли бы создать, индексирует как любой структура данных хеша значения по умолчанию (для того, чтобы искать единственные значения, основанные на уникальном ключе), или структура данных B-дерева общего назначения (для всех видов запросов, включающих равенство, неравенство, или операторы диапазона, такие как меньше чем или больше чем). Следующие разделы иллюстрируют, что синтаксис для того, чтобы создать оба вида индексирует. Общая проблема производительности использует хеш значения по умолчанию, индексирует в рабочих нагрузках, где B-дерево индексирует, более эффективны.

Физические характеристики MEMORY Таблицы

MEMORY механизм хранения связывает каждую таблицу с одним дисковым файлом, который хранит табличное определение (не данные). Имя файла начинается с имени таблицы и имеет расширение .frm.

MEMORY у таблиц есть следующие характеристики:

Операции DDL для MEMORY Таблицы

Создать a MEMORY таблица, определите пункт ENGINE=MEMORY на CREATE TABLE оператор.

CREATE TABLE t (i INT) ENGINE = MEMORY;

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

Этот пример шоу, как Вы могли бы создать, используйте, и удалите a MEMORY таблица:

mysql> CREATE TABLE test
        ENGINE=MEMORY    ->     SELECT ip,SUM(downloads) AS
        down    ->     FROM log_table GROUP BY ip;mysql> SELECT COUNT(ip),AVG(down) FROM test;mysql> DROP TABLE test;

Максимальный размер MEMORY таблицы ограничиваются max_heap_table_size системная переменная, у которой есть значение по умолчанию 16 МБ. Осуществлять различные пределы размера для MEMORY таблицы, измените значение этой переменной. Значение в действительности для CREATE TABLE, или последующее ALTER TABLE или TRUNCATE TABLE, значение, используемое для жизни таблицы. Перезапуск сервера также устанавливает максимальный размер существующих MEMORY таблицы к глобальной переменной max_heap_table_size значение. Можно установить размер для отдельных таблиц как описано позже в этом разделе.

Индексирует

MEMORY механизм хранения поддерживает обоих HASH и BTREE индексирует. Можно определить один, или другой для данного индексирует, добавляя a USING пункт как показано здесь:

CREATE TABLE lookup    (id INT, INDEX USING HASH (id))    ENGINE = MEMORY;CREATE TABLE lookup    (id INT, INDEX USING BTREE (id))    ENGINE = MEMORY;

Поскольку общие характеристики B-дерева и хеша индексируют, см. Раздел 8.3.1, "Использование MySQL How Индексирует".

MEMORY таблицы могут иметь, до 64 индексируют на таблицу, 16 столбцов на индексируют и максимальная длина ключа 3072 байтов.

Если a MEMORY табличный хеш индексирует, имеет высокую степень ключевого дублирования (много элементов индекса, содержащих то же самое значение), обновления к таблице, которые влияют на значения ключа и все удаляет, значительно медленнее. Степень этого замедления пропорциональна степени дублирования (или, обратно пропорционально пропорциональна индексировать количеству элементов). Можно использовать a BTREE индексируйте, чтобы избежать этой проблемы.

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

Столбцы, которые индексируются, могут содержать NULL значения.

Создаваемые пользователем и Временные таблицы

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

Загрузка Данных

Заполнить a MEMORY таблица, когда сервер MySQL запускается, можно использовать --init-file опция. Например, можно поместить операторы такой как INSERT INTO ... SELECT или LOAD DATA INFILE в этот файл, чтобы загрузить таблицу из персистентного источника данных. См. Раздел 5.1.3, "Опции Команды Сервера", и Раздел 13.2.6,"LOAD DATA INFILE Синтаксис".

MEMORY Таблицы и Репликация

Сервер MEMORY таблицы становятся пустыми, когда это выключено и перезапускается. Если сервер является ведущим устройством репликации, ее ведомые устройства не знают, что эти таблицы стали пустыми, таким образом, Вы видите устаревший контент, если Вы выбираете данные из таблиц на ведомых устройствах. Синхронизировать ведущее устройство и ведомое устройство MEMORY таблицы, когда a MEMORY таблица используется на ведущем устройстве впервые, так как она была запущена, a DELETE оператор пишется двоичному журналу ведущего устройства, чтобы освободить таблицу на ведомых устройствах также. У ведомого устройства все еще есть устаревшие данные в таблице во время интервала между перезапуском ведущего устройства и его первым использованием таблицы. Чтобы избежать этого интервала, когда прямой запрос к ведомому устройству мог возвратить устаревшие данные, используйте --init-file опция, чтобы заполнить MEMORY таблица на ведущем устройстве при запуске.

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

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

Память не исправляется, если Вы удаляете отдельные строки из a MEMORY таблица. Память исправляется только, когда вся таблица удаляется. Память, которая ранее использовалась для удаленных строк, снова используется для новых строк в пределах той же самой таблицы. Освободить всю память, используемую a MEMORY таблица, когда Вы больше не требуете ее содержания, выполняется DELETE или TRUNCATE TABLE удалить все строки, или удалить таблицу, в целом используя DROP TABLE. К свободному память, используемая удаленными строками, использовать ALTER TABLE ENGINE=MEMORY чтобы вызвать таблицу восстанавливают.

Память необходима для одной строки в a MEMORY таблица вычисляется, используя следующее выражение:

SUM_OVER_ALL_BTREE_KEYS(max_length_of_key + sizeof(char*) * 4)+ SUM_OVER_ALL_HASH_KEYS(sizeof(char*) * 2)+ ALIGN(length_of_row+1, sizeof(char*))

ALIGN() представляет фактор сводки новостей, чтобы заставить длину строки быть точным кратным числом char размер указателя. sizeof(char*) 4 на 32-разрядных машинах и 8 на 64-разрядных машинах.

Как отмечалось ранее, max_heap_table_size системная переменная устанавливает предел для максимального размера MEMORY таблицы. Чтобы управлять максимальным размером для отдельных таблиц, установите значение сеанса этой переменной прежде, чем составить каждую таблицу. (Не изменяйте глобальную переменную max_heap_table_size оцените, если Вы не предназначаете значение, которое будет использоваться для MEMORY таблицы составляются всеми клиентами.) Следующий пример создает два MEMORY таблицы, с максимальным размером 1 МБ и 2 МБ, соответственно:

mysql> SET max_heap_table_size =
        1024*1024;Query OK, 0 rows affected (0.00 sec)mysql> CREATE
        TABLE t1 (id INT, UNIQUE(id)) ENGINE =
        MEMORY;Query OK, 0 rows affected (0.01 sec)mysql> SET
        max_heap_table_size = 1024*1024*2;Query OK, 0 rows affected (0.00 sec)mysql> CREATE TABLE t2 (id INT, UNIQUE(id)) ENGINE = MEMORY;Query OK, 0 rows affected (0.00 sec)

Обе таблицы возвращаются к глобальной переменной сервера max_heap_table_size оцените, если сервер перезапускает.

Можно также определить a MAX_ROWS табличная опция в CREATE TABLE операторы для MEMORY таблицы, чтобы обеспечить подсказку о числе строк Вы планируете сохранить в них. Это не позволяет таблице вырасти вне max_heap_table_size значение, которое все еще действует как ограничение на максимальный табличный размер. Для максимальной гибкости в возможности использовать MAX_ROWS, набор max_heap_table_size по крайней мере, столь же высоко как значение, к которому Вы хотите каждого MEMORY таблица, чтобы быть в состоянии вырасти.

Дополнительные Ресурсы

Форум, выделенный MEMORY механизм хранения доступен в http://forums.mysql.com/list.php?92.