Instruction SQL Delete simple donnant le timeout d'attente

Combien de foreign keys avez-vous en reference à la colonne Id des Users , et y a-t-il des index sur ces colonnes?

Si cascade est défini comme NO_ACTION , comme vous l'avez indiqué, SQL Server peut passer du time à effectuer une parsing de table complète sur chacune de ces tables pour s'assurer qu'il n'y a pas de reference à l' Id 95146 – J'ai vu cela facilement Prenez quelques minutes à la fois avant, si les autres tables sont grandes.

c'est très étrange. Je suppose que vous avez une key étrangère ON DELETE CASCADE référençant votre table Users ailleurs dans votre schéma. Vérifiez vos contraintes:

 SELECT f.name AS ForeignKey, OBJECT_NAME(f.parent_object_id) AS TableName, COL_NAME(fc.parent_object_id,fc.parent_column_id) AS ColumnName, OBJECT_NAME (f.referenced_object_id) AS ReferenceTableName, COL_NAME(fc.referenced_object_id, fc.referenced_column_id) AS ReferenceColumnName, f.delete_referential_action_desc FROM sys.foreign_keys AS f INNER JOIN sys.foreign_key_columns AS fc ON f.OBJECT_ID = fc.constraint_object_id 

Pendant que votre déclaration est en cours d'exécution, jetez un coup d'œil à la list des tâches en cours et des verrous retirés par le système. Vous pouvez get ces informations à partir du moniteur d'activité, ou vous pouvez regarder les tâches en cours d'exécution dans la vue sys.dm_os_waiting_tasks et verrouiller avec exec sp_lock et sys.dm_tran_locks .

En outre, dans SQL Server Management Studio, entrez cette instruction et examinez le plan d'exécution estimé. Peut-être que vous serez en mesure de voir ce que SQL Server essaie de faire.

Jetez un oeil aux foreign keys à cette table. Vous devrez peut-être append des index sur d'autres tables pour optimiser les assertions de key étrangère.

Je me débattais avec une déclaration DELETE qui provoquait l'expiration de notre système ERP (Epicor 10) lors de sa course nocturne de MRP. C'était une suppression avec quelques jointures dedans, et une des tables impliquées dans la jointure est assez grande. La chose étrange était que si je transformais la suppression en SELECT * pour la même clause join / where, alors la requête se terminerait instantanément, et aurait des résultats ZÉRO (ie l'instruction delete effectuait évidemment une longue et longue parsing de table mais ne trouve rien à supprimer).

Ce qui m'a finalement aidé, c'est que j'ai exécuté la version de l'instruction select avec le plan d'exécution réel Show activé, et que l'index non-unique proposé était ajouté à l'une des tables. Après avoir ajouté cet index, l'instruction select était toujours exécutée instantanément, mais maintenant, l'instruction delete l'était aussi!

En plus des autres réponses, peut-être que votre DELETE est bloqué par une autre activité (voir s'il y a une valeur dans la colonne BlkBy de sp_who2 pour votre spid), ou peut-être un triggersur sur la table qui fait quelque chose de malsain. La plupart des choses mentionnées vont ralentir la suppression, mais sauf dans des situations extrêmement complexes, pas assez pour provoquer un timeout.