Optimisation..question de prudence

Bonjour, jai cette table avec ~25millions denregistrements et que lon insert dedans de facon tres intensive:

Date datetime null
Ident smallint null
Val float null
Status varchar 1 null
marker varchar 1 null

Date est toujours la date courrant (getdate()) au moment de linsertion..donc linsert de ce champ se fait toujours dans lordre croissant (mais la valeur nest pas declarer unique car elle peut ne pas l'etre)

la plupart des query basees sur cette table verifie la Date et le Ident dans des clauses WHERE

la table ne possede aucune cle et aucun index (javais lu que les index sont mauvaise pour des tables que lon insere souvent dedans). Mes query etaient TRES lente avant et jai decider de voir la difference avec des index (jai fais quelques lectures egalement, malgre que je suis encore newbie). La seule facon que jai reussi a optimiser mes query de facon "acceptable" est d'utiliser un CLUSTERED index sur Date. Le resultat en est surprenant!

Mes questions: est que y-a-til des consequence nefastes a utiliser ce genre dindex dans mon cas? (en raison des multiples insertions surtout)?

2e question: ya-t-il une grosse difference de perte de performance lors de linsertion avec un index clustered et non clustered?

Merci

Bonjour,

Citation:

---

Envoyé par maxtin

..donc linsert de ce champ se fait toujours dans lordre croissant

---

: c'est ce que tu crois mais physiquement c'est faux. En fait, SQL server mets les données là où il veut, et y'a pas de notion d'ordre.

Citation:

---

Envoyé par maxtin

est que y-a-til des consequence nefastes a utiliser ce genre dindex dans mon cas? (en raison des multiples insertions surtout)?

---

Ca dépend. Ca dépend du nombre d'enregistrements insérés par paquet. Si cela représente des insertions de 200 000 enregistrements, l'insertion sera plus lente que sans index. Mais y'a une option (me rappelle plus laquelle) qui permet de desactiver la mise à jour auto des statics (faire recherche ca doit être dans ce forum). Si tu as moins de 10% d'enregistrements par paquet, tu ne verras pas de différence.

Attention quand même à l'espace disque ;) Ca consomme un index :mouarf:
Et mets à jour ton index quotidiennement dans un plan de maintenance par exemple (DBCC Checkindex ...). Cette opération peut s'avérer longue mais est très efficace. Il est donc préférable de le faire en fin de journée.

Citation:

---

Envoyé par maxtin

2e question: ya-t-il une grosse difference de perte de performance lors de linsertion avec un index clustered et non clustered?

---

Oui, si on considère ma réponse au point 1. Considère que le "clustered" c'est comme si tu faisais une défragmentation de ton disque. Il va reserver de l'espace et classer "dans l'ordre" les enregistrements suivant l'index pour que tout soit "cote à cote". Les puristes ici me reprendront, mais c'est une métaphore proche de la vérité.

Par ailleurs, si tu utilises souvent les deux colonnes dans tes jointures ou filtres, essaie de faire ton index sur les deux colonnes. Tu gagneras encore un peu de temps vraisemblablement. Par contre, ton index bouffera plus de disque et sera plus long à l'insertion.

Pour finir, il te faudra alors trouver le bon compromis ;). Globalement, index (clustred ou pas) te donnera des temps d'insertions plus longs, si tu insères par paquets. En transactionnel, aucune différence. Et si ca te fait gagner 50% de temps de traitement sur un select, un update, fonce !:mouarf:

Premiererement, je te remercie pour ta reponse detaillée et qui m'eclairci beaucoup.

Les insertions se font 1 record a la fois mais le debit dinsertion est tres eleve. Donc, suite a ta reponse je crois que je nai pas de probleme.

Je sais comment desactiver la mise à jour auto des statics, mais pourrais-je savoir exactement qu'est-ce que ca fait au juste? Est-ce que ca affecte la performance de requete ou seulement celle dinsertion?

INDEXDEFRAG est ce que jutilise pour refaire mes index.. Yen a-t-il un meilleur? Est-ce que je peux quand meme inserer dans ma table meme si un defrag est en cours?

Ok de rien.

Pour tes deux question supplémentaires, je ne peux pas trop t'aider car je me suis permi de te donner mon retour sur expérience (bien que je ne sois pas un vrai informaticien). Or tes questions sont plus pour les spécialistes. Et ici y'en a pleins ;)

une FAQ qui peut t'aider :

http://sqlserver.developpez.com/faq/...formance#Perf1

Citation:

---

Envoyé par HULK

une FAQ qui peut t'aider :

http://sqlserver.developpez.com/faq/...formance#Perf1

---

Merci, mais je connaissais egalement REINDEX mais je me demande quelle serait la mieux pour moi entre DEFRAG et REINDEX? Aussi est-ce que les 2 permet linsertion lors de leur lancement?

reponse trouver pour ceux que ca interesse: http://www.knowdotnet.com/articles/dbccindexdefrag.html

Désolé d'être intervenu en retard, mais l'essentiel est déjà dit par Zers

Citation:

---

1- Supprime l'index avant l'insert
2-Désactive l'autoupdate statistic
3- Lancer les insert
4- Mettre à jour les stats
5- Recrée les index.

---

Je voulais seulement rectifier qu'un insert est toujours plus rapide sans index qu'avec un. Donc pour les insert en lot, il vaut mieux les désactiver.
Vous pouvez tester pour confirmation


Bonne chance.

les insert et les select se font en meme temps pour mon cas (tous est "Online") je dois composer avec les indexes et les insertions...mais jai des test a effctuer avant pour voir