I rant against 255 occasionally. Sure, there used to be some reasons for '255', but many are no longer valid, and even counter-productive.
In MySQL, there are reasons to stop at 191, 255, 767, 64K, and probably other values. Some depend on Engine, some on
CHARACTER SET, etc.
VARCHAR is stored as a 1- or 2-byte length plus enough bytes for the current text in whatever charset you have specified. However, the choice of 1 or 2 is not driven only by the individual column; it is driven by the total row size. That is, this is not a valid excuse for using 255.
Use a length that is
- Big enough to conservatively never be exceeded, yet
- As small as seems reasonable.
While I am ranting...
CHAR (fixed length) is rarely advised. And almost always it should be
CHARACTER SET ascii -- country_code, postal_code, Y/N, M/F, MD5, UUID, base64, etc. (MD5 and UUID should be taken a step further, but that is another rant.)
Potential negative impacts of blindly using '255':
- If you have a lot of columns, you could hit a max row size limit and
CREATE TABLE will fail.
- You could overflow a limit on index size.
SELECTs may need a temp table, and may use
MEMORY for it. In this case,
CHAR(255) for the temp table. And, if using utf8, that is 755 bytes for every row! (8.0 fixes this design flaw?)
Related: Don't blindly use
BIGINT for all numbers. It takes 8 bytes. Even
INT is overkill, at 4 bytes. See
TINYINT. Be aware that the
INT(2) means nothing; it still takes 4 bytes.