Comments on: How to understand key length limitations in MySQL

By: James Day

James Day — Wed, 28 Mar 2012 16:10:40 +0000

Anyone who does need a larger key length should look at innodb_large_prefix http://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_large_prefix . It’ll probably do what you are after if you’re using InnoDB.

James Day, MySQL Senior Principal Support Engineer, Oracle

By: mark

mark — Thu, 10 Feb 2011 16:31:29 +0000

I understand perfectly well how keys are used in database systems, and if I choose to design my system with a long key for a good reason, that is my tradeoff to make.

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.

By: Erik

Erik — Tue, 30 Mar 2010 11:10:54 +0000

what could be minimum length could be used for the sake of optimization too? field(2) or field(10), which would be fast and optimized for search?

By: J0NES

J0NES — Mon, 15 Mar 2010 09:40:22 +0000

annotation to my previous post: the citation markup I did not work – citation ends with “how keys are used in
database management systems.” – the following rant is by me.

By: J0NES

J0NES — Mon, 15 Mar 2010 09:38:24 +0000

Dear Author, Dear Readers,

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.