http://waynewhitty.ie/blog-post.php?id=19

MySQL - INT(11) vs BIGINT(11) vs TINYINT(11)

This seems to be a common misconception among many developers who interact with MySQL. The assumption is that the 11 inINT(11) determines the maximum size of the integer that the column can store. i.e. That a column set to INT(11) will hold an integer value up to 11 digits in length and that a column set to INT(6) will hold an integer value that is up to 6 digits in length.This misconception exists because of three reasons:

1. Developers rarely get caught out by it. This is because a regular integer column can store integer values up to 2147483647. That‘s close to 2.15 billion. This means that an integer primary key wont "hit the ceiling" until the table in question holds more than 2 billion rows. In most cases, this never happens.
2. String data types such as CHAR and VARCHAR do allow you to specify the maximum length. For example: A column set toVARCHAR(30) will only hold 30 characters or less. Anything over that amount will be truncated.
3. A lot of developers never read the manual.

So, if the 11 in INT(11) isn‘t a determinant for the column‘s maximum size, what is? Simply put: It‘s the data type itself that determines the maximum value. For instance: A regular TINYINT column will always have a max value of 127, an INT column will always have a maximum value of 2147483647 and a BIGINT column will always have a maximum value of 9223372036854775807. The number in brackets has zero affect on the size of the integer being stored. To get a full list of the ranges of integer data types, have a look at the official manual.

What does the number in brackets actually do?

To be honest, the number in brackets is kind of usless unless you‘re using the ZEROFILL attribute. All it does is tell MySQL what width to display the column at when the table‘s data is being viewed via the MySQL console. If you‘re using the ZEROFILL attribute, the number in brackets will tell MySQL how many zeros to pad incoming integers with. For example: If you‘re using ZEROFILL on a column that is set to INT(5) and the number 78 is inserted, MySQL will pad that value with zeros until the number satisfies the number in brackets. i.e. 78 will become 00078 and 127 will become 00127. To sum it up: The number in brackets is used for display purposes.

Side note

The official MySQL manual  also lists the number of bytes that each integer data type requires. A TINYINT will take up 1 byte. A SMALLINT will take up 2 bytes. An INT will take up 4 bytes. A BIGINT will take up 8 bytes. This means that you should choose your integer data types wisely. Last week, I switched a column from INT(1) to TINYINT(1) because it was only being used to store 1s and 0s. The result? An unncessary 6MB was shaved off the total size of the table. After making similar changes to a few more columns, I had managed to get rid of 25MB of uneeded data. Try to keep this in mind the next time you‘re using an INT instead of a TINYINT or a BIGINT instead of an INT.

MySQL 5.7 Reference Manual  /  ...  /  Integer Types (Exact Value) - INTEGER, INT, SMALLINT, TINYINT, MEDIUMINT, BIGINT

12.2.1 Integer Types (Exact Value) - INTEGER, INT, SMALLINT, TINYINT, MEDIUMINT, BIGINT

MySQL supports the SQL standard integer types INTEGER (or INT) and SMALLINT. As an extension to the standard, MySQL also supports the integer types TINYINT, MEDIUMINT, and BIGINT. The following table shows the required storage and range for each integer type.

MySQL 5.7 Reference Manual  /  ...  /  The CHAR and VARCHAR Types

12.4.1 The CHAR and VARCHAR Types

The CHAR and VARCHAR types are similar, but differ in the way they are stored and retrieved. They also differ in maximum length and in whether trailing spaces are retained.

The CHAR and VARCHAR types are declared with a length that indicates the maximum number of characters you want to store. For example, CHAR(30) can hold up to 30 characters.

The length of a CHAR column is fixed to the length that you declare when you create the table. The length can be any value from 0 to 255. When CHAR values are stored, they are right-padded with spaces to the specified length. When CHAR values are retrieved, trailing spaces are removed unless the PAD_CHAR_TO_FULL_LENGTH SQL mode is enabled.

Values in VARCHAR columns are variable-length strings. The length can be specified as a value from 0 to 65,535. The effective maximum length of a VARCHAR is subject to the maximum row size (65,535 bytes, which is shared among all columns) and the character set used. See Section C.10.4, “Limits on Table Column Count and Row Size”.

In contrast to CHAR, VARCHAR values are stored as a 1-byte or 2-byte length prefix plus data. The length prefix indicates the number of bytes in the value. A column uses one length byte if values require no more than 255 bytes, two length bytes if values may require more than 255 bytes.

If strict SQL mode is not enabled and you assign a value to a CHAR or VARCHAR column that exceeds the column‘s maximum length, the value is truncated to fit and a warning is generated. For truncation of nonspace characters, you can cause an error to occur (rather than a warning) and suppress insertion of the value by using strict SQL mode. See Section 6.1.7, “Server SQL Modes”.

For VARCHAR columns, trailing spaces in excess of the column length are truncated prior to insertion and a warning is generated, regardless of the SQL mode in use. For CHAR columns, truncation of excess trailing spaces from inserted values is performed silently regardless of the SQL mode.

VARCHAR values are not padded when they are stored. Trailing spaces are retained when values are stored and retrieved, in conformance with standard SQL.

The following table illustrates the differences between CHAR and VARCHAR by showing the result of storing various string values intoCHAR(4) and VARCHAR(4) columns (assuming that the column uses a single-byte character set such as latin1).

The values shown as stored in the last row of the table apply only when not using strict mode; if MySQL is running in strict mode, values that exceed the column length are not stored, and an error results.

If a given value is stored into the CHAR(4) and VARCHAR(4) columns, the values retrieved from the columns are not always the same because trailing spaces are removed from CHAR columns upon retrieval. The following example illustrates this difference:

mysql> CREATE TABLE vc (v VARCHAR(4), c CHAR(4));
Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO vc VALUES (‘ab  ‘, ‘ab  ‘);
Query OK, 1 row affected (0.00 sec)

mysql> SELECT CONCAT(‘(‘, v, ‘)‘), CONCAT(‘(‘, c, ‘)‘) FROM vc;
+---------------------+---------------------+
| CONCAT(‘(‘, v, ‘)‘) | CONCAT(‘(‘, c, ‘)‘) |
+---------------------+---------------------+
| (ab  )              | (ab)                |
+---------------------+---------------------+
1 row in set (0.06 sec)

Values in CHAR and VARCHAR columns are sorted and compared according to the character set collation assigned to the column.

All MySQL collations are of type PADSPACE. This means that all CHAR, VARCHAR, and TEXT values in MySQL are compared without regard to any trailing spaces. “Comparison” in this context does not include the LIKE pattern-matching operator, for which trailing spaces are significant. For example:

mysql> CREATE TABLE names (myname CHAR(10));
Query OK, 0 rows affected (0.03 sec)

mysql> INSERT INTO names VALUES (‘Monty‘);
Query OK, 1 row affected (0.00 sec)

mysql> SELECT myname = ‘Monty‘, myname = ‘Monty  ‘ FROM names;
+------------------+--------------------+
| myname = ‘Monty‘ | myname = ‘Monty  ‘ |
+------------------+--------------------+
|                1 |                  1 |
+------------------+--------------------+
1 row in set (0.00 sec)

mysql> SELECT myname LIKE ‘Monty‘, myname LIKE ‘Monty  ‘ FROM names;
+---------------------+-----------------------+
| myname LIKE ‘Monty‘ | myname LIKE ‘Monty  ‘ |
+---------------------+-----------------------+
|                   1 |                     0 |
+---------------------+-----------------------+
1 row in set (0.00 sec)

This is true for all MySQL versions, and is not affected by the server SQL mode.

Note

For more information about MySQL character sets and collations, see Section 11.1, “Character Set Support”. For additional information about storage requirements, see Section 12.8, “Data Type Storage Requirements”.

For those cases where trailing pad characters are stripped or comparisons ignore them, if a column has an index that requires unique values, inserting into the column values that differ only in number of trailing pad characters will result in a duplicate-key error. For example, if a table contains ‘a‘, an attempt to store ‘a ‘ causes a duplicate-key error.

https://dev.mysql.com/doc/refman/5.5/en/sql-mode.html#sqlmode_no_auto_value_on_zero

The Most Important SQL Modes

The most important sql_mode values are probably these:

• ANSI

  This mode changes syntax and behavior to conform more closely to standard SQL. It is one of the special combination modeslisted at the end of this section.

• STRICT_TRANS_TABLES

  If a value could not be inserted as given into a transactional table, abort the statement. For a nontransactional table, abort the statement if the value occurs in a single-row statement or the first row of a multiple-row statement. More details are given later in this section.

• TRADITIONAL

  Make MySQL behave like a “traditional” SQL database system. A simple description of this mode is “give an error instead of a warning” when inserting an incorrect value into a column. It is one of the special combination modes listed at the end of this section.

  Note

  The INSERT or UPDATE aborts as soon as the error is noticed. This may not be what you want if you are using a nontransactional storage engine, because data changes made prior to the error may not be rolled back, resulting in a “partially done” update.

When this manual refers to “strict mode,” it means a mode with either or both STRICT_TRANS_TABLES or STRICT_ALL_TABLESenabled.

小结：

0-int(4)  int(11) 区别在于补0的位数，但补0需开启ZEROFILL，二者所占的存储空间一致；

 1 mysql> use w0811;
 2 Database changed
 3 mysql> CREATE TABLE w_int (wint int);
 4 Query OK, 0 rows affected (0.01 sec)
 5
 6 mysql> INSERT INTO w_int VALUES (23);
 7 Query OK, 1 row affected (0.01 sec)
 8
 9 mysql> select * from w_int;
10 +------+
11 | wint |
12 +------+
13 |   23 |
14 +------+
15 1 row in set (0.00 sec)
16
17 mysql>

建议商城类数据库，直接用int 而非int（x）来设计表，客户端需要补全0的话，用php或js脚本实现；application中，tinyint满足需求的话，就不用smallint等，以此来节省空间。

发问：

0-沿袭的误区，misconception，是怎么造成的呢？