I have seen on many engagements the column data type is defined as INT(1).
People have the misconception that this numeric integer data type is of the length of one digit, or one byte. (One digit is 0-9 an one byte is 0-255)
This is incorrect.
Integer
For integer numeric data types in MySQL, that is TINYINT, SMALLINT, MEDIUMINT, INT, BIGINT the (n) has no bearing on the size of data stored within the specific data type. The (n) is simply for display formatting.
In the MySQL Manual 10.2. Numeric Types you read This optional display width is used to display integer values having a width less than the width specified for the column by left-padding them with spaces. The display width does not constrain the range of values that can be stored in the column, nor the number of digits that are displayed for values having a width exceeding that specified for the column.
The following example shows the (n) in this case 3 has no effect on the size of data stored.
DROP TABLE IF EXISTS numeric_int; CREATE TABLE numeric_int(i INT(3) NOT NULL); INSERT INTO numeric_int VALUES (1),(22),(333),(444),(55555); SELECT * FROM numeric_intG i: 1 i: 22 i: 333 i: 444 i: 55555
Floating Point
When it comes to floating point precision of FLOAT and DOUBLE, the syntax of (m,n) has a different inteperation. The manual states _A precision from 0 to 23 results in a four-byte single-precision FLOAT column. A precision from 24 to 53 results in an eight-byte double-precision DOUBLE column.
_ I will discuss this some more in a different post with some interesting findings.
And MySQL allows a non-standard syntax: FLOAT(M,D) or REAL(M,D) or DOUBLE PRECISION(M,D). Here, “(M,D)” means than values can be stored with up to M digits in total, of which D digits may be after the decimal point. For example, a column defined as FLOAT(7,4) will look like -999.9999 when displayed. MySQL performs rounding when storing values, so if you insert 999.00009 into a FLOAT(7,4) column, the approximate result is 999.0001.
So in the case of FLOAT,DOUBLE the (n) does both affect storage and presentation where it rounds the number as confirmed by the following test. Look a the last 2 rows for the rounding confirmation.
DROP TABLE IF EXISTS numeric_float; CREATE TABLE numeric_float(f1 FLOAT(10,5) NOT NULL); INSERT INTO numeric_float values (1),(2.0),(3.12345),(4.123451),(5.123456); Query OK, 5 rows affected (0.00 sec) Records: 5 Duplicates: 0 Warnings: 0 SELECT * FROM numeric_floatG f1: 1.00000 f1: 2.00000 f1: 3.12345 f1: 4.12345 f1: 5.12346 5 rows in set (0.01 sec)
Fixed Precision
The DECIMAL data type (NUMBER is a synonym) stores numbers to a fixed number of precision. From the manual again When declaring a DECIMAL or NUMERIC column, the precision and scale can be (and usually is) specified; for example: salary DECIMAL(5,2)
In this example, 5 is the precision and 2 is the scale. The precision represents the number of significant digits that are stored for values, and the scale represents the number of digits that can be stored following the decimal point. If the scale is 0, DECIMAL and NUMERIC values contain no decimal point or fractional part.
So in our test:
DROP TABLE IF EXISTS numeric_decimal; CREATE TABLE numeric_decimal(f1 DECIMAL(10,5) NOT NULL); INSERT INTO numeric_decimal values (1),(2.0),(3.12345),(4.123451),(5.123456); Query OK, 5 rows affected, 2 warnings (0.00 sec) SELECT * FROM numeric_decimalG f1: 1.00000 f1: 2.00000 f1: 3.12345 f1: 4.12345 f1: 5.12346
What is also interesting is that with a FLOAT, the rounding of a number greater then (n), produces no warnings, yet when using DECIMAL you will see warnings. These are:
INSERT INTO numeric_decimal values (1),(2.0),(3.12345),(4.123451),(5.123456); Query OK, 5 rows affected, 2 warnings (0.00 sec) Records: 5 Duplicates: 0 Warnings: 2 mysql> show warnings; +-------+------+-----------------------------------------+ | Level | Code | Message | +-------+------+-----------------------------------------+ | Note | 1265 | Data truncated for column 'f1' at row 4 | | Note | 1265 | Data truncated for column 'f1' at row 5 | +-------+------+-----------------------------------------+ 2 rows in set (0.00 sec)
What is also interesting is that the manual states the following When such a column is assigned a value with more digits following the decimal point than are allowed by the specified scale, the value is converted to that scale. (The precise behavior is operating system-specific, but generally the effect is truncation to the allowable number of digits.)
The number is generally truncated, buy differs per OS. In the case on Mac O/S and Linux it is rounded. The two test environments in this case where:
mysql> show variables like '%version%'; +-------------------------+------------------------------+ | Variable_name | Value | +-------------------------+------------------------------+ | protocol_version | 10 | | version | 5.1.23-rc | | version_comment | MySQL Community Server (GPL) | | version_compile_machine | i686 | | version_compile_os | apple-darwin9.0.0b5 | +-------------------------+------------------------------+ 5 rows in set (0.01 sec) mysql> show variables like '%version%'; +-------------------------+------------------------------+ | Variable_name | Value | +-------------------------+------------------------------+ | protocol_version | 10 | | version | 5.1.24-rc | | version_comment | MySQL Community Server (GPL) | | version_compile_machine | i686 | | version_compile_os | redhat-linux-gnu | +-------------------------+------------------------------+ 5 rows in set (0.41 sec)
Conclusion
So just to conclude, (n) for Integer types is for display formatting only, (m,n) for floating point will round the number at n places, while in fixed point (m,n) n will round or truncate the number.
About the Author
Ronald Bradford
provides Consulting and Advisory Services
in Data Architecture, Performance and Scalability for MySQL Solutions. An IT industry professional for two decades with extensive database experience in MySQL, Oracle and Ingres his expertise covers data architecture, software development, migration, performance analysis and production system implementations. His knowledge from 10 years of consulting across many industry sectors, technologies and countries has provided unique insight into being able to provide solutions to problems. For more information Contact Ronald
.
