Well, the table already shows the difference. Trying to use other words:

• The first one occupies 2 bytes and allows 65536 distinct numbers, usually half for each side
• The second occupy occupies 4 bytes and allows more than 4 billion variations being the normal half negative and half positive. What sets it apart is the storage capacity.

The question of 3 in parentheses is that it will be presented by default with 3 digits, which does not make much sense for both cases, 3 makes sense for TINYINT . But note that it's just presentation, does not occupy less or more space, does not change precision, accuracy, none of that. It is only when presented in the database.

Obviously I will not repeat what is already in the question.

The difference is the range of values that they accept (according to the table), that is:

Signed

SMALLINT: -32768 to 32767

INT: -2147483648 to 2147483647

Unsigned

SMALLINT: 0 to 65535

INT: 0 to 4294967295

Difference from Signed to Unsigned

Each type has its limit in bytes (eg SMALLINT 1 byte).

Signed : "divide" the possible amount between negative and positive.

Unsigned : "does not divide" thus accepting only positive numbers.

Value in parenthesis

A very explanatory quote ( Font ):

  

5 - Values need to be filled with leading zeros or have   an expected width?

     

The answer to question five is only used for formatting the   number. If we want the numbers to be returned with zeros to   left, we use the "ZEROFILL" modifier. The "width" of the   fields is used so that the application can display the value with spaces   left. The width of the fields is returned between the metadata   from a query.

     

Width is specified differently for integers and reals. We   integers, the width is specified in parentheses after the   field name (for example "INT (11)"). For real numbers, the   width is precisely the precision of the field (cited above), the   difference is that the precision number becomes the total width of the   field, including punctuation.

     

The biggest confusion I see around is the use of the "width" of the field   thinking that it is the "maximum digit capacity" of the field. This is   wrong. That is, if the field is INT (1), INT (2) or INT (11), its value   maximum will remain "2,147,483,647". To specify fields with   higher or lower capacity, field variations should be used   (TINYINT, SMALLINT, MEDIUMINT or BIGINT to INT fields or use FLOAT   or DOUBLE to floating-point fields).

     

Note: The ZEROFILL option automatically applies the UNSIGNED option   in the field, even though you have explicitly specified SIGNED.

Completing your question:

You can use SMALLINT to BIGINT because everyone accepts values: 72 , or 240 , or 300 .

The value in parenthesis (3) means that your column will be limited in 3 visible digits, but the values will still be possible according to the limits of the field.

Useful links

Official Documentation

According to progression, accept ranges of increasing numbers.

tinyint = 1 byte
smallint = 2 bytes
mediumint = 3 bytes
int = 4 bytes
bigint = 8 bytes

As for the quantity of characters, totally agree. As for (3), there are two things to think about using this. First, you indicate (3), your BD will always reserve this specific space for that value, whether you include value with 1 or 3 characters, which will improve when it comes to queries performance, especially when this DB begins to take larger proportions. Now, if you think more of space, whenever you specify a specific number of characters, this space will always be reserved, taking up more memory space than a dynamic field, such as 'int ()'. Obviously, with a dynamic field, there is the question that the query will first need to check the number of characters before returning the value, since it can only return after the mapping.

In short (with examples for integer int):

Int (): Allocate the amount of memory dynamically, depending on the amount of characters included.

Int (3): It will allocate memory for 3 characters, regardless of whether it includes 1 or 999 in its result.