question requête tsql et l'index

Question

J'ai une table qui stocke des informations de photo avec id comme clé primaire:

id (PK), titre, album_id, posted_by, publié, nom de fichier, les balises, les cotes, date_posted

ce tableau tiendra infor de plus de 100 millions de photos et j'ai besoin pour exécuter cette requête comme celles-ci fréquemment:

1) obtenir toutes les photos (juste id, nom de fichier, les colonnes de titre) d'un album donné

id select, nom, titre à partir de photos où album_id = @AlbumId et publié = 1

2) obtenir toutes les photos publiées d'un utilisateur donné mais excluent les photos actuellement regarder album

select id, nom, titre à partir de photos où posted_by = 'bob' et album_id <> 10 et publié = 1

Je veux éviter l'index et l'analyse de la table. Je dois utiliser chercher (disons 100%) autant que possible.

Est-ce que cela peut être fait? Quel type d'index et sur quelles colonnes m'y aiderais?

Merci

Answer 1

En réalité, vous ne pourrez le découvrir vous-même en mesure de la performance avant tweak, puis tweak, et mesurer encore et encore.

Mais en fonction de votre requête, vous devriez considérer (ou au moins essayer en premier) un index non cluster comme ceci:

CREATE NONCLUSTERED INDEX IX01_Photos 
    ON dbo.Photos(album_id, published, posted_by) 
    INCLUDE(id, filename, title) 

Raisonnement:

• fois vos requêtes les plus fréquentes ont WHERE clauses utilisant album_id et published - donc utilisez ces deux colonnes d'abord dans votre index
• votre deuxième requête comprend également posted_by dans la clause WHERE - mettre que dans ce même i ndex comme la troisième colonne
• afin d'éviter les recherches de signets coûteux dans la table de données réelles, vous pouvez inclure les id, filename, title colonnes de l'index

Avec toutes ces choses en place, vous devriez être voir la plupart du temps index recherche sur ce nouvel index non cluster pour satisfaire vos requêtes. Mais encore une fois: beaucoup d'autres facteurs entrent en jeu que vous n'avez probablement pas mentionnés dans votre question et peut-être même pas pensé à vous-même - mais cette approche devrait vous donner un bon point de départ pas moins.

Answer 2

Vous n'avez pas mentionné s'il est nécessaire d'utiliser le paramètre date_posted ou id comme critère de filtrage dans la requête. Il est donc préférable d'utiliser un index CLUSTERED sur une colonne non chronologique (je suppose que le l'index actuel de CLUSTERED est le PK. Droit?).

Je créerais un index CLUSTERED sur l'album_id.

Si vous ne pouvez pas modifier l'index CLUSTERED ou il y a beaucoup d'autres questions qui bénéficient de l'index ordonné en clusters existant, je soutiens la réponse de @marc_s (et voter en conséquence.)

Answer 3

Je suggère une index clusterisé sur album_id et un index secondaire sur posted_by, si le premier est celui qui sera le plus touché. Inversez-les si posted_by est touché le plus. Selon le nombre de photos pour chaque album_id ou posted_by, il peut être tout à fait possible de filtrer sur published dans le code appelant (en d'autres termes, ne l'ajoutez pas comme une restriction dans la requête, plutôt que le côté client de filtrage). Sinon, vous devrez ajouter cette contrainte publiée dans la requête, mais la restriction principale de album_id devrait signifier que seul un petit balayage sur published est encouru. Mais comme indiqué, il peut être plus facile de filtrer sur published côté client.

Answer 4

Clé primaire sur Id. Faites-le non-cluster. Je suppose que cela ne sera pas beaucoup utilisé (en particulier si toutes les recherches sont par album ou poster).

Index clusterisé sur AlbumId. On dirait qu'il serait utilisé dans la plupart des requêtes.

Index non clusterisé sur Posted_By. Avec AlbumId l'index clusterisé, il apparaîtra au niveau feuille de cet index, et agira donc comme une colonne INCLUDEd. Selon l'utilisation, il pourrait être préférable d'avoir ceci comme index clusterisé ... mais en tant que varchar (20), il prendrait plus d'espace disque, et les performances seraient pire que AlbumId (en supposant que AlbumId est un int).

Vous ne pouvez pas avoir publié en tant que colonne dans l'index, car vous ne pouvez pas indexer sur les colonnes de bits. Vous ne voudrez pas non plus - avec seulement deux valeurs possibles sur 100M + lignes, SQL ne l'utilisera probablement jamais pour optimiser les requêtes.

Je recommanderais de normaliser Posted_By (le déplacer vers sa propre table, lui donner sa propre clé de substitution, et l'utiliser comme clé étrangère dans cette table). Cela réduirait considérablement l'espace de stockage de votre table principale, augmenterait les performances globales et vous permettrait de retourner l'index clusterisé à cette colonne si nécessaire. (De plus, si "Bob" affiche sur la table, puis "Bob" de l'autre côté de la ville, comment le dites-vous à Bob?)