Comparaison de performances SQL Server - tables temporaires ou variables de table? Ou autre chose?

Question

Dans SQL Server, j'essaie de faire une analyse comparative entre deux structures de tables différentes en ce qui concerne les performances d'insertion avec différentes clés. Est-ce important si j'utilise une variable de table pour faire ce test, ou devrais-je utiliser une table temporaire? Ou dois-je prendre la peine de créer les tables et les index?

Plus précisément, je suis actuellement en utilisant le script suivant:

DECLARE @uniqueidentifierTest TABLE 
(
    --yes, this is terrible, but I am looking for numbers on how bad this is :) 
    tblIndex UNIQUEIDENTIFIER PRIMARY KEY CLUSTERED, 
    foo INT, 
    blah VARCHAR(100) 
) 

DECLARE @intTest TABLE 
(
    tblindex INT IDENTITY(1,1) PRIMARY KEY CLUSTERED, 
    foo INT, 
    blah VARCHAR(100) 
) 

DECLARE @iterations INT = 250000 
DECLARE @ctrl INT = 1 

DECLARE @guidKey UNIQUEIDENTIFIER 
DECLARE @intKey INT 

DECLARE @foo INT = 1234 
DECLARE @blah VARCHAR(100) = 'asdfjifsdj fds89fsdio23r' 

SET NOCOUNT ON 

--test uniqueidentifier pk inserts 
PRINT 'begin uniqueidentifier insert test at ' + CONVERT(VARCHAR(50), GETDATE(), 109) 
WHILE @ctrl < @iterations 
BEGIN 
    SET @guidKey = NEWID() 

    INSERT INTO @uniqueidentifierTest (tblIndex, foo, blah) 
     VALUES (@guidKey, @foo, @blah) 

    SET @ctrl = @ctrl + 1 
END 
PRINT 'end uniqueidentifier insert test at ' + CONVERT(VARCHAR(50), GETDATE(), 109) 

SET @CTRL = 1 

--test int pk inserts 
PRINT 'begin int insert test at ' + CONVERT(VARCHAR(50), GETDATE(), 109) 
WHILE @ctrl < @iterations 
BEGIN 
    INSERT INTO @intTest (foo, blah) 
     VALUES (@foo, @blah) 

    SET @ctrl = @ctrl + 1 
END 
PRINT 'end int insert test at ' + CONVERT(VARCHAR(50), GETDATE(), 109) 

SET NOCOUNT OFF 

Answer 1

Si vous voulez comparer les performances réelles, vous devez créer les tables et les index (et tout le reste impliqué). Alors qu'une table temporaire sera un bien meilleur analogue qu'une variable de table, elle ne remplace pas non plus une structure de table permanente réelle si vous recherchez des mesures de performance. Ceci dit, vous devriez éviter d'utiliser uniqueidentifier comme clé primaire ou, à tout le moins, utiliser newsequentialid() plutôt que newid(). Avoir un index clusterisé signifie que les lignes seront réellement stockées dans l'ordre physique. Si une valeur insérée est hors séquence, SQL Server devra réorganiser les lignes afin de l'insérer dans son emplacement approprié.

Answer 2

tout d'abord regrouper jamais sur un uniqueidentifier lors de l'utilisation newid(), il provoque la fragmentation et donc fractionnements, si vous devez utiliser un GUID puis le faire comme ça

create table #test (id uniqueidentifier primary key defualt newsequentialid()) 

newsequentialid() ne causera pas fractionnements

encore un int est encore mieux que le PK depuis maintenant tous vos index non ordonnés en clusters et les clés étrangères seront plus petits et maintenant vous avez besoin de moins IO pour obtenir les mêmes numéros de lignes arrière

Answer 3

I dunn o pourquoi mais je voudrais citer Remus Rusanu [1]:

Tout d'abord, vous devez exécuter la requête à plusieurs reprises sous chaque [censuré] et en moyenne le résultat, en écartant l'un avec le maximum de temps. Cela éliminera l'impact du préchauffage du tampon: vous voulez que toutes les analyses soient dans un cache chaud, ne pas avoir une requête pour réchauffer le cache et payer la pénalité en comparaison.

Ensuite, vous devez vous assurer de mesurer dans un scénario de concurrence réaliste. SI vous aurez des mises à jour/insertions/suppressions se produisent dans la vraie vie, alors vous devez les ajouter à votre test, car ils auront un impact énorme sur les lectures sous différents niveaux d'isolement. La dernière chose que vous voulez est de conclure que «les lectures sérialisables sont les plus rapides, utilisons-les partout» et que le système se fondre dans la production parce que tout est sérialisé.

1) L'exécution de la requête sur un cache froid n'est pas précise. Vos requêtes de production ne s'exécuteront pas sur un cache froid, vous optimiserez un scénario irréaliste et vous ne mesurerez pas la requête, vous mesurerez réellement le débit de lecture du disque. Vous devez également mesurer la performance sur une cache chaude et garder une trace des deux (temps d'exécution à froid, temps d'exécution à chaud).

Quelle est la pertinence du cache pour une requête volumineuse (en millions de lignes) qui, dans des circonstances normales, ne s'exécute qu'une seule fois pour des données particulières? Toujours très pertinent. Même si les données sont si grandes qu'elles ne tiennent jamais dans la mémoire et que chaque exécution doit relire chaque page de la table, il y a toujours la mise en cache des pages non-feuille (pages chaudes dans la table, racine ou racine proche), cache des index non clusterisés plus étroits, cache des métadonnées de table.Ne pensez pas à votre table en tant que fichier ISAM

[1] Pourquoi un meilleur niveau d'isolement signifie de meilleures performances dans SQL Server
Why better isolation level means better performance in SQL Server