Introduction

In MySQL, INT(11) does not mean “an integer that stores 11 digits.” This is the core misunderstanding behind questions like int(11) vs int(4) vs int(20). For the INT type, storage size and numeric range come from the type itself, not from the number in parentheses. Historically that number was display width, and in modern MySQL it is deprecated and effectively not something you should rely on for schema design.

What INT Actually Means

A normal MySQL INT is a 4-byte integer.

Its range is determined by signedness:

• signed INT: -2147483648 to 2147483647
• unsigned INT: 0 to 4294967295

That range is the same whether you write:

1INT
2INT(4)
3INT(11)
4INT(20)

The parentheses do not change the storage size of INT and do not change how many digits it can truly store.

What the Number in Parentheses Used to Mean

Historically, the number in INT(11) was display width. It affected how MySQL clients could display the value, especially when combined with ZEROFILL.

Example:

CREATE TABLE demo (
    id INT(5) ZEROFILL
);

If you inserted 42, a client could display it as:

00042

That padding was presentation behavior, not a change in storage capacity.

This is why INT(11) became so common in old schemas: tools and examples generated it automatically, even though developers often misread it as a capacity declaration.

Modern MySQL Behavior

In modern MySQL, integer display width has been deprecated and is not something you should use as a schema-design signal. So when you see old advice centered on INT(11), treat it as legacy vocabulary, not an important tuning knob.

For practical schema work today, the important choices are:

• 'TINYINT'
• 'SMALLINT'
• 'MEDIUMINT'
• 'INT'
• 'BIGINT'
• signed versus unsigned

Those choices actually affect storage and range.

A Comparison That Really Matters

This comparison is meaningful:

1CREATE TABLE sizes (
2    a TINYINT,
3    b SMALLINT,
4    c INT,
5    d BIGINT
6);

These types differ in storage and range.

This comparison is usually not meaningful for storage design:

INT(3)
INT(11)
INT(99)

If they are all plain INT, the underlying numeric type is the same.

Choosing the Right Integer Type

Choose the type based on expected range, not on how many digits you hope the parentheses imply.

For example:

• small flags or tiny counters: TINYINT
• moderate bounded counts: SMALLINT
• common IDs or counters: INT
• very large identifiers: BIGINT

A bad schema habit is picking INT(11) reflexively for every integer column. The better habit is asking what range the column truly needs.

If You Want Formatting, Format in the Application

If your business requirement is “show this number with leading zeros,” that is usually presentation logic, not database type logic.

For example, if order number 42 should display as 00042, format it when reading it:

order_id = 42
print(f"{order_id:05d}")

or in SQL when absolutely necessary:

SELECT LPAD(id, 5, '0') AS formatted_id FROM orders;

That is far clearer than trying to smuggle display intentions into INT(5).

Signed vs Unsigned Often Matters More

If the column can never be negative, UNSIGNED may be the more relevant design choice.

CREATE TABLE users (
    id INT UNSIGNED NOT NULL PRIMARY KEY
);

This changes the numeric range. That is a real storage-model decision.

So if you are thinking about capacity, signedness matters. Display width does not.

Common Pitfalls

The biggest pitfall is believing INT(11) stores 11 digits and INT(4) stores only 4 digits. That is false.

Another issue is carrying forward old schemas that use INT(11) everywhere and assuming the width is a meaningful tuning choice.

Developers also sometimes use database type declarations to solve UI formatting problems such as leading zeros.

Finally, when range is the real concern, focus on type family and signedness instead of parentheses.

Summary

• 'INT(11) is still an INT, not a special 11-digit storage type.'
• For INT, the number in parentheses was historically display width, not capacity.
• Modern MySQL treats integer display width as legacy and not something to design around.
• Real schema decisions come from the integer type itself and from signed versus unsigned.
• If you need padded display output, format it explicitly in the application or query layer instead of relying on INT(11).