MS SQL Server
  1. MS SQL Server
  3. Est-ce une mauvaise pratique de créer des index en utilisant toutes les colonnes dans include?
Intereting Posts
Comment convertir efficacement le prix dans SELECT en utilisant la table de taux de change existante avec une structure donnée? Procédure stockée entraînant un timeout d'attente uniquement lors de l'exécution de l'application SqlIaaSExtension.Service interrompu sur Azure SQL Server 2016 VM Aide avec la requête UPDATE dans SQL Server JDBC commit (): que se passe-t-il dans les coulisses? SQL Joining Query Comment faire Comment listr toutes les tables dans toutes les bases de données dans SQL Server dans un set de résultats unique? Pourquoi l'ancienne valeur rest-t-elle dans cet object après sa réinitialisation? Trouver des mots de séquençage SQL Requête T-SQL pour les articles de réplication SQL: vérifiez si une colonne de time est supérieure à l'heure système TSQL – Remplissage des valeurs au-dessus et au-dessous d'une input en faisant reference à d'autres colonnes Jointure interne de SQL Server Création d'loggings en double Les objects de support de diagramme de database ne peuvent pas être installés … aucun propriétaire valide Procédure SQL Server pour searchr les lignes de la table dont l'ID commence avec un nombre spécifique ne fonctionnant pas

Est-ce une mauvaise pratique de créer des index en utilisant toutes les colonnes dans include?

J'ai une table et je crée des index non-groupés sur des champs qui sont fréquemment utilisés dans la search dans la clause where. Je crée des index en utilisant la clause include et y mets tous les champs.

Ex: 

Create NonClustered Index IX_DocumentDate on Documents ( DocumentDate ) Include( JurisdictionID, JudgementTypeID, IDate, EfileDate, UserID, RecordingDateTime, ApprovedBy, ACEfileBankAccountID, LastStatusChangedDateTime, ACEfileCreditCardID, EfiledByUserID, ITypeID, IGroupID, InstrumentID, OldInstrumentID, [CreatedByJurisdictionID], CreatedByAccountID, [DocumentStatusID] ,[Remarks] ,[InternalNotes] ,[ParentDocumentID] ,[FilingNumber] ,[StampData] ,[Receipt] ,[ReceiptNo] ,[IsReEfiled] ,[ImportedFromInstrumentID] )

Par contre, il suffit de créer des index. Ces champs sont tous utilisés dans Select . Je voulais juste savoir que je le fais mal? Je reçois un énorme bonus de performance quand je le fais comme ça. Si cela est correct, alors pourquoi Microsoft ne l'a-t-il pas utilisé comme option par défaut et inclut tous les champs de la table include ?

Oui. En général, en SQL, il est toujours mauvais d'avoir un pattern – un LOT dépend de l'utilisation et cela va varier.

Dans le cas ci-dessus, cela peut ou non être sage ou nécessaire ou bénéfique. N'oubliez pas que vous payez un prix – en taille de disque (= IO et plus d'utilisation de la RAM) ainsi qu'en mise à jour et insertion de la vitesse (plus lente).

En général, INCLUDE doit être utilisé avec prudence. Commencez sans, puis utilisez-le là où vous avez des problèmes et ça aide.

Vous stockez votre table entière deux fois, une fois dans l'index, une fois dans la table principale. Ceci est généralement considéré comme un gaspillage d'espace. Cela réduit également l'efficacité de l'indice; il y a plus de données à lire qu'il n'y en aurait si vous vous reteniez de ne pas inclure de colonnes, ou seulement quelques colonnes incluses. Il peut être judicieux d'inclure la colonne d'ID de document primaire dans l'index (bien qu'il ne soit pas clair quelle colonne est l'ID de document principal), mais la majorité des colonnes que vous avez incluses sont clairement superflues à l'index.

Donc, la raison pour laquelle ce n'est pas le comportement par défaut est qu'il n'est pas aussi efficace qu'un index sans colonnes incluses. Par conséquent, n'incluez aucune colonne dans l'index tant que vous n'en avez pas besoin et mesurez que cela améliore les performances.

Vous pouvez essayer Index cluster pour une colonne, peut-être avec la key primaire, puis vérifier les performances. Vous pouvez comparer les performances de l'index clusterisé avec les index avec toutes les colonnes. La meilleure pratique indique que vous devez avoir des index minimum selon les besoins.