Je teste la vitesse d'insertion de plusieurs lignes avec une seule instruction insertion.
Par exemple: Insérez des valeurs [MyTable] (5, 'Dog'), (6, 'Cat'), (3, 'Poisson)
Ceci est très rapide jusqu'à ce que je passe 50 lignes sur une seule déclaration, la vitesse tombe de manière significative.
L'insertion de 10000 lignes avec des lots de 50 prises 0,9 seconde. L'insertion de 10000 lignes avec des lots de 51 prend 5,7 secondes.
Ma question a deux parties:
Mes tests ont été effectués en C ++ et ADO.
EDIT: Il apparaît que le point de dépôt n'est pas de 50 rangées, mais 1000 colonnes. Je reçois des résultats similaires avec 50 lignes de 20 colonnes ou 100 rangées de 10 colonnes.
6 Réponses :
Avez-vous également comparé avec l'approche "Union TOUT" présentées ici? http://blog.sqlauthority.com/2007/06/08/sql-server-insert-multiple-records-utilisateur-insert-statement-utilisateur-funion-all/
Je suppose qu'il y a un cache / index interne utilisé jusqu'à 50 rangées (c'est un bon nombre décimal rond). Après 50 rangs, il redevient sur un algorithme d'insertion d'un cas général moins efficace pouvant gérer des quantités arbitraires d'entrées sans utiliser de mémoire excessive.
Je viens d'essayer l'approche de l'Union. C'est aussi assez lent. Environ 7 secondes pour 10000 rangées.
Le ralentissement est probablement l'analyse des valeurs de chaîne: Essayez quelque chose comme ceci, qui insérera une ligne pour chaque ligne renvoyée par la requête: et voir ce qui se passe valeurs (5, «chien»), (6, 'chat'), (3, 'poisson) et non un problème d'insertion.
Si vous utilisez SQL 2008, vous pouvez utiliser des paramètres de valeur de table et simplement faire une seule instruction insertion.
Personnellement, je n'ai jamais vu le ralentissement à 50 insère des enregistrements même avec des lots réguliers. Peu importe nous sommes déplacés vers des paramètres de valeur de table qui avaient une augmentation significative de la vitesse pour nous.
J'ai essayé cela et comme novice SQL, je ne suis pas certain que je le fais de la manière la plus optimale. Cependant, mes tests montrent n'importe où de 6 secondes à 30 secondes pour 10000 lignes, en fonction de la taille du lot. Rien près de l'insertion de plusieurs rangées.
C'est très étrange. Vous attribuez à tous les champs de la table ou êtes-vous attribués via les valeurs par défaut de colonne? Si le plus tard, ceux-ci peuvent être chers (comme la fonction getDate ()) ...
J'ai suivi l'exemple ici: msdn.microsoft.com/ fr-US / Bibliothèque / BB510489% 28SQL.100% 29.aspx Mais au lieu d'insérer dans la table temporaire d'une autre table, je insère des valeurs à l'aide d'une insertion de plusieurs rangées. Je spécifie toutes les valeurs, aucune valeur par défaut.
Pensées aléatoires:
Oui c'est très cohérent. Et je vidai la table entre chaque test.
@Todd: intéressant. Bonne question. Et je n'ai aucune autre idée cependant :-)
Cela pourrait également être lié à la taille de la ligne. La table que vous utilisez comme exemple semble avoir seulement 2 colonnes. Et si cela a 25 colonnes? La performance diminue-t-elle également à 50 rangées?
Intéressant. Le tableau ci-dessus n'était qu'un exemple, ma table réelle compte 20 colonnes. Je coupe jusqu'à 10 ans et j'ai essayé à nouveau. Maintenant, je reçois la coupe à 100. Les lots de 100 prennent environ 0,6 seconde. Les lots de 101 prennent environ 3,25 secondes. Il apparaît que la limite n'est pas de 50 rangées, mais 1000 champs mis à jour individuels?
On dirait que la coupure ressemble davantage à des données totales en mémoire. Si une table est petite, vous pouvez peut-être que vous puissiez installer 100 rangées dans un «bloc», quel que soit un bloc. Mais de grandes tables, avec de nombreuses colonnes ou avec quelques grandes colonnes (par exemple, Varchar (1200)) limiteraient le nombre de lignes que vous pourriez correspondre à un bloc.
Pour les inserts à volume élevé et à haute fréquence, envisagez d'utiliser inserts en vrac < / a> Pour charger vos données. Ce n'est pas la chose la plus simple du monde de mettre en œuvre et cela apporte un nouvel ensemble de défis, mais cela peut être beaucoup plus rapide que de faire un insert.
J'ai l'impression que cela s'aggrave en raison de l'analyse de l'intrant.
Devinière complète et totale sauvage: moins de 50 lignes sont mises en cache dans la RAM par SQL Server, mais des inserts plus importants sont considérés comme plus «importants» et sont écrits immédiatement sur le disque? Honnêtement, pas sûr (par conséquent, commenter plutôt que de répondre)