Optimizing MySQL - strings vs integers

I've been logging my slow MySQL queries, with "slow" being defined rather harshly as anything that takes more than 0.01 seconds. However, when you are only dealing with 1000-30,000 records and simple selects, they shouldn't take much longer than that.

One thing I've noticed is a MAJOR difference between how MySQL treats integers versus strings in the WHERE clause.

For instance, if I do
SELECT *
FROM zipcodes
WHERE Zip=19104

This works fast if Zip is stored as an integer. If you want to store Zip as a string (to support codes like 00213, or because you are using a 7 character field to also support Canada which uses a mix of letters and numbers), then you can run into problems.

If you have it stored as CHAR or VARCHAR, then if you do WHERE Zip=19104 it works, however MySQL is converting it from an integer to a string. This action is probably relatively fast (though it might happen once for every single row MySQL looks at). Your big efficiency loss comes from MySQL not being able to use its cache!

(I'm not sure what cache this is - perhaps the key cache???)

If you store it as CHAR/VARCHAR and do WHERE Zip='19104' a sample query took 0.14 seconds the first time, but only 0.001 seconds the next time. If I did it using WHERE Zip=19104 it took about 0.14 seconds both times.

Adding a simple set of single quotation marks causes my queries to run 100 times faster!

OK, so I probably should be storing zip codes as numbers. But I want to have international support and I'm not sure if I want to keep track of which countries have numeric zip codes (and thus could be optimized for speed) and those that have alpha-numeric. I like optimization but I bet that's huge overkill =)