La méthode de résolution de collision par liste chaînée est en fait fort simple. Il s'agit, à chaque case, d'avoir une liste chaînée plutôt qu'une seule entrée. Une clef qui fait une collision est tout simplement ajoutée à la liste si elle n'en fait pas déjà partie.

L'avantage de cette méthode c'est évidemment qu'elle est très simple. Il est en effet trivial d'implémenter une liste, voire d'en utiliser une déjà conçue (comme celle de la STL, par exemple.)

Le principal désavantage c'est que la recherche dégénère en temps linéaire en la longueur de la liste. Plus la liste est longue, plus c'est coûteux faire la recherche dans la liste chaînée.

La meilleure façon de se prémunir contre un comportement dégénéré est d'avoir une table avec un très faible taux de collisions, soit une table très grande par rapport au nombre de clefs qu'on y insérera. Typiquement, la taille de la table sera 2 ou 3 fois le nombre de clefs. C'est en effet suffisant si nous avons une très bonne fonction de hash.

On peut toujours utiliser quelque astuce pour accélérer les recherches, comme déplacer le dernier élément accédé dans la liste à la tête de celle-ci pour le trouver plus rapidement à la prochaine fouille. Les schèmes « move to front » performent bien pour certains types de distributions de type géométrique, comme la distribution de Zipf, mais ne donneront rien si la distribution des accès est uniforme. Notez que la distribution des clefs ici ne dépend pas de la fonction de hash, mais des requêtes faites par l'usager.

On peut aussi remplacer la liste chaînée par une structure de données plus rapide, et qui dépend moins de la distribution des clefs, comme un arbre de recherche binaire. On pourra, si on veut, même utiliser une variante comme AVL qui garantit les temps d'accès.