MS-SQL prend-il en charge les tables en mémoire ?

Question

Récemment, j'ai commencé à modifier certaines de nos applications pour prendre en charge MS SQL Server comme back-end alternatif.

L'un des problèmes de compatibilité que j'ai rencontrés est l'utilisation de CREATE TEMPORARY TABLE de MySQL pour créer des tables en mémoire contenant des données pour un accès très rapide pendant une session sans avoir besoin de stockage permanent.

Quel est l’équivalent en MS SQL ?

Une condition est que je dois pouvoir utiliser la table temporaire comme n'importe quelle autre, en particulier JOIN avec les permanents.

Answer 1

@Keith

C'est une idée fausse courante :Les variables de table ne sont PAS nécessairement stockées en mémoire.En fait, SQL Server décide de conserver la variable en mémoire ou de la transférer vers TempDB.Il n'existe aucun moyen fiable (du moins dans SQL Server 2005) de garantir que les données des tables sont conservées en mémoire.Pour des informations plus détaillées, regardez ici

Answer 2

Vous pouvez créer des variables de table (en mémoire) et deux types différents de table temporaire :

--visible only to me, in memory (SQL 2000 and above only)
declare @test table (
    Field1 int,
    Field2 nvarchar(50)
);

--visible only to me, stored in tempDB
create table #test (
    Field1 int,
    Field2 nvarchar(50)
)

--visible to everyone, stored in tempDB
create table ##test (
    Field1 int,
    Field2 nvarchar(50)
)

---

Modifier:

Suite aux retours, je pense que cela nécessite une petite clarification.

#table et ##table sera toujours dans TempDB.

@Table les variables seront normalement en mémoire, mais il n'est pas garanti qu'elles le soient.SQL décide en fonction du plan de requête et utilise TempDB si nécessaire.

Answer 3

Vous pouvez déclarer une « variable de table » dans SQL Server 2005, comme ceci :

declare @foo table (
    Id int,
    Name varchar(100)
);

Vous y faites alors référence comme une variable :

select * from @foo f
    join bar b on b.Id = f.Id

Pas besoin de le supprimer - il disparaît lorsque la variable devient hors de portée.

Answer 4

C'est possible avec MS SQL Server 2014.

Voir: http://msdn.microsoft.com/en-us/library/dn133079.aspx

Voici un exemple de code de génération SQL (depuis MSDN) :

-- create a database with a memory-optimized filegroup and a container.
CREATE DATABASE imoltp 
GO

ALTER DATABASE imoltp ADD FILEGROUP imoltp_mod CONTAINS MEMORY_OPTIMIZED_DATA 
ALTER DATABASE imoltp ADD FILE (name='imoltp_mod1', filename='c:\data\imoltp_mod1') TO FILEGROUP imoltp_mod 
ALTER DATABASE imoltp SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT=ON
GO

USE imoltp
GO


-- create a durable (data will be persisted) memory-optimized table
-- two of the columns are indexed
CREATE TABLE dbo.ShoppingCart ( 
  ShoppingCartId INT IDENTITY(1,1) PRIMARY KEY NONCLUSTERED,
  UserId INT NOT NULL INDEX ix_UserId NONCLUSTERED HASH WITH (BUCKET_COUNT=1000000), 
  CreatedDate DATETIME2 NOT NULL, 
  TotalPrice MONEY
  ) WITH (MEMORY_OPTIMIZED=ON) 
GO

 -- create a non-durable table. Data will not be persisted, data loss if the server turns off unexpectedly
CREATE TABLE dbo.UserSession ( 
  SessionId INT IDENTITY(1,1) PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT=400000), 
  UserId int NOT NULL, 
  CreatedDate DATETIME2 NOT NULL,
  ShoppingCartId INT,
  INDEX ix_UserId NONCLUSTERED HASH (UserId) WITH (BUCKET_COUNT=400000) 
  ) WITH (MEMORY_OPTIMIZED=ON, DURABILITY=SCHEMA_ONLY) 
GO

Answer 5

Un bien article de blog ici mais en gros, préfixez les tables temporaires locales avec # et la température globale avec ## - par exemple

CREATE TABLE #localtemp

Answer 6

Je comprends ce que vous essayez de réaliser.Bienvenue dans le monde des bases de données variées !

SQL Server 2000 prend en charge les tables temporaires créées en préfixant un # au nom de la table, ce qui en fait une table temporaire accessible localement (locale à la session) et en précédant ## au nom de la table, pour les tables temporaires accessibles globalement, par exemple #MyLocalTable et ##MyGlobalTable respectivement.

SQL Server 2005 et versions ultérieures prennent en charge à la fois les tables temporaires (locales, globales) et les variables de table. Méfiez-vous des nouvelles fonctionnalités sur les variables de table dans SQL 2008 et dans la version deux !La différence entre les tables temporaires et les variables de table n'est pas si grande mais réside dans la manière dont le serveur de base de données les gère.

Je ne voudrais pas parler des anciennes versions de SQL Server comme 7, 6, même si j'ai travaillé avec elles et c'est de là que je viens de toute façon :-)

Il est courant de penser que les variables de table résident toujours en mémoire, mais c’est faux.En fonction de l'utilisation de la mémoire et du volume de transactions du serveur de base de données, les pages d'une variable de table peuvent être exportées de la mémoire et écrites dans tempdb et le reste du traitement s'y déroule (dans tempdb).

Veuillez noter que tempdb est une base de données sur une instance sans objets permanents par nature, mais elle est responsable de la gestion des charges de travail impliquant des transactions secondaires telles que le tri et d'autres travaux de traitement de nature temporaire.D'un autre côté, les variables de table (généralement avec des données plus petites) sont conservées en mémoire (RAM), ce qui les rend plus rapides d'accès et donc moins d'E/S disque en termes d'utilisation du lecteur tempdb lors de l'utilisation de variables de table avec des données plus petites par rapport aux tables temporaires qui sont toujours connectez-vous à tempdb.

Les variables de table ne peuvent pas être indexées tandis que les tables temporaires (locales et globales) peuvent être indexées pour un traitement plus rapide si la quantité de données est importante.Vous connaissez ainsi votre choix en cas de traitement plus rapide avec des volumes de données plus importants par des transactions temporaires.Il convient également de noter que les transactions sur les variables de table seules ne sont pas enregistrées et ne peuvent pas être annulées, tandis que celles effectuées sur des tables temporaires peuvent être annulées !

En résumé, les variables de table conviennent mieux aux données plus petites, tandis que les tables temporaires conviennent mieux aux données plus volumineuses traitées temporairement.Si vous souhaitez également un contrôle approprié des transactions à l'aide de blocs de transactions, les variables de table ne sont pas une option pour annuler les transactions, il est donc préférable d'utiliser des tables temporaires dans ce cas.

Enfin, les tables temporaires augmenteront toujours les E/S du disque puisqu'elles utilisent toujours tempdb alors que les variables de table peuvent ne pas l'augmenter, en fonction des niveaux de sollicitation de la mémoire.

Faites-moi savoir si vous souhaitez des conseils sur la façon d'ajuster votre tempdb pour obtenir des performances beaucoup plus rapides et dépasser 100 % !

Answer 7

La syntaxe souhaitée est la suivante :

créer une table #tablename

Le préfixe # identifie la table comme table temporaire.

Answer 8

CRÉER UNE TABLE #tmptablename

Utilisez le préfixe dièse/dièse