SQL: Interruption d'une requête

Question

J'ai travaillé sur un projet utilisant une base de données non-SQL propriétaire où les requêtes pouvaient être interrompues et dans la base de code il y avait quelques endroits où cette fonctionnalité était utilisée et parfaitement logique (par exemple une requête longue qui est annulée par l'utilisateur, ou quand une requête plus récente a lieu et rend obsolète la requête précédente, etc.) et je me suis rendu compte que je n'ai jamais vraiment vu ce genre de "requêtes interrompues" bonne question SO (plusieurs questions, mais ils sont tous liés à exactement la même chose):

• Les requêtes SQL peuvent-elles être interrompues?

• est cette partie de la norme SQL?

• si cela ne fait pas partie de la norme SQL, quelles bases de données SQL autorisent l'interruption des requêtes (quel que soit l'exemple le plus approprié)?

• est-il courant d'interrompre une requête DB (SQL ou non) dont vous savez que vous ne vous soucierez plus du résultat? (Dans le code de base que j'ai travaillé, cela aide à alléger la charge du serveur)

Answer 1

Imho « interrompu » devrait être remplacé par « tué » ou « terminé ». Le concept d'interruption peut être déroutant car on pourrait supposer qu'il permettrait à la requête d'être reprise plus tard.

La norme SQL ne fournit pas un moyen d'interrompre ou de terminer une requête en cours d'exécution, mais chaque SGBD que je connais met en œuvre une commande KILL ou similaire. Par exemple, dans MySQL, un utilisateur peut utiliser la LISTE DE PROCESSUS SHOW [FULL] pour voir toutes les requêtes en cours (et leurs états, les ID de requêtes, etc.). Les utilisateurs avec le privilège KILL peuvent ensuite terminer une requête.

La plupart des KILL se produisent parce qu'une requête risque de s'exécuter trop longtemps ou bloque d'autres requêtes, par exemple. la table manque un index ou le disque est plein. Lorsque le résultat ne vous intéresse pas (par exemple, la navigation du site annulée par l'utilisateur), le serveur Web interrompt souvent le processus et donc la requête en lui-même (aucune interaction manuelle ou programmeur n'est nécessaire)

Answer 2

Toutes les couches d'accès SGBDR I ' Nous avons déjà travaillé avec une méthode d'annulation pour annuler de manière asynchrone les requêtes en cours. Consultez la documentation de la pile de technologie d'accès aux données que vous utilisez. .NET/ADO/JDBC fournissent une méthode 'cancel'. ODBC - SQLCancel. Il est évident que le pilote d'accès aux données des fournisseurs SGBDR sous-jacent doit également implémenter la méthode.

En termes d'utilité de l'annulation, j'aurais tendance à critiquer tout schéma qui en ferait un usage régulier. À mon avis, une meilleure coordination et/ou conception aurait tendance à atténuer les besoins non administratifs.

Il existe une dépendance significative sur les composants internes du SGBDR, la nature de la transaction et le schéma d'isolation. Si le SGBDR utilise un modèle de concurrence optimiste (c.-à-d. Que la validation est essentiellement gratuite), l'annulation d'une requête en cours peut entraîner une opération de restauration potentiellement coûteuse. Dans le pire des cas, une requête qui s'exécute pendant une heure jusqu'au moment de l'annulation peut très bien prendre une autre heure pour revenir en arrière.