Un ami et je travaille sur un nouveau projet qui utilise SQL Server. Dans le SQL que j'ai fait des projets passés, j'ai toujours mis des index sur n'importe quel domaine utilisé dans une jointure ou un endroit où.
Mon ami ne les a ajoutés que lorsqu'il y a eu un besoin de performance pour eux. L'idée étant qu'il y ait un coût pour maintenir les index et vous voulez être sûr que cela vaut la peine de payer ce coût. Il est juste de dire que certaines des requêtes ne seront pas utilisées souvent et que certaines tables seront ajoutées plus activement que d'autres.
Je cherche donc des conseils sur quelle est la "meilleure pratique" pour les indices de base de données. Qu'est-ce qui fonctionne bien pour vous?
7 Réponses :
Lors de la conception d'index, suivez ces directives:
- Utilisez des index sur des tables avec de nombreuses lignes, sur des colonnes utilisées dans le Où la clause de requêtes ou dans le tableau rejoint et sur des colonnes utilisées dans l'ordre par et groupe par requêtes.
- Évitez les index usagés rarement utilisés sur des colonnes fréquemment mises à jour. Dans Ajout, évitez d'avoir de nombreux index sur une table qui est fréquemment mise à jour. Sinon, vous augmentez inutilement les heures d'insertion et de mise à jour de votre requêtes. Pour améliorer les performances, minimiser la largeur totale du Colonnes indexées.
- Utilisez des index regroupés et non clusterisés de manière appropriée. Comprendre le but de chacun et choisissez le bon Tapez pour votre scénario.
- Utilisez un index de revêtement pour réduire le temps d'exécution de la requête de manière fréquente déclarations utilisées. Un indice de couverture est un index non clusterisé qui a tout le colonnes qui viennent dans une clause où et dans la sélection de colonne de requête.
comme selon
Vous voulez ne les mettre que sur ces colonnes ou les groupes de colonnes qui ont beaucoup de questions contre eux. Vous pouvez obtenir de nombreuses statistiques de SQL Server pour voir quelles requêtes sont exécutées contre vos tables et SQL Server suggérera même des index où vous ne les avez pas.
Voici un bon lien avec des informations utiles et d'autres liens vers de bonnes informations. Liste de contrôle SQL Server Index et conseils
Ma préférence personnelle va à l'approche L'autre approche, n'ajout que des index où les performances leur nécessitent, ne sont valides que si vous surveillez une surveillance active, mais peut-être même un
Si vous travaillez avec des tables si grand que vous êtes préoccupé par l'impact de la performance de la création d'un nouvel index (en supposant que le système 24/7 de 24/7 sans fenêtres de maintenance ?!) : alors il est significativement < B> plus important que la table n'est pas enlisée avec des index superflus (pouvant même contribuer à des problèmes de verrouillage).
Il n'y a pas de réponse facile pour votre question. Tout est tombé à l'utilisation des tables. Surveillance L'utilisation de la table vous indiquera quoi faire.
select * from sys.dm_db_missing_index_details Get to know your dynamic management viewsAnd then go and use this sproc from this URL http://www.sqlservercentral.com/scripts/Index+Management/63937/Also.. what homedude is saying about 'covered indexes' make sure that you understand the difference between covered indexes (SQL 2000) and indexes with the INCLUDE clause (SQL 2005 and newer)
J'ai trouvé cette table, mais c'est vide. Existe-t-il une option qui doit être activée pour le remplir?
Je n'ai jamais vu de serveur de production avec un DMW vide. Fais-tu cela dans Dev? L'autre moyen de le faire consiste à utiliser SQL Profiler (contre la production) pour capturer une trace, puis pour tester cette charge de travail pour des performances à l'aide du conseiller de syntonisation de la base de données. Je ne sais généralement pas de ne pas l'enregistrer dans un fichier / une table lorsqu'il est en cours d'exécution, mais lorsque la trace du profileur SQL est terminée (lorsque vous appuyez sur STOP), vous pouvez enregistrer les résultats de la trace à une table. Je pense juste que c'est bien mieux de le faire à la fin de la trace, au lieu du début de la trace.
Un index est mieux placé sur une valeur aussi unique que possible . C'est, par exemple, inutile de placer un index sur une colonne où 50% de cette colonne est la valeur "A" et 50% de la colonne a une valeur "B".
De cette façon, la table scannera au moins 50% des enregistrements avant de sélectionner les bonnes valeurs.
SO La meilleure pratique est de placer un index sur les colonnes la plupart des colonnes uniques , et uniquement les colonnes utilisées pour sélectionner des requêtes avec.
Exemple: Si vous deviez créer une sélection pour un "login" typique, vous mettriez un index sur la colonne "Nom d'utilisateur", car vous assurez que le nom d'utilisateur est unique.
J'ai édité ma solution juste avant que vous écriviez votre commentaire, je pense. Je lisais ça et j'ai vu exactement ce que vous venez de mentionner.
Les règles du pouce peuvent être utilisées sous le marteau - index peuvent également être utilisées pour récupérer des données. Ainsi, même si vous avez 50 à 50 données, certaines requêtes peuvent bénéficier d'un index - par exemple le nombre (*) ... 'A' devra lire uniquement l'index. Donc, ce n'est pas nécessairement inutile.
J'essaierais de suivre ces lignes directrices:
a toujours une touche bonne clé principale / clustering - généralement une identité Indexez toujours toutes les colonnes de clé étrangère - séparément ou avec d'autres colonnes qui ont un sens; Cela aide à joindre la performance
autre que celui: Utilisez les DMV à la main (le index manquant DMV et les indices inutilisés DMV ) pour avoir une idée de ce que les indices peuvent aider, ce qui ne sont pas utilisés du tout ... < / p>
int - éviter le GUID ou le grand composé pk / ck. Un PK / CK choisi pensivement et pensivement choisira un long chemin pour aider à la performance globale. Pour bien comprendre pourquoi, lire l'ensemble de Kimberly Tripp's publier des blogs sur la clé de clustering choix.
Cette question est très large. Ne vous attendez pas à des réponses faciles. Vous pouvez faire mieux décisions éduquées Si vous comprenez: comment les structures d'index fonctionnent, comment insertion / mises à jour affectent les indices, l'impact des serrures et l'escalade de verrouillage, les principes de sélectivité, les modèles d'accès à vos données . Mais tout se résume à: Dans un système de toute taille significative, l'indice Tuning est Un processus en cours impliquant la surveillance, le profilage, le marquage de banc et les tests expérimentaux. < / i>
À titre de note latérale: je me demande si vous avez vraiment quelque chose? On dirait que vous avez simplement accepté la réponse qui correspondait la plus étroitement et soutenu votre opinion personnelle. Donc, il semble que vous recherchiez vraiment quelqu'un à la recherche de quelqu'un pour vous soutenir.