The actual range and storage size of an INT
INT(2) and INT(11) use the same storage. Display width is not precision — pick TINYINT…BIGINT (and DATE) deliberately.
INT(2) vs INT(20) is not a storage or range difference. The (n) on integer types is display width (mostly relevant to ZEROFILL / interactive clients). Application APIs ignore it.
Range comes from the type
| Type | Storage | Signed range (approx.) |
|---|---|---|
TINYINT |
1 byte | −128…127 |
SMALLINT |
2 bytes | −32768…32767 |
MEDIUMINT |
3 bytes | ±16M |
INT / INTEGER |
4 bytes | ±2.1B |
BIGINT |
8 bytes | huge |
CHAR(n) / VARCHAR(n) length semantics do not apply to integers. Seeing INT(2) in a schema review usually means someone confused the two — worth checking even when the column “works.”
Birth dates as unix timestamps
Storing date-of-birth as a unix time cast to INT fails several ways:
- Signed 32-bit unix time does not cover pre-1970 births
- Display width like
INT(22)does not enlarge the type - You store more precision (and PII surface) than many products need
Prefer DATE, or YEAR when only the year is required. Match the type to the domain, not to a language’s default integer.