Modern B-Tree Techniques (2011)
> Probably  the  strongest  arguments  for  B-trees  over  hash  indexes pertain to multi-field indexes and to nonuniform distributions of key values. A hash index on multiple fields requires search keys for all those fields such that a hash value can be calculated. A B-tree index, on the other hand, can efficiently support exact-match queries for a prefix of the index key, i.e., any number of leading index fields<p>Yes, well, if none of the columns/fields in the index are sufficiently selective, then the ability to search a B-tree by prefix may not do you much good.  Don't get me wrong though: I fully agree with all of the given reasons for B-tree superiority to hash tables.<p>Although the newest storage technologies (particularly very fast byte-addressable NVMs) -- too new for TFA -- might well change things.  When you have fast byte-addressable storage it will pay to not read pages, and hash tables may yet involve fewer accesses than B-trees in that case, though I suspect B-trees will successfully adapt anyways.