El motor de almacenamiento MEMORY
crea tablas
con contenidos que se almacenan en memoria.Éstas se conocían
préviamente como HEAP
. En MySQL 5.0,
MEMORY
es el término preferido, aunque
HEAP
se soporta para compatibilidad con
versiones anteriores.
Cada tabla MEMORY
está asociada con un fichero
de disco. El nombre de fichero comienza con el nombre de la tabla
y tiene una exensión de .frm
para indicar
que almacena la definición de la tabla.
Para especificar explícitamente que quiere una tabla
MEMORY
, indíquelo con una opción
ENGINE
:
CREATE TABLE t (i INT) ENGINE = MEMORY;
Como indica su nombre, las tablas MEMORY
se
almacenan en memoria y usan índices hash por defecto. Esto las
hace muy rápidas, y muy útiles para crear tablas temporales. Sin
embargo, cuando se apaga el servidor, todos los datos almacenados
en las tablas MEMORY
se pierde. Las tablas por
sí mismas continúan existiendo ya que sus definiciones se
almacenan en ficheros .frm
en disco, pero
están vacías cuando reinicia el servidor.
Este ejemplo muestra cómo puede crear, usar , y borrar una tabla
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;
Las tablas MEMORY
tienen las siguientes
características:
El espacio para tablas MEMORY
se reserva en
pequeños bloques. Las tablas usan el 100% del hashing
dinámico para insrciones. No se necesita área de
desbordamiento o espacio extra para claves. No se necesita
espacio extra para listas libres. Los registros borrados se
ponen en una lista encadenada y se reúsan cuando inserta
nuevos datos en la tabla. Las tablas MEMORY
no tienen ninguno de los problemas asociados con borrados más
inserciones en tablas hasheadas.
Las tablas MEMORY
pueden tener hasta 32
índices por tabla, 16 columnas por índice y una clave de
longitud máxima de 500 bytes.
En MySQL 5.0, el motor MEMORY
implementa
índices HASH
y BTREE
.
Puede espcificar uno u otro para cada índice añadiendo una
cláusula USING
tal y como se muestra:
CREATE TABLE lookup (id INT, INDEX USING HASH (id)) ENGINE = MEMORY; CREATE TABLE lookup (id INT, INDEX USING BTREE (id)) ENGINE = MEMORY;
Las características generales de B-trees e índices hash se describen en Sección 7.4.5, “Cómo utiliza MySQL los índices”.
Puede tener claves no únicas en una tabla
MEMORY
. (Esta es una característica no
común de implementaciones de índices hash.)
En MySQL 5.0, puede usar INSERT DELAYED
con
tablas MEMORY
. Consulte
Sección 13.2.4.2, “Sintaxis de INSERT DELAYED
”.
Si tiene un índice hash en una tabla
MEMORY
que tenga un alto índice de
duplicación de claves (muchas entradas de índice con el
mismo valor), las actualizaciones a la tabla que afecten
valores claves y todos los borrados son significativamente
más lentos. El rango de esta ralentización es proporcional
al rango de duplicación (o inversamente proporcional al grado
cardinalidad). Pude usar un índice BTREE
para evitar este problema.
Las tablas MEMORY
usan una longitud de
registro fija.
MEMORY
no soporta columnas
BLOB
o TEXT
.
MEMORY
en MySQL 5.0 incluye soporte para
columnas AUTO_INCREMENT
e índices en
columnas que contengan valores NULL
.
Las tablas MEMORY
se comparten entre todos
los clientes (como cualquier otra tabla
no-TEMPORARY
).
Los contenidos de las tablas MEMORY
se
almacenan en memora , lo que es una propiedad que las tablas
MEMORY
comparten con las tablas internas
que el servidor va creando al procesar consultas. Sin embargo,
los dos tipos de tablas difierne en que las tablas
MEMORY
no están sujetas a conversión de
almacenamiento, mientras que las tablas internas sí:
Si una tabla interna llega a ser demasiado grande, el
servidor la convierte automáticamente a una tabla en
disco. El límite de tamaño lo determina la variable de
sistema tmp_table_size
.
Las tablas MEMORY
nunca se convieren en
tablas de disco. Para segurar que no comete un error
accidentalmente, puede cambiar la variable de sistema
max_heap_table_size
para que imponga un
tamaño máximo de tablas MEMORY
. Para
tablas individuales, puede especificar la opción de tabla
MAX_ROWS
en el comando CREATE
TABLE
.
El servidor necesita suficiente memoria para mantener todas
las tablas MEMORY
en uso a la vez.
Para liberar memoria usada por una tabla
MEMORY
cuando no se requiere su contenido,
debe ejecutar DELETE FROM
o
TRUNCATE TABLE
, o borrar toda la tabla con
DROP TABLE
.
Si quiere rellenar una tabla MEMORY
cuando
arranca el servidor MySQL, puede usar la opción
--init-file
. Por ejemplo, puede usar
comandos como INSERT INTO ... SELECT
o
LOAD DATA INFILE
en este fichero para
cargar la tabla de una fuente de datos persistente. Consulte
Sección 5.3.1, “Opciones del comando mysqld” y
Sección 13.2.5, “Sintaxis de LOAD DATA INFILE
”.
Si usa replicación, las tablas MEMORY
del
servidor maestro se vacían cuando se apaga y reinicia. Sin
embargo, un esclavo no es consciente que se vacían estas
tablas, así que retorna contenido desfasado si selecciona
datos del mismo. En MySQL 5.0, cuando se usa una tabla
MEMORY
en el maestro por primera vez desde
que arrancó el maestro, se escribe un comando DELETE
FROM
en el log binario del maestro automáticamente,
resincronizando el maestro y el esclavo otra vez. Tenga en
cuenta que incluso con esta estrategia, el esclavo tiene datos
desfasados en la tabla en el intervalo entre el reinicio del
maestro y el primer uso de la tabla. Sin embargo, si usa la
opción --init-file
para rellenar la tabla
MEMORY
al arrancar el maestro, se asegura
que este intervalo sea cero.
La memoria necesaria por un registro en una tabla
MEMORY
se calcula con la siguiente
expresión:
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()
representa un factor de redondeo
para que la longitud del registro sea un múltiplo exacto del
tamaño del puntero char
.
sizeof(char*)
es 4 en máquinas de 32-bit y
8 en máquinas de 64-bit.
Ésta es una traducción del manual de referencia de MySQL, que puede encontrarse en dev.mysql.com. El manual de referencia original de MySQL está escrito en inglés, y esta traducción no necesariamente está tan actualizada como la versión original. Para cualquier sugerencia sobre la traducción y para señalar errores de cualquier tipo, no dude en dirigirse a mysql-es@vespito.com.