Introducción a las tablas con optimización para memoria

2025-06-21

Se aplica a:SQL Server Azure SQL Database Azure SQL Managed Instance

Las tablas optimizadas para memoria se crean con CREATE TABLE (Transact-SQL).

De forma predeterminada, las tablas optimizadas para memoria son totalmente durables y, al igual que las transacciones en tablas basadas en disco (tradicionales), las transacciones en este tipo de tablas tienen todas las propiedades ACID (atomicidad, coherencia, aislamiento y durabilidad). Las tablas optimizadas para memoria y los procedimientos almacenados compilados de forma nativa admiten solo un subconjunto de características de Transact-SQL.

A partir de SQL Server 2016, y en Azure SQL Database, no existen limitaciones para intercalaciones o páginas de códigos que son específicas de OLTP en memoria.

El almacenamiento principal para las tablas optimizadas para memoria es la memoria principal. Las filas de la tabla se leen y se escriben en la memoria. Una segunda copia de los datos de la tabla se conserva en el disco pero solo por la durabilidad. Vea Crear y administrar el almacenamiento de objetos con optimización para memoria para obtener más información sobre las tablas durables. Los datos de las tablas optimizadas para memoria solo se leen desde el disco durante la recuperación de la base de datos (por ejemplo, después de reiniciar el servidor).

Para conseguir incluso mayores mejoras de rendimiento, OLTP en memoria admite tablas durables con la durabilidad diferida de las transacciones. Las transacciones duraderas retrasadas se guardan en el disco poco después de que se confirma la transacción y el control se devuelve al cliente. A cambio del aumento del rendimiento, las transacciones confirmadas que no se conservan en el disco se pierden en un bloqueo del servidor o en una conmutación por error.

Además de las tablas optimizadas para memoria duradera predeterminadas, SQL Server también admite tablas optimizadas para memoria no duradera, que no se registran y sus datos no se conservan en el disco. Esto significa que las transacciones en estas tablas no requieren ninguna E/S de disco, pero los datos se pierden si hay un bloqueo del servidor o una conmutación por error.

OLTP en memoria está integrado con SQL Server para proporcionar una experiencia satisfactoria en todas las áreas como el desarrollo, la implementación, la facilidad de uso y la compatibilidad. Una base de datos puede contener objetos en memoria y objetos basados en disco.

Las tablas optimizadas para memoria son siempre con control de versiones. Esto significa que cada fila de la tabla puede tener varias versiones. Todas las versiones de fila se mantienen en la misma estructura de datos de la tabla. El control de versiones de fila se utiliza para permitir las lecturas y las escrituras simultáneas en la misma fila. Para obtener más información sobre las lecturas y las escrituras simultáneas en la misma fila, vea Transactions with Memory-Optimized Tables(Transacciones con tablas con optimización para memoria).

La siguiente ilustración muestra la multiversión. La ilustración muestra una tabla con tres filas y cada fila tiene versiones diferentes.

Multiversión.

La tabla tiene tres filas: r1, r2 y r3. r1 tiene tres versiones, r2 tiene dos versiones y r3 tiene cuatro. Las diferentes versiones de la misma fila no ocupan necesariamente ubicaciones de memoria consecutivas. Las diferentes versiones de fila pueden estar dispersas por la estructura de datos de la tabla.

La estructura de datos de una tabla optimizada para memoria se puede considerar como una colección de versiones de fila. Las filas de tablas basadas en disco se organizan en páginas y extensiones, las filas individuales se direccionan con el desplazamiento de página y número de página, y las versiones de fila de las tablas optimizadas para memoria se direccionan con punteros de memoria de 8 bytes.

Se puede tener acceso a los datos de las tablas optimizadas para memoria de dos maneras:

A través de procedimientos almacenados compilados de forma nativa.
A través de Transact-SQL interpretado, fuera de un procedimiento almacenado compilado de forma nativa. Estas instrucciones de Transact-SQL pueden ser procedimientos almacenados interpretados internamente o pueden ser instrucciones de Transact-SQL ad hoc.

Acceso a datos en tablas con optimización para memoria

Se puede tener acceso a las tablas con optimización para memoria de forma más eficaz desde procedimientos almacenados compilados de forma nativa (Procedimientos almacenados compilados de forma nativa). Se puede tener acceso también a las tablas con optimización para memoria con Transact-SQL interpretado (tradicional). Transact-SQL interpretado hace referencia al acceso a tablas optimizadas para memoria sin un procedimiento almacenado compilado de forma nativa. Algunos ejemplos de acceso con Transact-SQL interpretado son el acceso a una tabla optimizada para memoria desde un desencadenador DML, un lote ad hoc de Transact-SQL, una vista y una función con valores de tabla.

En la tabla siguiente se resume el acceso con Transact-SQL interpretado y nativo para varios objetos.

Característica	Acceso con un procedimiento almacenado compilado de forma nativa	Acceso de Transact-SQL interpretado	Acceso CLR
Tabla con optimización para memoria	Sí	Sí	Nº¹
Tipo de tabla con optimización para memoria	Sí	Sí	No
Procedimiento almacenado compilado de forma nativa	Ahora se admite el anidamiento de procedimientos almacenados compilados de forma nativa. Puede usar la sintaxis EXECUTE dentro de los procedimientos almacenados, siempre que el procedimiento de referencia también se compile de forma nativa.	Sí	No*

¹No se puede tener acceso a una tabla optimizada para memoria ni a un procedimiento almacenado compilado de forma nativa desde la conexión de contexto (la conexión desde SQL Server al ejecutar un módulo CLR). Sin embargo, puede crear y abrir otra conexión en la que pueda tener acceso a las tablas optimizadas para memoria y a los procedimientos almacenados compilados de forma nativa.

Los datos confidenciales de las tablas optimizadas para memoria se pueden proteger mediante Always Encrypted. Se presentan las siguientes limitaciones:

Al usar Always Encrypted con enclaves seguros, no se admite el uso de claves habilitadas para enclave para columnas en tablas optimizadas para memoria. Esto significa que no se puede usar el cifrado local y el cifrado inicial se realiza en el cliente.
Always Encrypted no se admite para ninguna columna de una tabla optimizada para memoria cuando se hace referencia a la tabla en un módulo compilado de forma nativa.

Escalabilidad y rendimiento

Los siguientes factores afectan a las mejoras de rendimiento que se pueden lograr con In-Memory OLTP:

Comunicación: Una aplicación que usa muchas llamadas cortas a procedimientos almacenados puede ver una ganancia de rendimiento menor en comparación con una aplicación con menos llamadas y más funcionalidad implementada en cada procedimiento almacenado.

Transact-SQL Execution: OLTP en memoria alcanza el máximo rendimiento cuando se usan procedimientos almacenados compilados de forma nativa en lugar de procedimientos almacenados interpretados o de ejecución de consultas. Puede haber un beneficio para obtener acceso a las tablas optimizadas para memoria desde este tipo de procedimientos almacenados.

Examen de rango frente a búsqueda de punto: los índices no agrupados con optimización para memoria admiten los exámenes de rango y los exámenes ordenados. Para las búsquedas de puntos, los índices hash optimizados para memoria tienen mejor rendimiento que los índices no clúster optimizados para memoria. Los índices no clúster con optimización para memoria tienen mejor rendimiento que los índices basados en disco.

A partir de SQL Server 2016, el plan de consulta para una tabla optimizada para memoria puede examinar la tabla en paralelo. Esto mejora el rendimiento de las consultas de análisis.
- Los índices de hash también han pasado a poder examinarse en paralelo en SQL Server 2016.
- Los índices no agrupados también han pasado a poder examinarse en paralelo en SQL Server 2016.

Operaciones de índice: Las operaciones de índice no se registran y solo existen en la memoria.

Simultaneidad: las aplicaciones cuyo rendimiento se ve afectado por la simultaneidad del nivel de motor, como la contención de bloqueos temporales o el bloqueo, mejoran significativamente cuando se pasan a OLTP en memoria.

En la tabla siguiente se enumeran los problemas de rendimiento y escalabilidad que se suelen encontrar en las bases de datos relacionales y el modo en que OLTP en memoria puede mejorar el rendimiento.

Problema	Impacto de OLTP en memoria
Rendimiento Uso elevado de recursos (CPU, E/S, red o memoria).	Unidad Central de Procesamiento (CPU) Los procedimientos almacenados compilados de forma nativa pueden reducir significativamente el uso de la CPU porque requieren menos instrucciones para ejecutar una instrucción Transact-SQL en comparación con los procedimientos almacenados interpretados. In-Memory OLTP puede ayudar a reducir la inversión de hardware en cargas de trabajo escaladas horizontalmente, ya que un servidor puede ofrecer potencialmente el rendimiento de varios servidores. E/S Si encuentra un cuello de botella de E/S desde el procesamiento hasta las páginas de datos o de índices, OLTP en memoria puede reducir el cuello de botella. Además, los puntos de control de In-Memory objetos OLTP son continuos y no provocan aumentos repentinos en las operaciones de E/S. Sin embargo, si el espacio de trabajo de las tablas críticas para el rendimiento no cabe en la memoria, In-Memory OLTP no se aplica porque requiere que los datos residan en la memoria. Si encuentra un cuello de botella de E/S en el registro, OLTP en memoria puede reducirlo porque realiza menos tareas de registro. Si una o más tablas optimizadas para memoria se configuran como tablas no durables, puede eliminar el registro de los datos. Memoria In-Memory OLTP no ofrece ninguna ventaja de rendimiento. OLTP en memoria puede suponer una presión adicional sobre la memoria, ya que los objetos deben residir en la memoria. Red In-Memory OLTP no ofrece ninguna ventaja de rendimiento. Los datos tienen que comunicarse desde la capa de datos en el nivel de aplicación.
Escalabilidad La mayoría de los problemas de escala de las aplicaciones de SQL Server son causados por problemas de simultaneidad como la contención de bloqueos, bloqueos temporales y bloqueos por subproceso.	Contención de bloqueos temporales Un escenario típico es la contención en la última página de un índice al insertar filas simultáneamente en el orden de clave. Dado que In-Memory OLTP no acepta bloqueos temporales al acceder a los datos, los problemas de escalabilidad relacionados con las contenciones de bloqueos temporales se eliminan por completo. Contención de bloqueo por subproceso Dado que In-Memory OLTP no acepta bloqueos temporales al acceder a los datos, los problemas de escalabilidad relacionados con las contenciones de bloqueo por subproceso se eliminan por completo. Contención relacionada con el bloqueo Si la aplicación de base de datos encuentra problemas de bloqueo entre las operaciones de lectura y escritura, OLTP en memoria evita dichos problemas porque usa un nuevo formato de control de simultaneidad optimista para implementar todos los niveles de aislamiento de las transacciones. In-Memory OLTP no usa TempDB para almacenar versiones de fila. Si el problema de escala se debe al conflicto entre dos operaciones de escritura, como dos transacciones simultáneas que intenten actualizar la misma fila, OLTP en memoria permite que una transacción sea correcta y que la otra dé error. La transacción con errores debe volver a enviarse explícita o implícitamente, volviendo a intentar la transacción. En cualquier caso, debe realizar cambios en la aplicación. Si la aplicación experimenta conflictos frecuentes entre dos operaciones de escritura, el valor de bloqueo optimista se reduce. La aplicación no es adecuada para In-Memory OLTP. La mayoría de las aplicaciones OLTP no tienen conflictos de escritura a menos que el conflicto sea el resultado de una escalada de bloqueo.

Problema

Impacto de OLTP en memoria

Rendimiento

Uso elevado de recursos (CPU, E/S, red o memoria).

Unidad Central de Procesamiento (CPU)
Los procedimientos almacenados compilados de forma nativa pueden reducir significativamente el uso de la CPU porque requieren menos instrucciones para ejecutar una instrucción Transact-SQL en comparación con los procedimientos almacenados interpretados.

In-Memory OLTP puede ayudar a reducir la inversión de hardware en cargas de trabajo escaladas horizontalmente, ya que un servidor puede ofrecer potencialmente el rendimiento de varios servidores.

E/S
Si encuentra un cuello de botella de E/S desde el procesamiento hasta las páginas de datos o de índices, OLTP en memoria puede reducir el cuello de botella. Además, los puntos de control de In-Memory objetos OLTP son continuos y no provocan aumentos repentinos en las operaciones de E/S. Sin embargo, si el espacio de trabajo de las tablas críticas para el rendimiento no cabe en la memoria, In-Memory OLTP no se aplica porque requiere que los datos residan en la memoria. Si encuentra un cuello de botella de E/S en el registro, OLTP en memoria puede reducirlo porque realiza menos tareas de registro. Si una o más tablas optimizadas para memoria se configuran como tablas no durables, puede eliminar el registro de los datos.

Memoria
In-Memory OLTP no ofrece ninguna ventaja de rendimiento. OLTP en memoria puede suponer una presión adicional sobre la memoria, ya que los objetos deben residir en la memoria.

Red
In-Memory OLTP no ofrece ninguna ventaja de rendimiento. Los datos tienen que comunicarse desde la capa de datos en el nivel de aplicación.

Escalabilidad

La mayoría de los problemas de escala de las aplicaciones de SQL Server son causados por problemas de simultaneidad como la contención de bloqueos, bloqueos temporales y bloqueos por subproceso.

Contención de bloqueos temporales
Un escenario típico es la contención en la última página de un índice al insertar filas simultáneamente en el orden de clave. Dado que In-Memory OLTP no acepta bloqueos temporales al acceder a los datos, los problemas de escalabilidad relacionados con las contenciones de bloqueos temporales se eliminan por completo.

Contención de bloqueo por subproceso
Dado que In-Memory OLTP no acepta bloqueos temporales al acceder a los datos, los problemas de escalabilidad relacionados con las contenciones de bloqueo por subproceso se eliminan por completo.

Contención relacionada con el bloqueo
Si la aplicación de base de datos encuentra problemas de bloqueo entre las operaciones de lectura y escritura, OLTP en memoria evita dichos problemas porque usa un nuevo formato de control de simultaneidad optimista para implementar todos los niveles de aislamiento de las transacciones. In-Memory OLTP no usa TempDB para almacenar versiones de fila.

Si el problema de escala se debe al conflicto entre dos operaciones de escritura, como dos transacciones simultáneas que intenten actualizar la misma fila, OLTP en memoria permite que una transacción sea correcta y que la otra dé error. La transacción con errores debe volver a enviarse explícita o implícitamente, volviendo a intentar la transacción. En cualquier caso, debe realizar cambios en la aplicación.

Si la aplicación experimenta conflictos frecuentes entre dos operaciones de escritura, el valor de bloqueo optimista se reduce. La aplicación no es adecuada para In-Memory OLTP. La mayoría de las aplicaciones OLTP no tienen conflictos de escritura a menos que el conflicto sea el resultado de una escalada de bloqueo.

Seguridad de nivel de fila en tablas con optimización para memoria

Laseguridad de nivel de fila es compatible con las tablas optimizadas para memoria. La aplicación de directivas de seguridad de nivel de fila a las tablas optimizadas para memoria es esencialmente igual que para las tablas basadas en disco, con la excepción de que las funciones con valores de tabla en línea que se usan como predicados seguros deben compilarse de manera nativa (se deben crear con la opción WITH NATIVE_COMPILATION). Para obtener más información, vea la sección Compatibilidad entre características del tema Seguridad de nivel de fila .

Varias funciones de seguridad integradas que son esenciales para la seguridad de nivel de fila están disponibles para las tablas optimizadas para memoria. Para obtener más información, vea Funciones integradas en módulos compilados de forma nativa.

EXECUTE AS CALLER : todos los módulos nativos ahora admiten y usan EXECUTE AS CALLER de forma predeterminada, incluso si no se especifica la sugerencia. Esto se debe a que se espera que todas las funciones de predicado de seguridad de nivel de fila usen EXECUTE AS CALLER para que la función, y las funciones integradas que se usen en ella, se evalúen en el contexto del usuario que realiza la llamada.
EXECUTE AS CALLER tiene una pequeña merma en el rendimiento (de aproximadamente 10 %) provocada por las comprobaciones de permisos en el autor de la llamada. Si el módulo especifica EXECUTE AS OWNER o EXECUTE AS SELF explícitamente, se evitan estas comprobaciones de permisos y su coste de rendimiento asociado. Sin embargo, el uso de cualquiera de estas opciones junto con las funciones integradas mencionadas incurre en un mayor impacto en el rendimiento debido al cambio de contexto necesario.

Escenarios

Para obtener una breve descripción de los escenarios habituales en los que OLTP en memoria puede mejorar el rendimiento, vea OLTP en memoria.

Consulte también

In-Memory OLTP (optimización In-Memory)