Je travaille sur différentes techniques d'optimisation des requêtes. J'ai réduit le temps d'exécution des requêtes de 1 minute à 12 secondes simplement en ajoutant un index non clusterisé sur une table comprenant une colonne (qui est utilisée dans plusieurs conditions where), mais DBA est très pointilleux sur l'ajout d'index.
Je voudrais savoir si cela fait une différence en ajoutant NCI sur une table temporaire au lieu d'une table réelle. Si OUI, comment? Si NON, pourquoi?
Synopsis sur l'approche d'ajout dynamique de NCI sur une table à fort trafic:
Le temps consacré à la création de NCI sur une table temporaire était bien plus que la lecture. Donc, dans l'ensemble, il a fallu beaucoup plus de temps pour exécuter la requête.
NCI sur la table réelle est beaucoup plus rapide.
Enfin, nous avons décidé d'optimiser un peu la requête et de créer NCI sur la table réelle.
La réponse à ma question est OUI
cela fait une énorme différence lorsque vous créez NCI sur une table temporaire par rapport à une table réelle. Au moins pour mon scénario (table à fort trafic avec des millions d'enregistrements et des données qui arrivent constamment), c'est une approche incorrecte pour créer NCI sur la table temporaire car il faut plus de temps pour construire l'index que pour le lire (encore une fois, c'est pour mon type de scénario).
Ma compréhension des index était limitée lorsque j'ai posé la question. J'ai appris un peu plus aujourd'hui.
Merci tout le monde!
Les tables temporaires respectent les mêmes règles que les tables permanentes en matière d'indexation. La seule différence réside dans l'emplacement de stockage, qui est Tempdb pour les tables temporaires.
Cependant, si vous ajoutez un index à une table qui est fortement écrit, vous devez prendre en compte le compromis écriture/lecture.
Étant donné que la table temporaire est probablement utilisée dans une procédure ou dans un script, c'est votre code qui contrôle la force avec laquelle vous frappez la table avec des écritures.
Les INSERT sont plus rapides sans index en place: si vous insérez beaucoup de données dans plusieurs instructions, vous souhaiterez probablement créer l'index après avoir entièrement rempli la table.
Les MISES À JOUR et SUPPRIMER doivent d'abord trouver la ou les lignes à modifier, afin de bénéficier grandement d'une indexation appropriée.
Si votre DBA veut payer (beaucoup) plus de lectures + CPU + temps écoulé par rapport à certaines écritures, je pense qu'il devrait clarifier son point.
Pour faire court, si votre code s'exécute plus rapidement avec un NCI, continuez et ajoutez-le.
Quel genre de différences recherchez-vous? La différence est que la table est stockée dans tempdb
, par opposition à la base de données actuelle. Il en va de même pour l'index. Voir ci-dessous:
use TestDB;
go
if exists (select 1 from tempdb.sys.tables where name like '#MyTempTable%')
begin
drop table #MyTempTable;
end
create table #MyTempTable
(
id int identity(1, 1) not null
);
go
insert into #MyTempTable
default values;
go 100
select *
from #MyTempTable;
create unique nonclustered index IX_MyTempTable
on #MyTempTable (id);
go
select
name,
object_id,
type_desc
from tempdb.sys.tables
where name like '#MyTempTable%';
select
name,
object_id,
index_id,
type_desc
from tempdb.sys.indexes
where name = 'IX_MyTempTable';
Vous devriez voir quelque chose de similaire à la sortie ci-dessus:
name object_id type_desc
-------------------------- ----------- ---------
#MyTempTable________...... -1516322775 USER_TABLE
name object_id index_id type_desc
-------------- ----------- ----------- ---------
IX_MyTempTable -1516322775 2 NONCLUSTERED
Quelles autres différences recherchez-vous? Quelle est la justification des administrateurs de base de données derrière le malaise de créer un index sur une table temporaire?