Mettre à jour à l'aveuglette ou mettre à jour où?

Question

J'ai une table contenant des informations sur les villes dans un jeu. Vous pouvez construire un bâtiment à chaque tour. Cette valeur est enregistrée avec la valeur & "usedBuilding &";.

À chaque tour, je vais exécuter un script qui modifie usedBuilding en 0. La question est de savoir lequel des deux moyens suivants est le plus rapide et le moyen réellement utilisé importe-t-il?

UPDATE cities SET usedBuilding = 0;
UPDATE cities SET usedBuilding = 0 WHERE usedBuilding = 1;

Answer 1

En général, la clause 2nd cas (avec la clause WHERE) serait plus rapide, car elle ne causera pas d'évaluation du déclencheur, de journalisation des transactions, de mise à jour d'index, etc. sur les lignes inutilisées.

Potentiellement - en fonction de la distribution des valeurs 0/1, il pourrait être plus rapide de mettre à jour toutes les lignes plutôt que de faire la comparaison - mais c'est un cas assez dégénéré.

Étant donné qu'environ 95% des coûts de votre requête sont des E / S, l'utilisation de la clause WHERE ne fera aucune différence (puisque la colonne n'est pas indexée et que vous effectuez un balayage de table), ou une énorme différence (si la colonne est indexé, ou la table partitionnée, etc.). De toute façon, ça ne fait pas mal.

Je soupçonne que, compte tenu de la quantité de données dont vous parlez, vous ne remarquerez aucune différence entre les plans d'exécution ou la rapidité d'exécution - ce qui la rend théorique au mieux, optimisée prématurée au pire. Je vous conseillerais donc de choisir tout ce qui est logique pour votre application.

Answer 2

Si usedBuilding est indexé, il sera plus rapide d’utiliser la clause where car elle n’accédera / ne mettra à jour que les lignes où usedBuilding aura la valeur true. Si ce n’est pas indexé, vous effectuerez quand même une analyse complète de la table, de sorte que cela ne ferait aucune différence (aucune?).

Answer 3

Essayez les deux sens en boucle plusieurs milliers de fois et chronométrez-les! Cela dépend probablement du nombre d'enregistrements réellement présents dans cette table et de leur stockage en mémoire ou de leur pagination sur le disque. Combien de bâtiments sont à la valeur 1 avant d'exécuter la mise à jour (je suppose que cela pourrait être 1).

Peu importe le moyen utilisé, mais le plus petit a probablement le moins qui puisse mal se passer. Le code que vous n'écrivez pas ne peut pas avoir de bugs.

Answer 4

À quelle fréquence ces tournants se produisent-ils? Combien de lignes pensez-vous avoir dans cette table? Si les réponses sont "moins d'une fois par seconde" et "moins de 10 000", arrêtez de vous inquiéter.

À moins que vous n'ayez un intérêt académique pour cela, bien sûr.

Answer 5

Il semble qu’il y aurait un nombre inférieur de transactions pour que le " UPDATE villes SET usedBuilding = 0; " exécuter que la requête plus spécifique. La principale raison pour laquelle je peux penser à cela serait si vous aviez plus d'un état dans votre colonne. Si c'est simplement un booléen, alors ça ira, mais vous voudrez peut-être prendre le temps de penser si ce sera toujours le cas.

L'indexation pourrait également améliorer l'efficacité du plan d'exécution à l'aide de la clause WHERE.

Answer 6

Le meilleur moyen d'obtenir une réponse définitive serait de profiler en utilisant un grand nombre d'échantillons de données dans des scénarios différents.

Answer 7

L'indexation ne vous aidera pas du tout, sauf si vous avez quelque chose comme 2% des valeurs usedBuilding = 1.

Cependant, ces 2 déclarations sont logiquement différentes et peuvent signifier des choses totalement différentes. mais si, dans votre cas, ils sont identiques, utilisez celui sans la clause where.

Answer 8

Combien de lignes aurez-vous exactement? Je pense que pour un jeu en ligne assez petit, vous ne vous en souciez vraiment pas.

Si vous effectuez plusieurs mises à jour du " villes " table, il peut être judicieux de les faire tous dans une instruction UPDATE si possible.

Toute modification apportée à une ligne nécessite probablement autant d’entrées / sorties que l’écriture de la ligne entière (sauf que la mise à jour des colonnes indexées nécessite également des écritures d’index), vous perdez donc en créant plusieurs UPDATE qui touchent de nombreuses lignes. / p>

Mais si vous avez, disons, < 1 000 lignes, cela ne vous dérange vraiment pas:)