8
votes

Pourquoi une mise à jour prend-elle beaucoup plus de temps qu'une sélection?

J'ai la déclaration de sélection suivante qui finit presque instantanément. xxx

Cependant, l'instruction de mise à jour équivalente prend 1m40S xxx même si J'ajouterai: xxx

à la fin de l'instruction de mise à jour réduisant le nombre d'écritures à zéro, il faut le même temps.

Est-ce que je fais quelque chose de mal ici? Pourquoi y a-t-il une telle différence?


1 commentaires

L'extra et la clause est toujours une bonne idée, pourquoi mettre à jour 50 000 lignes lorsque vous n'avez besoin que de mettre à jour 2?


4 Réponses :


1
votes

Parce que la lecture n'affecte pas les indices, les déclencheurs et ce que vous avez?


0 commentaires

6
votes

La mise à jour doit verrouiller et modifier les données dans la table et enregistrer également les modifications apportées au journal des transactions. Le Select n'a pas à faire de ces choses.


3 commentaires

Nitpick: Vous peut avoir DML dans une déclaration de sélection, il n'est tout simplement pas écrit ... Sauf si c'est un insert dans ... Sélectionnez ...


Et modifiez également les index sur la table. Plus les index, plus l'écriture est longue.


Alors pourquoi cela prend-il beaucoup de temps même avec l'état supplémentaire? Il devrait y avoir zéro changements sur les tables, mais cela prend encore beaucoup de temps.



23
votes
  • Le fichier journal de transaction écrit
  • Mises à jour d'index
  • Recherche de clé étrangère
  • Touches étrangères Cascades
  • Vues indexées
  • Colonnes calculées
  • Vérifiez les contraintes
  • LOCKS
  • loquets
  • Serrure Escalation
  • Isolation d'instantané d'instantané
  • dB miroir
  • Croissance du fichier
  • Autres processus Lecture / Écriture
  • SIGNITÉS DE LA PAGE / Index en cluster non adapté
  • Evénements de dépassement de pointeur / rangée en ligne
  • Index pauvres
  • Statistiques hors de date
  • Mauvaise mise en page de disque (par exemple un gros raid pour tout)
  • Vérifiez les contraintes avec les UDF qui ont accès à la table
  • ...

    Bien que le suspect habituel est un "fort> déclencheur ...

    Aussi, votre condition extra n'a pas de sens: comment SQL Server peut-il savoir l'ignorer? Une mise à jour est toujours générée avec la plupart des bagages ... Même la gâchette va toujours tirer. Les serrures doivent être tenues pendant que les lignes sont recherchées pour les autres conditions, par exemple

    Edité SEP 2011 et février 2012 avec plus d'options


2 commentaires

Oui, un déclencheur était la cause. Je suis nouveau à cela et le "code" n'est pas à moi. Merci pour l'information. J'ai ajouté la condition supplémentaire parce que je pensais que cela pourrait prendre trop de temps pour écrire sur le disque, il n'y avait donc pas d'écrivies inutiles sur le disque. Encore une fois, merci beaucoup.


Et des déclencheurs en particulier qui sont "conçus" pour curseur à travers toutes les lignes au lieu de courir de manière basée sur un ensemble!



1
votes

dans des serveurs lents ou une grande base de données, j'utilise habituellement la mise à jour retardée, qui attend une "pause" de mettre à jour la base de données elle-même.


0 commentaires