3 ms·

I am pretty sure it was not because of any optimization but that the real reason was to make sure a VARCHAR(255) would still fit within the maximum field size o

by jeltz 8y ago

I am pretty sure it was not because of any optimization but that the real reason was to make sure a VARCHAR(255) would still fit within the maximum field size of InnoDB (768 bytes) at the time. Since then MySQL has added ROW_FORMAT=DYNAMIC to InnoDB which allows for larger values, but that probably required major changes to InnoDB.

morgo 8y ago
There are various buffers that were* not variable length in query execution (sorting, temp tables). It is not just about the on-disk format in this case. * Use MySQL 8.0 :-)
MrBuddyCasino 8y ago
There is usually a good reason for doing these kind of things. But then don't call it UTF8 encoding! It doesn't do that. It stores the most popular characters out of a larger address space. Call it UTF8-MB3 maybe from the start and let the user decide if having varchar(255) is worth the tradeoff. Thats the trouble with MySQL: doing silently the wrong thing, and thus violating the principle of least surprise. There is software where this might be ok, but a database is not that kind of software.
- tinus_hn 8y ago
  In the case of MySQL (especially MySQL in 2003) bad design and silly behavior isn’t much of a surprise though :)