And you just type "S", the "SD" results may hide the SO one, the chance of pickign the wrong one is rather high. However, that sems very constructed, and I'm not sure if incremental search is a good solution at all if this would be a problem.

Great answer, I just want to add that performance issues can be solved by delaying search for about 0.5 sec after keypress, so if user is typing smth, intermediate request will not be sent to server until he stops typing.
–
Nikita ProkopovMar 8 '11 at 13:12

1

@Nikita - thanks, I actually edited that out before the initial submit. I've added it again :)
–
peterchenMar 8 '11 at 16:32

1

Really good, thank you. How about getting the results. Should the search look inside words or just the beginning of the word. fx. if search phrase is "sic" should it result fx. "basic" or just words beginning with "sic"?
–
kuakeliMar 9 '11 at 7:07

My recent conclusions: How well they match could be (or go into) the secondary rank - e.g. just list the "starts with sic" results first, then those just containing sic.
–
peterchenMar 9 '11 at 8:09

An autocomplete functionality is most optimally backed by a structure called a Trie.

Using a trie, you would'nt even have to set a lower limit on characters.
Lookup is performed in O(n) where n is length of the query text and is independent (mostly) of the number of search items that are in your database.

Please take a look at a node.js based trie implementation that I did - MyTriePOC.

From a user experience perspective, if you are really setting a lower limit, best practice is to provide a tooltip to instruct the user to keep typing more characters for best results.