Introduction aux tables optimisées en mémoire

2025-06-21

S’applique à :SQL Server Azure SQL Database Azure SQL Managed Instance

Les tables à mémoire optimisée sont créées à l’aide de CREATE TABLE (Transact-SQL).

Les tables à mémoire optimisée sont intégralement durables par défaut, et, tout comme les transactions sur des tables sur disque (traditionnelles), les transactions sur les tables à mémoire optimisée sont ACID (atomicité, cohérence, isolation, durabilité). Les tables à mémoire optimisée et les procédures stockées compilées en mode natif ne prennent en charge qu’un sous-ensemble de fonctionnalités Transact-SQL.

À compter de SQL Server 2016 et dans Azure SQL Database, il n’existe aucune limite relative aux classements ni pages de codes qui sont spécifiques à OLTP en mémoire.

Le stockage principal des tables à mémoire optimisée est la mémoire principale. Les lignes de la table sont lues et écrites dans la mémoire. Une deuxième copie des données de la table est conservée sur le disque, mais uniquement pour la durabilité. Consultez Création et gestion du stockage des objets mémoire optimisés Pour plus d’informations sur les tables durables. Les données des tables à mémoire optimisée ne sont lues à partir du disque que lors de la récupération de la base de données (par exemple, après le redémarrage d’un serveur).

Pour des gains de performance encore accrus, l'OLTP en mémoire prend en charge les tables durables avec des transactions à durabilité retardée. Les transactions durables différées sont enregistrées sur le disque peu de temps après la validation de la transaction et le retour du contrôle au client. En échange de performances accrues, les transactions validées qui ne sont pas conservées sur le disque sont perdues en cas de panne du serveur ou de basculement.

Outre les tables optimisées pour la mémoire durable par défaut, SQL Server prend également en charge les tables optimisées pour la mémoire non durable, qui ne sont pas journalisées et dont les données ne sont pas conservées sur le disque. Cela signifie que les transactions sur ces tables ne nécessitent pas d’E/S de disque, mais que les données sont perdues en cas de panne du serveur ou de basculement.

L’OLTP en mémoire est intégré à SQL Server pour offrir une expérience transparente dans tous les domaines, tels que le développement, le déploiement, la gestion et la prise en charge. Une base de données peut contenir des objets en mémoire et sur disque.

Les lignes des tables optimisées en mémoire ont un contrôle de version. Cela signifie que chaque ligne de la table a potentiellement plusieurs versions. Toutes les versions de ligne sont conservées dans la même structure de données de la table. Le contrôle de version de ligne est utilisé pour autoriser les lectures et les écritures simultanées sur la même ligne. Pour plus d’informations sur les lectures et les écritures simultanées sur la même ligne, consultez Transactions with Memory-Optimized Tables(Transactions avec des tables optimisées en mémoire).

La figure ci-dessous illustre les contrôles de version multiples. Elle représente une table de trois lignes ayant chacune plusieurs versions.

Contrôles de version multiples.

La table a trois lignes : r1, r2 et r3. r1 a trois versions, r2 a deux versions, et r3 a quatre versions. Les différentes versions d’une même ligne n’occupent pas nécessairement des emplacements de mémoire consécutifs. Les différentes versions de ligne peuvent être dispersées dans l'ensemble de la structure de données de la table.

La structure de données des tables optimisées en mémoire peut être considérée comme une collection de versions de ligne. Les lignes d'une table sur disque sont organisées dans des pages et des extensions, et les lignes individuelles sont traitées sur la base du numéro et du décalage de la page, les versions de ligne dans les tables optimisées en mémoire sont traitées à l'aide de pointeurs de mémoire à huit octets.

Les données des tables optimisées en mémoire sont accessibles de deux manières :

Via des procédures stockées compilées en mode natif.
Par le biais de Transact-SQL interprété, en dehors d’une procédure stockée compilée en natif. Ces instructions Transact-SQL peuvent être dans des procédures stockées interprétées ou des instructions Transact-SQL ad hoc.

Accès aux données des tables optimisées en mémoire

Les tables optimisées en mémoire sont plus efficacement accessibles à partir des procédures stockées compilées en mode natif (Procédures stockées compilées en mode natif). Elles peuvent également être accédées via le Transact-SQL interprété (traditionnel). Le terme Transact-SQL interprété fait référence à l’accès aux tables optimisées en mémoire sans procédure stockée compilée en mode natif. Parmi les exemples d’accès au Transact-SQL interprété figure l’accès à une table optimisée en mémoire à partir d’un déclencheur DML ou d’un traitement, d’une vue ou d’une fonction table Transact-SQL ad hoc.

Le tableau suivant résume l’accès natif et l’accès en Transact-SQL interprété pour différents objets.

Fonctionnalité	Accès à l'aide d'une procédure stockée compilée en mode natif	Accès Transact-SQL interprété	Accès CLR
Table mémoire optimisée	Oui	Oui	N^{° 1}
Type de table mémoire optimisée	Oui	Oui	Non
Procédure stockée compilée en mode natif	L’imbrication de procédures stockées compilées en mode natif est désormais prise en charge. Vous pouvez utiliser la syntaxe EXECUTE à l’intérieur des procédures stockées, à condition que la procédure référencée soit également compilée en mode natif.	Oui	Non*

¹Vous ne pouvez pas accéder à une table optimisée en mémoire ou à une procédure stockée compilée en mode natif à partir de la connexion contextuelle (connexion à partir de SQL Server lors de l’exécution d’un module CLR). Cependant, vous pouvez créer et ouvrir une autre connexion à partir de laquelle vous accédez aux tables optimisées en mémoire et aux procédures stockées compilées en mode natif.

Les données sensibles des tables optimisées en mémoire peuvent être protégées à l’aide de Always Encrypted. Les limites suivantes s'appliquent :

Lors de l’utilisation d’Always Encrypted avec des enclaves sécurisées, l’utilisation de clés activées pour les enclaves pour les colonnes dans les tables optimisées en mémoire n’est pas prise en charge. Cela signifie que le chiffrement sur place ne peut pas être utilisé et que le chiffrement initial est effectué sur le client.
Always Encrypted n’est pris en charge pour aucune colonne d’une table optimisée en mémoire lorsque la table est référencée dans un module compilé en mode natif.

Performances et extensibilité

Les facteurs suivants affectent les gains de performances qui peuvent être obtenus avec In-Memory OLTP :

Communication: Une application utilisant de nombreux appels de procédure stockée courts peut voir un gain de performances plus faible par rapport à une application avec moins d’appels et plus de fonctionnalités implémentées dans chaque procédure stockée.

Exécution Transact-SQL : l’OLTP en mémoire offre des performances optimales si vous utilisez des procédures stockées compilées en mode natif plutôt que des procédures stockées interprétées ou l’exécution de requêtes. Il peut être avantageux d’accéder aux tables optimisées en mémoire à partir de ces procédures stockées.

Comparaison entre l’analyse de plage et la recherche de points : Les index non cluster optimisés en mémoire prennent en charge les analyses de plage et les analyses triées. Pour les recherches de points, les index de hachage optimisés en mémoire offrent de meilleures performances que les index non cluster optimisés en mémoire. Les index non cluster optimisés en mémoire offrent de meilleures performances que les index sur disque.

À partir de SQL Server 2016, le plan de requête pour une table optimisée en mémoire peut analyser la table en parallèle. Les requêtes analytiques sont donc plus performantes.
- Les index de hachage peuvent également être analysés en parallèle à partir de SQL Server 2016.
- Les index non cluster peuvent également être analysés en parallèle à partir de SQL Server 2016.

Opérations d’indexation : Les opérations d’index ne sont pas journalisées et n’existent qu’en mémoire.

Accès simultané : Pour les applications dont les performances sont affectées par l’accès simultané au niveau du moteur, tel que la contention de verrous internes ou le blocage, les performances s’améliorent de façon significative quand l’application passe à l’OLTP en mémoire.

Le tableau suivant répertorie les problèmes de performance et d'extensibilité couramment rencontrés dans les bases de données relationnelles et indique comment l'OLTP peut améliorer les performances.

Problème	Impact sur l'OLTP en mémoire
Performances Utilisation élevée des ressources (processeur, E/S, réseau ou mémoire).	UC Les procédures stockées compilées en mode natif peuvent réduire considérablement l’utilisation du processeur, car elles nécessitent moins d’instructions pour exécuter une instruction Transact-SQL par rapport aux procédures stockées interprétées. In-Memory OLTP peut aider à réduire l’investissement matériel dans les charges de travail scale-out, car un serveur peut potentiellement fournir le débit de plusieurs serveurs. E/S Si vous observez un goulot d'étranglement des E/S à partir du traitement des données ou des pages d'index, l'OLTP en mémoire peut l'atténuer. De plus, le point de contrôle des objets OLTP In-Memory est continu et n’entraîne pas d’augmentation soudaine des opérations d’E/S. Toutefois, si l’ensemble de travail des tables critiques pour les performances ne tient pas en mémoire, In-Memory OLTP ne s’applique pas, car il nécessite que les données résident en mémoire. Si vous observez un goulot d'étranglement des E/S lors de la journalisation, l'OLTP en mémoire l'atténue, car il nécessite moins d'opérations de journalisation. Si une ou plusieurs tables optimisées en mémoire sont configurées en tant que tables non durables, supprimez la journalisation des données. Mémoire In-Memory OLTP n’offre aucun avantage en termes de performances. Il peut en effet solliciter davantage la mémoire, car les objets doivent résider en mémoire. Network (Réseau) In-Memory OLTP n’offre aucun avantage en termes de performances. Les données doivent être communiquées de la couche Données à la couche Application.
Évolutivité La plupart des problèmes de mise à l’échelle dans les applications SQL Server sont dus à des problèmes d’accès concurrentiel tels que la contention dans les verrous, les verrous internes et les verrouillages tournants.	Contention de verrous internes Un scénario typique est la contention dans la dernière page d'un index lors de l'insertion simultanée de lignes dans l'ordre des clés. Étant donné In-Memory OLTP n’accepte pas de verrous lors de l’accès aux données, les problèmes d’évolutivité liés aux conflits de verrou sont entièrement éliminés. Contention de verrouillage tournant Étant donné In-Memory OLTP n’accepte pas de verrous lors de l’accès aux données, les problèmes d’évolutivité liés aux conflits de spinlock sont entièrement supprimés. Contention liée au verrouillage Si votre application de base de données rencontre des problèmes de blocage entre les opérations de lecture et d'écriture, l'OLTP en mémoire les supprime, car il utilise une nouvelle forme de contrôle d'accès concurrentiel optimiste pour implémenter tous les niveaux d'isolation des transactions. In-Memory OLTP n’utilise pas TempDB pour stocker les versions de ligne. Si le problème de mise à l'échelle est provoqué par un conflit entre deux opérations d'écriture, telles que deux transactions simultanées tentant de mettre à jour la même ligne, l'OLTP en mémoire laisse une transaction aboutir et fait échouer l'autre. La transaction ayant échoué doit être soumise à nouveau, explicitement ou implicitement, en réessayant la transaction. Dans les deux cas, vous devez apporter des modifications à l'application. Si votre application crée des conflits fréquents entre deux opérations d'écriture, la valeur du verrouillage optimiste est diminuée. L’application n’est pas adaptée à In-Memory OLTP. La plupart des applications OLTP n’ont pas de conflits d’écriture, sauf si le conflit est le résultat d’une escalade de verrouillage.

Problème

Impact sur l'OLTP en mémoire

Performances

Utilisation élevée des ressources (processeur, E/S, réseau ou mémoire).

UC
Les procédures stockées compilées en mode natif peuvent réduire considérablement l’utilisation du processeur, car elles nécessitent moins d’instructions pour exécuter une instruction Transact-SQL par rapport aux procédures stockées interprétées.

In-Memory OLTP peut aider à réduire l’investissement matériel dans les charges de travail scale-out, car un serveur peut potentiellement fournir le débit de plusieurs serveurs.

E/S
Si vous observez un goulot d'étranglement des E/S à partir du traitement des données ou des pages d'index, l'OLTP en mémoire peut l'atténuer. De plus, le point de contrôle des objets OLTP In-Memory est continu et n’entraîne pas d’augmentation soudaine des opérations d’E/S. Toutefois, si l’ensemble de travail des tables critiques pour les performances ne tient pas en mémoire, In-Memory OLTP ne s’applique pas, car il nécessite que les données résident en mémoire. Si vous observez un goulot d'étranglement des E/S lors de la journalisation, l'OLTP en mémoire l'atténue, car il nécessite moins d'opérations de journalisation. Si une ou plusieurs tables optimisées en mémoire sont configurées en tant que tables non durables, supprimez la journalisation des données.

Mémoire
In-Memory OLTP n’offre aucun avantage en termes de performances. Il peut en effet solliciter davantage la mémoire, car les objets doivent résider en mémoire.

Network (Réseau)
In-Memory OLTP n’offre aucun avantage en termes de performances. Les données doivent être communiquées de la couche Données à la couche Application.

Évolutivité

La plupart des problèmes de mise à l’échelle dans les applications SQL Server sont dus à des problèmes d’accès concurrentiel tels que la contention dans les verrous, les verrous internes et les verrouillages tournants.

Contention de verrous internes
Un scénario typique est la contention dans la dernière page d'un index lors de l'insertion simultanée de lignes dans l'ordre des clés. Étant donné In-Memory OLTP n’accepte pas de verrous lors de l’accès aux données, les problèmes d’évolutivité liés aux conflits de verrou sont entièrement éliminés.

Contention de verrouillage tournant
Étant donné In-Memory OLTP n’accepte pas de verrous lors de l’accès aux données, les problèmes d’évolutivité liés aux conflits de spinlock sont entièrement supprimés.

Contention liée au verrouillage
Si votre application de base de données rencontre des problèmes de blocage entre les opérations de lecture et d'écriture, l'OLTP en mémoire les supprime, car il utilise une nouvelle forme de contrôle d'accès concurrentiel optimiste pour implémenter tous les niveaux d'isolation des transactions. In-Memory OLTP n’utilise pas TempDB pour stocker les versions de ligne.

Si le problème de mise à l'échelle est provoqué par un conflit entre deux opérations d'écriture, telles que deux transactions simultanées tentant de mettre à jour la même ligne, l'OLTP en mémoire laisse une transaction aboutir et fait échouer l'autre. La transaction ayant échoué doit être soumise à nouveau, explicitement ou implicitement, en réessayant la transaction. Dans les deux cas, vous devez apporter des modifications à l'application.

Si votre application crée des conflits fréquents entre deux opérations d'écriture, la valeur du verrouillage optimiste est diminuée. L’application n’est pas adaptée à In-Memory OLTP. La plupart des applications OLTP n’ont pas de conflits d’écriture, sauf si le conflit est le résultat d’une escalade de verrouillage.

Sécurité au niveau des lignes dans les tables optimisées en mémoire

Sécurité au niveau des lignes La sécurité au niveau des lignes est prise en charge pour les tables optimisées en mémoire. La procédure d’application de stratégies de sécurité de niveau ligne à des tables optimisées en mémoire est globalement identique à celle qui concerne les tables sur disque, à une exception près : les Fonctions table incluses qui sont utilisées comme prédicats de sécurité doivent être compilées en mode natif (créées avec l’option WITH NATIVE_COMPILATION). Pour plus d’informations, consultez la section Compatibilité entre fonctionnalités dans la rubrique Sécurité au niveau des lignes .

Diverses fonctions de sécurité intégrées essentielles à la sécurité au niveau des lignes sont disponibles pour les tables optimisées en mémoire. Pour plus d’informations, consultez Fonctions intégrées dans les modules compilés en mode natif.

EXECUTE AS CALLER - Tous les modules natifs prennent désormais en charge et utilisent EXECUTE AS CALLER par défaut, même si l’indication n’est pas spécifiée. En effet, il est attendu que toutes les fonctions de prédicat de sécurité au niveau de la ligne utilisent EXECUTE AS CALLER afin que la fonction, et toutes les fonctions intégrées utilisées dans celle-ci, soient évaluées dans le contexte de l’utilisateur appelant.
EXECUTE AS CALLER n’entraîne qu’une faible baisse de performances (de l’ordre de 10 %) du fait des vérifications des autorisations effectuées sur l’appelant. Si le module spécifie explicitement EXECUTE AS OWNER ou EXECUTE AS SELF, ces contrôles d’autorisation et leur coût de performance associé sont évités. Cependant, l’utilisation de l’une ou l’autre de ces options avec les fonctions intégrées mentionnées entraîne une baisse plus élevée des performances en raison de la commutation de contexte nécessaire.

Scénarios

Pour découvrir une brève description des scénarios types dans lesquels l’OLTP en mémoire peut contribuer à améliorer les performances, consultez OLTP en mémoire.

Voir aussi

In-Memory OLTP (optimisation en mémoire)