Les transactions ajoutent-elles des frais généraux à la DB?

Vous avez raison, avec autocommande, chaque relevé est enveloppé dans la transaction. Si vos méthodes de service exécutent plusieurs relevés SQL, il serait bon de les envelopper dans une transaction. Jetez un coup d'œil à Ceci < / a> réponse pour plus de détails et ici est un bel article de blog sur le sujet.

et pour répondre à votre question, oui, les transactions ajoutent les frais de vue de la performance, mais dans votre cas spécifique, vous ne remarquerez pas la différence car vous avez déjà activé une autocommande, à moins que vous n'ayez des relevés de fonctionnement à long terme des méthodes de service, ce qui entraînera plus longtemps. Verrouille sur des tables participant aux transactions. Si vous venez d'envelopper vos multiples déclarations dans une transaction, vous obtiendrez une transaction (au lieu de la transaction pour chaque relevé individuel), comme indiqué sur ICI (" Une session Autocommit activé peut effectuer une transaction à plusieurs inscriptions en le démarrant avec une transaction de démarrage explicite ou en commençant par une instruction et la fin avec une déclaration de validation ou de restauration ») et vous obtiendrez de l'atomicité sur un niveau de méthode de service ...

À la fin, j'irais avec votre solution, si cela est logique de la perspective d'atomicité sur un niveau de méthode de service (que je pense que vous souhaitez atteindre), mais il y a + et - des effets sur la performance, En fonction de vos requêtes, des demandes / s etc.

Oui, ils peuvent ajouter des frais généraux. La "comptabilité" supplémentaire nécessaire pour isoler les transactions les unes des autres peut devenir significative, en particulier si les transactions sont ouvertes pendant une longue période.

La réponse courte est que cela dépend de votre type de table. Si vous utilisez Myisam, la valeur par défaut, il n'y a pas de transactions vraiment, il n'ya donc donc aucun effet sur les performances.

Mais vous devez les utiliser de toute façon . Sans transactions, il n'y a pas de démarcation de travail. Si vous effectuez une mise à niveau vers InnoDB ou une base de données réelle comme PostgreSQL, vous souhaitez ajouter ces transactions à vos méthodes de service, afin que vous puissiez aussi bien en faire une habitude maintenant, alors qu'elle ne vous coûte rien.

En outre, vous devez déjà utiliser un magasin transactionnel. Comment nettoyez-vous si une méthode de service échoue actuellement? Si vous écrivez des informations sur la base de données, puis votre méthode de service jette une exception, comment nettoyez-vous cette information incomplète ou erronée? Si vous utilisiez des transactions, vous n'auriez pas au-dessus de la base de données jetterait des données roulées pour vous. Ou que faites-vous si je suis à mi-chemin d'une méthode et une autre demande s'inscrit et trouve mes données semestriées? Est-ce que ça va faire exploser quand il va chercher l'autre moitié qui n'est pas encore là? Un magasin de données transactionnelles vous gérerait pour vous: vos transactions seraient isolées les unes des autres, afin que personne d'autre ne puisse voir une transaction partiellement écrite.

Tout comme tout avec des bases de données, la seule réponse définitive proviendra des tests avec des données réalistes et des charges réalistes. Je vous recommande de le faire toujours, peu importe ce que vous soupçonnez, car lorsqu'il s'agit de bases de données, des chemins de code très différents sont activés lorsque les données sont grandes par rapport à la situation. Mais je soupçonne fortement que le coût de l'utilisation des transactions, même avec Innodb, n'est pas génial. Après tout, ces systèmes sont fortement utilisés constamment, tous les jours, par des organisations grandes et petites qui dépendent des transactions performantes. MVCC ajoute très peu de frais généraux. Les avantages sont vastes, les coûts sont bas utilisés!