Optimisation des performances d'une instruction de mise à jour dans SQL SERVER

J'ai 2 déclarations de mise à jour. une fois exécuté set prend plus de 12 heures de SSIS. Tous les index de cette table ont été désactivés avant d'exécuter ces instructions de mise à jour. J'ai besoin d'améliorer la performance. J'ai besoin de suggestions:

1) Première mise à jour

Update Db1.table1 Set Db1.table1.col1 = Db2.table2.col1 from Db1.table1, Db2.table2 where Db1.table1.col2 = Db2.table2.col2

2) Deuxième mise à jour

 update table1 set table1.col3 = 0 from table1 where table1.col3 is null

Est-ce que la mise à jour par lots peut aider à améliorer les performances de la première mise à jour? Je vois avoir une valeur par défaut sur col3 est suffisante au lieu d'exécuter la deuxième mise à jour. Mais je ne suis pas sûr si cela affecte les requêtes d'insertion. La table a beaucoup de données. Je ne suis pas sûr de modifier la table pour inclure la valeur par défaut sur une colonne où table a beaucoup de données.

S'il vous plaît fournir vos suggestions pour la performance affiner les déclarations ci-dessus. Veuillez également noter que je n'ai pas les permissions appropriées sur la database pour vérifier le plan d'exécution.

Premièrement, il serait utile de savoir quelle mise à jour prend plus de time. Mais, les index ne sont pas nécessairement votre ennemi lors des mises à jour.

La première mise à jour:

 Update t1 Set t1.col1 = t2.col2 from Db1.table1 t1 join Db2.table2 t2 on t1.col2 = t2.col2;

Cette mise à jour a vraiment besoin d'un index sur db2.table2(col2) . Sinon, il faudra faire une jointure de boucle nestede.

La deuxième mise à jour:

 update table1 set table1.col3 = 0 from table1 where table1.col3 is null

est un peu plus compliqué. Vous mettez à jour la colonne dans la clause where . Mon sentiment est que si relativement peu de valeurs sont null – jusqu'à quelques pour cent – alors un index sur table1(col3) aiderait. Si la plupart des colonnes sont nulles, un index serait less utile. Sans index, cela nécessite un scan de table complet et ne devrait pas être absurdement lent.

Vous findez peut-être que la mise en lots des mises à jour sur cette table améliorerait les performances.

Lors de la première déclaration, vous devez:

avoir un index clusterisé sur table1.col2
avoir un index clusterisé sur table2.col2

Be ware: vous ne pouvez avoir qu'un seul index cluster par table (car cet index indique comment stocker physiquement datatables) et il DOIT ÊTRE LE PREMIER INDEX créé sur une table (et vice versa: le dernier que vous supprimez)

coordonner l'ordre des actions:

créer une table
créer un index clusterisé (unique ou non, peu importe)
créer des index non-arrondis

respectivement:

supprimer les index non clusterisés
supprimer l'index clusterisé
déposer une table