Combien de temps une requête renvoyant 5 millions d'enregistrements doit-elle prendre?
Je me rends compte que la réponse devrait probablement être «le moins de temps possible», mais j'essaie d'apprendre comment optimiser les bases de données et je n'ai aucune idée du temps acceptable pour mon matériel.
Pour commencer, j'utilise ma machine locale avec une copie de SQL Server 2008 Express. J'ai un processeur dual-core, 2 Go de RAM et un système d'exploitation 64 bits (si cela fait une différence). J'utilise seulement une table simple avec environ 6 champs varchar.
Au début, j'ai interrogé les données sans aucune indexation. Cela a pris un temps ridiculement long, j'ai donc annulé et ajouté un index clusterisé (utilisant la clé PK) à la table. Cela a réduit le temps à 1 minute 14 secondes. Je ne sais pas si c'est le meilleur que je puisse obtenir ou si je suis encore capable de le réduire encore plus?
Suis-je limité par mon matériel ou puis-je faire autre chose à ma table/base de données/requêtes pour obtenir des résultats plus rapidement?
Pour votre information, j'utilise uniquement un SELECT * FROM standard pour récupérer mes résultats.
Merci!
EDIT: Juste pour clarifier, je ne fais cela qu'à des fins de test. Je n'ai PAS BESOIN d'extraire toutes les données, je l'utilise simplement comme test cohérent pour voir si je peux réduire les temps d'interrogation.
Je suppose que ce que je demande, c’est: Est-ce que je peux faire quelque chose pour accélérer les performances de mes requêtes autres que a) la mise à niveau du matériel et b) l’ajout d’index (en supposant que le schéma soit déjà bon)?
Je pense que vous posez la mauvaise question.
Tout d’abord, pourquoi avez-vous besoin de tant d’articles à la fois sur la machine locale? Que voulez-vous faire avec eux?
Pourquoi je demande? Je pense que cette quantité de données sera transférée quelque part. Et seulement à ce moment-là, vous devriez mesurer le temps de transfert des données.
Et même dans cette situation, je tiens à vous conseiller:
Vos applications ne doivent pas sélectionner 5 millions d'enregistrements à la fois. Essayez de scinder votre requête et d’obtenir des données partiellement.
METTRE À JOUR:
Comme vous dites le faire pour les tests, je vous suggère de:
- Supprimer
*de votre requête - SQL Server met du temps à résoudre ce problème. - Essayez de mettre vos données dans un stockage de données temporaire. Essayez d’utiliser
VIEWou une table temporaire pour cela. - Essayez d’utiliser un plan cache sur votre serveur
Mais je ne comprends toujours pas - pourquoi avez-vous besoin de tels tests si votre application n’utilise jamais une telle requête? Tester uniquement pour tester, c'est perdre du temps .
Regardez le plan d'exécution de la requête. Si votre requête effectue un balayage de table, cela prendra évidemment beaucoup de temps. Le plan d'exécution de la requête peut vous aider à choisir le type d'indexation nécessaire sur la table. En outre, la création de partitions de table peut parfois être utile dans les cas où les données sont partitionnées par une condition (généralement la date et l'heure).
La meilleure façon optimisée dépend de la stratégie d'indexation que vous choisissez. Comme bon nombre des réponses ci-dessus, je dirais aussi que partitionner la table aiderait parfois. Et ce n’est pas la meilleure pratique pour interroger tout le milliard d’enregistrements au cours d’une même période. Vous obtiendrez de meilleurs résultats si vous pouviez essayer d'interroger partiellement les itérations. vous pouvez vérifier ce lien pour dissiper les doutes sur la configuration minimale requise pour le serveur SQL 2008 H/W minimum et S/W Configuration requise pour le serveur SQL 2008
J'ai fait 5,5 millions en 20 secondes. Cela prend plus de 100 000 horaires avec différentes fréquences et les prévoit pour les 25 prochaines années. Just max test de scénario, mais prouve la vitesse que vous pouvez atteindre dans un système de planification, par exemple.
Lorsque vous fectez 5 millions de lignes, vous êtes presque 100% en train de passer de spool à tempdb. vous devriez essayer d'optimiser votre base de données temporaire en ajoutant des fichiers supplémentaires. si vous avez plusieurs lecteurs sur des disques distincts, vous devez fractionner les données de la table en différents fichiers ndf situés sur des disques distincts. le partitionnement ne vous aidera pas lors de la recherche de toutes les données sur le disque . Vous pouvez également utiliser un indicateur de requête pour forcer le parrallélisme MAXDOP, ce qui augmentera l'utilisation de la CPU. Assurez-vous que les colonnes contiennent le moins possible de NULL et reconstruisez vos index et vos statistiques.