Il existe des scénarios où SET NOCOUNT ON est obligatoire. Lors de la conception d'un niveau intermédiaire hautes performances basé sur un traitement asynchrone exploitant le pool de threads via les méthodes BeginExecuteXXX de SqlClient, il existe un problème très sérieux avec le nombre de lignes. Les méthodes BeginExecute se terminent dès que le premier Le paquet de réponse est renvoyé par le serveur. Mais lorsqu'un EndExecuteXXX est appelé, cela se termine sur les demandes sans requête lorsque l'appel est terminé. Chaque réponse rowcount est une réponse. Lors du traitement de procédures même modérément complexes, le décompte de la première ligne peut revenir en 5 à 10 ms, tandis que l'appel se termine en 300 à 500 ms. Au lieu de rappeler la demande asynchrone soumise après 500 ms, elle rappelle après 5 ms, puis le rappel se bloque dans EndExecuteXXX pendant 495 ms. Le résultat est que les appels asynchrones se terminent prématurément et bloquent un thread du pool de threads dans les appels EndExecuteNonQuery. Cela conduit à la famine de ThreadPool. J'ai vu des systèmes hautes performances améliorer le débit de centaines d'appels par seconde à des milliers d'appels par seconde simplement en ajoutant le SET NOCOUNT ON, sur des scénarios spécifiques.
Étant donné que pour les appels asynchrones de niveau intermédiaire à grande échelle/haut débit, le traitement des appels asynchrones est la seule solution, le NOCOUNT est à peu près une exigence obligatoire.
