We can't just magically make a query faster without knowing anything about it or the context it's used in. Post #5 is much better but there are still more details you could provide, as IanRyder has indicated. Quite possibly there's no way to make your queries faster, but there are ways to make your application perform better. I'll make a few suggestions straight off the bat though.
1. The KeyDown event is very wrong. TextChanged would be the place to start, but even then you shouldn't actually execute the query from there. What if the user quickly types three letters in? There will be three events but you don't want to perform three queries. You only need the results of the last one and it's going to be the smallest result set too. On each TextChanged event you should restart a Timer. Only when that Timer Ticks should perform a query. You would settle on a reasonable delay, e.g. 250 milliseconds, so that you only perform a query if the user stops typing for that long.
2. After you've performed a query, if the user keeps typing then you know for a fact that the next query result set will be a subset of the first. As such, you can simply filter the data you already have instead querying the database again. If the current value starts with the previous value then you know that you can simply filter the data you already have. Only if the user deletes or modifies part of the value used for the first query do you actually need to go back to the database.
For instance, if the user types "ab" then you'll search for all values that start with "ab". If the user then adds "c" you can then just filter the data you have for all values that start with "abc" without going back to the database. If the user then replaces the "c" with a "d" you can still just filter the data you already have because all values that start with "abd" also start with "ab" and you already have all of those. If the user changes the text to "az", then you will need to requery the database. Even then though, you may not discard the data you already had. You might keep it in case it could be used later, saving you another query.
3. As an alternative to 2, you might query every time but limit the number of results to, say, 20. That means that you'll never have thousands of records to pull back. It may mean that the user will have to type more characters to get a match but finding a match manually in a long list is unlikely to happen anyway so they'd probably type more characters to narrow down the options anyway.