MySQL INT(11): Storage Size in Bytes & Max Value

An INT(11) column in MySQL always takes up 4 bytes of storage—no more, no less, regardless of that “11” you see in the declaration. For signed integers (the default), the maximum value is 2,147,483,647; switch to unsigned, and it jumps to 4,294,967,295. It’s a common mix-up thinking the (11) changes these limits, but it doesn’t—it’s just a display hint.

Contents

• What is an INT(11) Column in MySQL?
• Storage Size of INT(11) in MySQL
• Maximum Values for INT(11) (Signed vs Unsigned)
• Why the (11) Doesn’t Affect Storage or Range
• Common Misconceptions and Best Practices
• Sources
• Conclusion

What is an INT(11) Column in MySQL?

Picture this: you’re designing a table for user IDs or counts, and you slap on INT(11). What does that even mean? In MySQL, INT is a fixed-size integer type—short for “integer”—and the (11) is a display width specifier. It tells tools like the mysql client how many characters to pad with spaces or zeros (if you use ZEROFILL), but it has zero impact on storage or the actual values you can cram in there.

Ever created a table and wondered why your big numbers still fit fine? That’s because MySQL ignores the display width for storage decisions. The official MySQL integer types documentation lays it out clearly: INT is always 4 bytes, signed by default. Here’s a quick CREATE TABLE example to see it in action:

CREATE TABLE example (
 id INT(11) PRIMARY KEY AUTO_INCREMENT,
 big_num INT(11) UNSIGNED
);

Insert 4 billion? No sweat for the unsigned one.

Storage Size of INT(11) in MySQL

Straight to the point: the storage size of an INT(11) column in MySQL is 4 bytes. Always. Doesn’t matter if it’s 1, 11, or 20 in the parentheses—MySQL standardizes INT at 32 bits, or 4 bytes.

Why so consistent? MySQL uses fixed-width storage for integers to keep things blazing fast and predictable. The MySQL storage requirements page spells it out in their table:

This holds across InnoDB, MyISAM, you name it. Row limits cap at 65,535 bytes total, but one INT(11)? Negligible. Test it yourself: SHOW CREATE TABLE won’t reveal the width affecting bytes on disk.

And yeah, as of MySQL 8.4 and even previews of 9.5, nothing’s changed—still 4 bytes firm.

Maximum Values for INT(11) (Signed vs Unsigned)

Now, the maximum value for INT(11) in MySQL. Signed (default): tops out at 2,147,483,647. That’s 2^31 - 1, covering negatives down to -2,147,483,648. Go unsigned with INT(11) UNSIGNED, and you’re golden up to 4,294,967,295—full 2^32 - 1.

Quick comparison table from the docs:

Hit the limit? Overflow wraps around or errors out, depending on SQL mode. Pro tip: for positive-only like timestamps or counters, unsigned saves headaches.

Why the (11) Doesn’t Affect Storage or Range

Here’s where folks trip up: “INT(11) means 11 digits, right? So bigger storage?” Nope. The (11) is purely a visual cue for display width in clients. Without ZEROFILL, MySQL ignores it completely for storage, range, or anything functional.

Add ZEROFILL, though:

CREATE TABLE test (num INT(11) ZEROFILL);
INSERT INTO test VALUES (42); -- Displays as 00000000042

Still 4 bytes underneath. The storage requirements docs confirm: display width “is not used to determine the storage required for values.” It’s a relic from old days, ignored in modern apps.

Stack Overflow threads echo this—veterans point to official sources every time.

Common Misconceptions and Best Practices

Think INT(11) locks you to 11 digits max? Wrong—2 billion+ fits fine (10 digits). Or that it auto-pads? Only with ZEROFILL, and even then, storage stays 4 bytes.

Some blogs muddle it with SMALLINT (2 bytes), but stick to docs. Best practices?

• Use UNSIGNED for non-negatives—doubles your range.
• BIGINT for millions/billions if needed (8 bytes).
• Skip arbitrary widths like (11); they’re noise.
• Check with INFORMATION_SCHEMA.COLUMNS for real metadata.

In database design, this clarity prevents bloat. Your app scales better without myths.

Sources

1. MySQL Integer Types — Official documentation on INT storage and display width: https://dev.mysql.com/doc/refman/8.0/en/integer-types.html
2. MySQL Storage Requirements — Detailed byte sizes for all integer types including INT: https://dev.mysql.com/doc/refman/8.0/en/storage-requirements.html
3. MySQL 8.4 Storage Requirements — Updated storage tables confirming 4 bytes for INT: https://dev.mysql.com/doc/refman/8.4/en/storage-requirements.html
4. Stack Overflow: Size of INT(11) — Community discussion validating 4-byte storage with doc references: https://stackoverflow.com/questions/5634104/what-is-the-size-of-column-of-int11-in-mysql-in-bytes
5. Devart Blog: MySQL INT Data Type — Explains display width irrelevance for storage: https://blog.devart.com/mysql-int-data-type.html

Conclusion

Bottom line: MySQL INT(11) storage is a rock-solid 4 bytes, max signed value 2,147,483,647 (or 4+ billion unsigned), and that (11) is just window dressing. Ditch the confusion, design smarter with UNSIGNED where it fits, and always peek at the official docs for your version. Your databases will thank you—faster, leaner, no surprises.