La stratégie la plus simple de toutes: il suffit de « descendre » dans la table (modulo la taille de celle-ci) jusqu'à ce que nous trouvions la clef recherchée, ou, si nous sommes en train d'insérer une nouvelle clef, une case vide.
Soit a0=H1(k), la première adresse à être examinée. Si la clef que nous cherchons se trouve à l'adresse a0, la fouille se termine avec succès. Si cette adresse ne contient pas la clef recherchée, nous allons procéder à l'examen d'autres adresses.
Avec la fouille linéaire simple on examine, au t ième essai, l'adresse
On boucle jusqu'à ce que l'on trouve la clef, auquel cas le sondage termine avec succès, ou jusqu'à ce que nous atteignions une case vide, ou encore que nous ayons t = m, alors le sondage termine avec échec.
L'avantage de cette méthode, c'est qu'elle est très simple, mais cela ne contrebalance pas ses désavantages majeurs. Premièrement, lorsque la table est presque pleinne, trouver une case vide ou une clef peut dégénérer en recherche linéaire, ce qui est très lent. Deuxièmement, elle crée du secondary clustering: elle remplira de larges plages de la table parce que la fonction ne sondage ne cherche pas une case aléatoirement choisie, mais la prochaine en ordre croissant qui est libre. Alors, même si la fonction de hash primaire est relativement bonne, la fonction de sondage linéaire va « boucher » les trous dans la table et, créant des clusters de plus en plus gros, jusqu'à ce que la recherche dégénère en temps linéaire. La figure suivante illustre le problème.
Fig. 1. La fonction de hash primaire (la flèche en haut) calcule une adresse et génère une collision. La première case libre en ordre croissant, ici en rouge, est trouvée et utilisée, consolidant ainsi deux clusters, provoquant une congestion supplémentaire.