Should MySQL VARCHAR Lengths Be Powers of Two?

No. MySQL does not make a VARCHAR faster because its declared length is a power of two, nor because it is one less than a power of two. Values such as 31, 63, 127, and 255 may look natural to a programmer, but they have no general allocation or alignment advantage in an InnoDB schema.

The useful question is not whether M resembles 2n or 2n - 1. It is what M means for the selected data type and character set, and whether that limit matches the data.

What M Actually Means

For CHAR and VARCHAR, M is a maximum number of characters. For BINARY and VARBINARY, M is a number of bytes. Those units are identical only for a single-byte character set.

CHAR(M) is fixed-length: values are padded to the declared character width when stored, although the physical representation can depend on the character set and InnoDB row format. BINARY(M) always stores exactly M bytes in its data portion and pads shorter values with zero bytes. Making either declaration wider can therefore consume more space.

VARCHAR and VARBINARY are variable-length. A VARCHAR row does not reserve a buffer of M bytes for every value. Let L be the actual value length in bytes. The stored variable-length payload uses:

• L + 1 bytes when the column's maximum possible byte length is at most 255 bytes;
• L + 2 bytes when the column can require more than 255 bytes.

These expressions describe the value plus its length prefix, not every byte of an InnoDB record. Record headers, nullability, transaction metadata, page layout, and possible off-page storage add separate concerns.

The Real Boundary Is 255 Bytes

The length-prefix transition is real, but it is a byte boundary rather than a power-of-two optimization. It is selected from the column's maximum possible byte length, not independently from each stored value.

A VARCHAR(255) CHARACTER SET utf8mb4 column can require up to 1,020 data bytes, so it already uses a two-byte prefix. Increasing it to 256 characters does not cross another prefix boundary. Conversely, 63 happens to be a useful threshold for utf8mb4, but only because 63 * 4 = 252 stays below 256 bytes. It is not evidence that MySQL favors 2n - 1 declarations.

Why Allocator Alignment Does Not Decide the Schema

The allocator alignment intuition comes from low-level memory management, where an allocator may round requested blocks into size classes. An InnoDB record is not represented as one separately allocated C buffer for each VARCHAR value. InnoDB packs records into database pages using its own record and page formats. There is no extra CPU step that becomes cheaper merely because M is a power of two.

Execution can still use temporary buffers, and declared maximum widths can influence row-size calculations or memory estimates in some operations. That is an argument against casually oversized declarations, not an argument for powers of two. Other storage engines also have their own layouts; NDB, for example, applies four-byte alignment internally. Its rounding rules still do not make a domain limit of 127 more correct than 120.

Choose the Length from the Data

Choose M from the domain represented by the column:

• Use an exact limit when the domain defines one, such as CHAR(2) for a fixed two-character code.
• Use VARCHAR when values vary in character length and the application has a meaningful upper bound.
• Use VARBINARY when the limit is measured in raw bytes rather than characters.
• Account for the column character set before reasoning about storage, row size, or index key limits.

Do not switch to TEXT merely because a desired limit reaches 256 characters. Modern MySQL permits much larger VARCHAR declarations, subject to the 65,535-byte row limit, the character set, and storage-engine constraints. Choose TEXT when the value is genuinely text-like or when its different row-storage behavior is useful, while accounting for differences in indexing and other schema operations.

Oversizing is not automatically harmless. Maximum widths contribute to MySQL's row-size validation, can determine whether an index fits within InnoDB index key limits, and communicate weaker constraints to every writer. Conversely, an artificially small power-of-two limit can reject valid domain values. Schema semantics come first; measured storage and query behavior come next.

Inspect Bytes Instead of Guessing

INFORMATION_SCHEMA.COLUMNS exposes both the character limit and its maximum byte length. This makes character-set effects visible:

SELECT
    COLUMN_NAME,
    DATA_TYPE,
    CHARACTER_MAXIMUM_LENGTH,
    CHARACTER_OCTET_LENGTH
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = 'app'
  AND TABLE_NAME = 'customer';

CHARACTER_MAXIMUM_LENGTH reports characters, while CHARACTER_OCTET_LENGTH reports the maximum bytes allowed by the declaration and character set. Use SHOW CREATE TABLE customer as the canonical check for the effective column types, character sets, collations, row format, and indexes.

If changing a production column, inspect actual lengths before selecting the new limit:

SELECT
    MAX(CHAR_LENGTH(display_name)) AS max_characters,
    MAX(OCTET_LENGTH(display_name)) AS max_bytes
FROM customer;

This describes current data, not necessarily the complete business domain. Leave justified headroom for valid future values, then verify the altered table definition and relevant query plans. A benchmark is useful for comparing real schemas and workloads; comparing arbitrary values such as 127 and 128 without a domain or workload does not reveal a MySQL optimization rule.

Conclusion

There is no universal preference for 2n or 2n - 1. The one-versus-two-byte prefix boundary can make adjacent declarations differ by one byte per value, but the boundary depends on maximum bytes and therefore on the data type and character set. Pick the smallest honest domain limit, not the nearest binary-looking number.

References

• [MySQL-Char]MySQL 8.4 Reference Manual: The CHAR and VARCHAR Types.
• [MySQL-Storage]MySQL 8.4 Reference Manual: Data Type Storage Requirements.
• [MySQL-Rows]MySQL 8.4 Reference Manual: Limits on Table Column Count and Row Size.