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

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

--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)
)

---

Edit:

Suivantes commentaires, je pense que cela a besoin d'un petit éclaircissement.

#table et ##table sera toujours dans la base de données TempDB.

@Table variables sera normalement dans la mémoire, mais ne sont pas garantis. SQL décide basé sur le plan de requête, et utilise la base de données TempDB si il en a besoin.

Il est possible avec MS SQL Server 2014.

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

Voici un exemple de SQL de génération de code (à partir de 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

Je comprends ce que vous essayez d'atteindre. Bienvenue dans le monde d'une variété de bases de données!

SQL server 2000 prend en charge les tables temporaires créées par la préfixation d'un # pour le nom de la table, rendant accessible localement table temporaire (local de la session) et précédé de ## pour le nom de la table, pour accessible dans le monde entier tables temporaires.e.g #MyLocalTable et ##MyGlobalTable respectivement.

SQL server 2005 et au-dessus du support à la fois des tables temporaires (local, global) et les variables de table - méfiez-vous de nouvelles fonctionnalités sur les variables de table dans SQL 2008 et la libération de deux! La différence entre les tables temporaires et les variables de table n'est pas si grand, mais se tient dans la façon dont le serveur de base de données gère.

Je ne voudrais pas parler des versions antérieures de SQL server 7, 6, bien que j'ai travaillé avec eux et c'est là que j'ai pris, de toute façon 🙂

Il est courant de penser que les variables de table toujours résident en mémoire, mais c'est faux. En fonction de l'utilisation de la mémoire et le serveur de base de données de volume de transactions, une variable de table de pages peuvent être exportées à partir de la mémoire et sont écrites dans la base de données tempdb et le reste de la transformation a lieu là-bas (dans la base de données tempdb).

Veuillez noter que la base de données tempdb est une base de données sur une instance avec aucun des objets permanents dans la nature, mais il est responsable de la gestion des charges de travail impliquant les transactions côté comme de tri, et d'autres travaux de traitement qui est de nature temporaire. D'autre part, les variables de table (généralement avec de petits de données) sont conservés dans la mémoire vive (RAM) en les rendant plus rapide d'accès et, par conséquent, moins d'e /s de disque dans l'utilisation de la base de données tempdb disque lors de l'utilisation de variables de table avec des données plus petite par rapport à des tables temporaires qui toujours se connecter à la base de données tempdb.

Table de variables ne peuvent pas être indexées, tandis que les tables temporaires (à la fois locale et mondiale) peuvent être indexées pour un traitement plus rapide dans le cas où la quantité de données est importante. Ainsi vous savez que votre choix en cas de traitement plus rapide, avec de gros volumes de données temporaire des transactions. Il est également intéressant de noter que les opérations sur les variables de table ne sont pas enregistrés et ne peuvent pas être annulées, tandis que celles effectuées sur les tables temporaires peuvent être restaurées!

En résumé, les variables de table sont meilleures pour les petits de données, tandis que les tables temporaires sont mieux pour les grandes données en cours de traitement temporairement. Si vous aussi vous voulez la bonne opération de contrôle à l'aide de la transaction de blocs, les variables de table ne sont pas une option pour l'annulation de transactions de sorte que vous êtes mieux avec des tables temporaires dans ce cas.

Enfin, les tables temporaires seront toujours plus d'e /s disque, car ils utilisent toujours la base de données tempdb, alors que le tableau des variables ne peut pas augmenter, en fonction de la mémoire les niveaux de stress.

Laissez-moi savoir si vous voulez des conseils sur la façon de régler votre base de données tempdb pour gagner beaucoup de performances plus rapides pour aller au-dessus de 100%!

CREATE TABLE #tmptablename

Utiliser le hash/dièse préfixe