Debunking MySQL VARCHAR Myths: Why 255 Isn’t the Magic Number

Why is VARCHAR(255) so common?

In MySQL 4.0 and earlier the maximum length of a VARCHAR column was 255 bytes because the engine stored the length in a single byte (max 2⁸‑1 = 255). MySQL 4.1 (2004) introduced multi‑byte character sets such as UTF‑8 and expanded the theoretical limit to 65,535 bytes, though the actual usable length still depends on row format, character set, and other columns.

The habit of defining VARCHAR(255) originates from those early versions and persists even though most deployments now run on newer MySQL releases.

What is the true maximum length of VARCHAR?

From MySQL 4.1 onward the maximum length is 65,535 bytes, limited by the maximum row size. The actual number of characters you can store depends on the encoding:

GBK: up to 32,766 characters (2 bytes per character).

UTF‑8: up to 21,845 characters (up to 3 bytes per character).

UTF8MB4: up to 16,383 characters (up to 4 bytes per character).

Additionally, MySQL reserves 1–2 bytes per VARCHAR column to store the length, so the usable character count is slightly lower.

ERROR 1118 (42000): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. You have to change some columns to TEXT or BLOBs.

Does VARCHAR(50) perform better than VARCHAR(255)?

In InnoDB the storage is based on the actual string length, not the declared maximum, so VARCHAR(50) and VARCHAR(255) have essentially the same performance for strings shorter than 255 bytes.

Length information uses 1 byte when the declared maximum ≤ 255; it switches to 2 bytes only when the declared maximum exceeds 255, which can trigger a table rebuild.

When temporary MEMORY tables are used, the engine allocates fixed space equal to the declared maximum, so VARCHAR(255) consumes more memory than VARCHAR(50) even for short values.

Index length limits can be hit more easily with VARCHAR(255), affecting index storage efficiency.

Therefore, while storage performance is similar, using the shortest sufficient length saves memory and index space.

How many Chinese characters can VARCHAR(50) hold?

In MySQL the number inside VARCHAR(n) always represents the maximum number of characters, regardless of the encoding. Thus VARCHAR(50) can store up to 50 Chinese characters.

Each Chinese character occupies different bytes depending on the charset (UTF‑8 ≈ 3 bytes, UTF8MB4 ≈ 4 bytes, GBK ≈ 2 bytes), but this does not affect the character count.

To count characters reliably, use CHARACTER_LENGTH() instead of LENGTH(): CHARACTER_LENGTH('师兄奇谈') returns 4 (four characters). LENGTH('师兄奇谈') returns 12 (four characters × 3 bytes in UTF‑8).

Does aligning VARCHAR sizes to 2ⁿ improve performance?

Modern MySQL storage does not align field lengths to powers of two. The engine allocates space based on the actual data length plus 1–2 bytes of metadata, not on the declared maximum. Consequently, choosing sizes like VARCHAR(8), VARCHAR(16), or VARCHAR(32) offers no measurable performance or storage advantage.

Block sizes of disks and memory pages (e.g., the default 16 KB InnoDB page) are far larger than typical VARCHAR definitions, so the impact of a field’s declared length on I/O or memory efficiency is negligible.

Best practice: size columns according to the real data requirements (e.g., VARCHAR(11) for a phone number) rather than arbitrary 2ⁿ values.

Key Takeaways

VARCHAR(255) is a legacy default; MySQL 4.1+ allows up to 65 535 bytes, limited by row size and character‑set byte usage.

InnoDB stores only the actual string length plus 1–2 bytes, so short VARCHAR definitions have similar performance.

Define column lengths based on expected data, not on historical conventions or 2ⁿ alignment.

Use CHARACTER_LENGTH() to count characters, especially for multibyte languages.

Avoid over‑allocating VARCHAR length to reduce index size, memory‑table overhead, and potential table rebuilds when the length crosses the 255‑byte threshold.