Besoin de conseils sur la sélection d'un index clusterisé pour une table de journalisation

Question

J'utilise SQL Server 2005. J'ai une simple table de journalisation que mon application Web utilise pour suivre les activités des utilisateurs et les URL visitées. La conception de la table est très simple

ID (valeur d'identité),

LogDate (datetime),

Activité (nvarchar (200)),

Url (nvarchar (1000))

Nous faisons principalement des insertions dans cette table. De temps en temps, nous effectuons des requêtes sur cette table si nous voulons examiner les activités d'un utilisateur particulier sur une période donnée. La table possède actuellement une colonne d'identité en tant que clé primaire. C'est aussi son index clusterisé.

Je me demande s'il est préférable pour moi de changer son index clusterisé dans la colonne LogDate. La colonne LogDate stocke la date/heure de l'activité et peut avoir des doublons, mais étant donné que nous insérons toujours dans la table, les nouveaux enregistrements doivent toujours se trouver à la fin de la table. SQL Server n'a donc aucune raison regorganise ou effectue des découpages de page qui affecteraient les performances d'insertion. Avoir la colonne LogDate en tant qu'index en cluster devrait également aider à rechercher des performances.

S'il vous plaît laissez-moi savoir si mon raisonnement est correct. Je vous remercie!

Answer 1

Oui, votre raisonnement est correct, à condition que le taux d'inserts est beaucoup moins que la granularité de datetime (3.33ms)

SQL Server 2008 a un nouveau type de données, DATETIME2, avec une plus grande précision (100 nanosecondes).

Si vous laissez une quantité raisonnable d'espace libre (FILLFACTOR entre 80 et 90) et reconstruisez l'index régulièrement (une fois par semaine), tout devrait bien se passer.

Answer 2

Je pense que la meilleure option est d'utiliser le "Assistant de configuration du moteur de base de données". Ceci prendra soin de choisir le meilleur choix pour votre cas. Vous avez juste besoin de l'exécuter assez longtemps pour couvrir vos différents cas afin que son analyse corresponde au mieux à votre cas réel.

Vous pouvez trouver plus à http://msdn.microsoft.com/en-us/library/ms189303%28SQL.90%29.aspx (pour le serveur SQL 2005)

Answer 3

Avant de choisir des index de clustering, nous devons définir des priorités. Quoi de plus important: accélérer les sélections peu fréquentes ou ralentir au minimum les insertions fréquentes? Si vos inserts sont plus importants, conservez l'index de cluster existant.