Discussion :

[boby62423]

Bonjour,

J'ai un site sur lequel il y a pas mal de traffic.
Sur chaque page, j'insère des données dans une table. Les infos que je stocke sont (entre autres): l'ip du visiteur, un numéro qui correspond à la page et un numéro qui correspond au referer (site qui a envoyé le visiteur).

Cela représente des données très volumineuses.
Afin d'établir des stats, je suis amené à faire de manière reguliere des select sur cette table.
Le select porte sur l'ip, mais aussi sur les différents numéros (N° de referer, N° de la page, etc.)

Si je lit mot pour mot la litterature, je vois qu'il faut faire un index multiple sur l'ensemble des champs qui interviennent dans le where.

Dans mon cas, cela conduit à générer un index assez lourd car il existe beaucoup de combinaisons d'ip/referer/pages.

Je remarque que pour une ip donnée, il y a finalement peu d'enregistrements.

Je serais tenté de placer un index juste sur l'ip du coup...

Est ce que quelqu'un peut me donner son avis sur la question ?

D'avance Merci

[mikedavem]

Bonsoir,

Un index sera d'autant plus performant qu'il sera sélectif.
Effectivement mettre un index sur l'ip peut être une bonne chose à voir.

Tout dépend ensuite comment vous filtrez dans la clause WHERE, il faudra sûrement ajouter certaines colonnes.

Si votre index est trop lourd, il vous reste la possibilité d'inclure certaines colonnes dans votre index... possible avec SQL Server 2005

++

[boby62423]

Justement, c'est ma question ! Est ce qu'il faut que je fasse un index multiple !

Mon where est hyper simple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select * from tableStats where adresseIp='x.x.x.x' and numeroReferer=5 and numeroPage=10

Je résume ma question:

Est ce que je fait un index multiple sur (adresseIp, numeroReferer, numeroPage) ?
Ou bien un index simple uniquement sur (adresseIp).

Sachant que : donnée essentielle : pour une IP donnée il n'y a pas beaucoup d'enregistrements (on va dire une cinquantaine en moyenne alors que la table en contient plusieurs dizaine de milliers...)

D'avance Merci !

[mikedavem]

Vous historisez donc vos logs.

Dites moi si je me trompe mais dans ce cas vous allez avoir beaucoup d'enregistrements pour une IP au bout d'un certain temps.. Vous allez également avoir un critère de date je suppose ... ou est ce que vous videz cette table ou bout d'un certain laps de temps ??

Pouvez vous nous en dire plus sur la structure de votre table tableStats ?

Quoi qu'il en soit, si dans votre SELECT * (A éviter), vous ne récupérez que les informations contenus dans la restricition de votre requête, il est intéressant de mettre dans votre index toutes les colonnes concernés par cette restriction. Dans le cas contraire, même si vous allez utiliser votre index, étant donné que celui-ci ne contiendra pas toutes les informations nécessaires il devrait faire une recherche par clés dans votre table.. donc mois performant ...

++

[SQLpro]

Avez vous une clef primaire dans cette table ?
Si oui, est-elle cluster ??
Si non, il serait intéressant de faire un index cluster sur la combinaison adresseIp, numeroReferer, numeroPage mais dans ce cas :
1) mettre un fill factor assez important (tout dépend du nombre d'insertion par jour par rapport au volume de la table)
2) ré indexer cette table une fois par jour aux heures creuses.

Donnez nous le script complet de votre table contraintes comprises, le volume de données actuel (sp_spaceused 'matable') et le nombre moyen de ligne inséré par jour.

A +

[boby62423]

Cette table est en fait vidée a intervalle régulier (tout ce qui a plus de x heures) donc le nombre d'enreg par IP reste le même.

Il n'y a pas de clef primaire.

Je dit peut être une connerie, mais l'idée de mettre un index cluster sur tous les champs me fait peur: ça va créer un index immense et sql server va être hyper chargé pour construire ces index (qqsoit la valeur du fill factor).

D'ou l'idée de faire un index simple sur IP...