Optimisation du temps d'insertion de données
Bonjour,
A l'installation de notre application, nous devons insérer un grand nombre de données dans la base SQL qui est vide.
De façon à diminuer les temps de traitement, les index ne sont créés qu'après les insert.
Toutefois en ayant testé les 2 solutions, je constate des différences de 15 sec entre les 2 solutions pour des ajouts de 400 000 lignes (durée d'insert 8 min 45 sec) ! Cela me parait bien peu ... Dans cet exemple, 5 index sont concernés dont 1 index trié (où les données sont insérées déjà triées).
Une autre piste d'optimisation a été explorée, à savoir les transactions.
Il ne nous est pas necessaire de pouvoir revenir à l'état initial en cas d'erreur.
En supprimant toutes les transactions, le temps d'import est plus long !
L'application (déjà en production) fonctionne actuellement avec des transactions ouvertes et commitées toutes les 100 lignes.
Y'a-t-il intérêt à augmenter ce nombre de lignes ? à le diminuer ? A-t-on une chance de diminuer le temps d'import en changeant les transactions utilisées ?
Ou pouvons-nous trouver un ordre d'idées sur le volume de lignes que SQL Server peut insérer dans une table à la seconde, si cette ligne est simple (uniquement une dizaine d'entiers par record). Il parait évident que le nombre de lignes traitées ne peut être constant au fur et a mesure que le nombre de lignes déjà présentent dans la base augmente.
Pouvez vous me dire s'il est nécessaire (ou même interessant) de créer un index sur les champs de la clé primaire pour optimiser les recherche sur des filtres sur cette clé ?
Merci beaucoup de vos réponses, si il y a d'autres pistes d'optimisations, je suis tout prêt à les étudier..
J. DUVAL
Répondre avec citation
Partager