MySQL: Does the "length" setting affect table size in bytes?

Question

Regarding setting the length of allowable characters for a field (11) in the example:

database table columns in a gui

Does this number affect the size of the table?

For example, I want to create a char type column and I only want to use three letter codes. Does setting the length to 3 make for a smaller byte size overall?

Is it a waste of space to set it to 16 when I know I'm only going to be using 3? Or is it purely for organizational purposes, i.e. nothing beyond three characters is allowed to be written?

• ypercubeᵀᴹ: The image shows INT while the text mentions char. What is the question about? INT, CHAR, VARCHAR or all of them?

Answer 1

No your INT will still use 4 bytes storage..

The length is only usefull if you use zerofill

Answer 2

As explained in this answer to a very similar question, the "length" is a hint, provided in result set metadata for applications that want it, of the "typical" maximum number of digits expected to be seen in the column. As documented, this doesn't change the storage requirements and does not change the range of values that can be stored in a column.

As far as I know, this is essentially a holdover from the early evolution of MySQL when fixed-width terminals were common.

MySQL supports an extension for optionally specifying the display width of integer data types in parentheses following the base keyword for the type. For example, INT(4) specifies an INT with a display width of four digits. This optional display width may be used by applications to display integer values having a width less than the width specified for the column by left-padding them with spaces. (That is, this width is present in the metadata returned with result sets. Whether it is used or not is up to the application.)

The display width does not constrain the range of values that can be stored in the column. Nor does it prevent values wider than the column display width from being displayed correctly. For example, a column specified as SMALLINT(3) has the usual SMALLINT range of -32768 to 32767, and values outside the range permitted by three digits are displayed in full using more than three digits.

When used in conjunction with the optional (nonstandard) attribute ZEROFILL, the default padding of spaces is replaced with zeros. For example, for a column declared as INT(4) ZEROFILL, a value of 5 is retrieved as 0005.

^{— http://dev.mysql.com/doc/refman/5.6/en/numeric-type-attributes.html}

Answer 3

CHAR datatype is a waste of storage if used the way you described.

If you define column as CHAR(16) and put 3 characters in it database engine will pad 13 spaces to fill all 16 characters. I assume added spaces are not significant for you.

Furthermore padding CHAR datatype costs engine resources. Application needs to be aware of trailing spaces when reading data. This is wasting of CPU.

The only reason to use CHAR instead of VARCHAR datatype is when you are 100% sure that all data in that column will have particular size. E.g. 16.

Example of such data can be: postal code, state abbreviation, gender, T/F - true/false, Y/N - yes/no, etc.

Remark: I would discourage from using any character datatype for columns involved in joins. Will be slower than numeric.