La suppression des données n'est pas toujours nécessaire ni désirée dans une base de données. Il arrive parfois même, dans les bases d'archive, qu'elle soit interdite, sauf pour des raisons purement techniques. Il n'empêche que, dans de nombreux cas, effacer des données devenues inutiles devient une nécessité, ne fut-ce que pour des raisons de performances. L'effacement d'une donnée peut devenir très problématique, même dans les structures de bases (raisonnablement) simples. Le principal problème que cela peut poser est celui de l'intégrité référentielle, c'est-à-dire des références croisées entre clés primaires. D'une façon générale, on s'interdit d'effacer une donnée référencée par un autre. Si cette donnée est obsolète, mais que la première ne l'est pas, il n'y a pas d'autre choix que de conserver la première. C'est un peu ainsi que des bases se transforment en tas de données, perdent petit à petit leur structure, que des doublons apparaissent, et que les choses deviennent de plus en plus inutilisables. La forme générale d'un delete est la suivante.
La clause where est facultative. S'il n'y en a pas, alors tout le contenu de la table passée en paramètre est effacé. Une précaution élémentaire avant d'exécuter un delete est d'effectuer un select avec la même clause where. Cela permet de vérifier que les données qui vont être effacées sont bien les bonnes, et de prévenir d'éventuels désastres. Notons que l'on peut effectuer des sous-requête dans la clause where d'une delete.

Comme il a été dit, la présence d'une clé étrangère peut empêcher l'effacement d'un enregistrement. Il y a un moyen de remédier à cela, lors de la déclaration de cette clé étrangère. Si cette clé a été créée avec l'option on cascade delete, alors l'effacement est possible, et toutes les données qui référencent la donnée que l'on efface seront effacées aussi. Ce mécanisme est très pratique à condition qu'il soit parfaitement maîtrisé. Dans le cas contraire, un effacement a priori anodin peut entrainer l'effacement de quantités d'autres données, sans qu'il soit réellement possible de prévoir lesquelles de façon simple. L'option on cascade delete est à manipuler avec les plus grandes précautions.

Le fonctionnement du delete suit une ordre très précis, très important dans certains cas. Le serveur procède en deux temps. Tout d'abord, il commence par balayer la table à la recherche des lignes qui vérifient la condition indiquée. Il marque chacune de ces lignes, qui seront être effacées par la suite. Dans un second temps, il efface les lignes marquées. Cet effacement peut d’ailleurs être un processus commun à toutes les tables, qui vide les données marquées à intervalles de temps réguliers. Voyons sur un exemple pourquoi cette façon de faire est importante. Supposons que l'on veuille effacer les marins de notre table, dont l'âge est inférieur à l'âge moyen des marins.
Dans ce cas, la requête imbriquée est tout d’abord évaluée, et le résultat comparé à la soustraction. Ces deux opérations sont faites à chaque ligne. Si l’effacement était immédiat, le résultat du calcul de la moyenne changerait à chaque ligne, le résultat final de l’opération changerait suivant l’ordre dans lequel les lignes seraient traitées. Comme le calcul se fait en deux passes, le processus fonctionne comme attendu. Dans un premier temps, les lignes à effacer sont marquées, mais sont toujours prises en compte dans le calcul de la moyenne. Une fois toutes les lignes examinées, les effacements sont effectués.