Perhaps using long keys will slow down mysql relative to an unindexed table; if so, they should look at how sqlite does it — it works quite well, even in a 150 GB (hundred fifty gigabyte) database.

the best link to understand to what happened here is
http://bugs.mysql.com/bug.php?id=4541

you have to scroll down to the bottom to the last post by Jason Urrich:

————————————
TO ANYONE WHO RUNS INTO THIS PROBLEM
————————————

Before trying to work around this problem, consider what this error is telling you: you
are trying to set up a key (i.e., a tree searching index) that needs more than a certain
number of bytes. If you are getting this error for something that you’ve marked as a
primary key and your keylength is over 20 bytes (latin1) or 60 bytes (utf8), then stop
right and go back to your design – this is not a suitable primary key.

If you are running into this problem for a non-primary key or an indexed column, the
problem comes down to the same thing: you’re trying to use an enormously long string to
do tree index lookup, which means you’ve probably not understood how keys are used in
database management systems.

Of course most of the Webapps, especially php based, will break, if they really need utf8 – so the result of this stupid design decision is that in 2010 you still can not have full utf-8 support with mysql – instead you are faced with arrogant “you do not know how to use indexes” statements of the devs and they want you to look like the idiot – totally ridicolous.

My serious advise for 2010, considering not only the never ending line of stupid mysql bugs, but also the general situation for this piece of software: move your apps either to postgres or, if web only, to one of the upcoming nosql databases like e.g. couchdb – it is time for mysql to die, and you will be lost on a sinking ship.

create table test(c varchar(250), d varchar(250), primary key(`c`(100),`d`(100));

You can choose only the first few to index.