Documentation Home
MySQL 5.7 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 38.2Mb
PDF (A4) - 38.2Mb
PDF (RPM) - 37.1Mb
HTML Download (TGZ) - 10.2Mb
HTML Download (Zip) - 10.3Mb
HTML Download (RPM) - 9.0Mb
Man Pages (TGZ) - 206.2Kb
Man Pages (Zip) - 314.7Kb
Info (Gzip) - 3.5Mb
Info (Zip) - 3.5Mb
Excerpts from this Manual

MySQL 5.7 Reference Manual  /  Data Types  /  Choosing the Right Type for a Column

11.9 Choosing the Right Type for a Column

For optimum storage, you should try to use the most precise type in all cases. For example, if an integer column is used for values in the range from 1 to 99999, MEDIUMINT UNSIGNED is the best type. Of the types that represent all the required values, this type uses the least amount of storage.

All basic calculations (+, -, *, and /) with DECIMAL columns are done with precision of 65 decimal (base 10) digits. See Section 11.1.1, “Numeric Type Overview”.

If accuracy is not too important or if speed is the highest priority, the DOUBLE type may be good enough. For high precision, you can always convert to a fixed-point type stored in a BIGINT. This enables you to do all calculations with 64-bit integers and then convert results back to floating-point values as necessary.

User Comments
  Posted by Martin Feuchtwanger on August 29, 2008
Instead of

"For the most efficient use of storage, try to use the MOST precise type in all cases."

I think it should be

"For the most efficient use of storage, try to use the LEAST precise type THAT WILL ACCOMMODATE ALL POSSIBLE VALUES in all cases."

(EMPHASIS made just to highlight the difference.)
  Posted by Jalil Latiff on February 11, 2012
i think the precision he meant refers to the TYPE rather than the numbers. If you have numeric data for example, you can also store it as string, but it would be more precise to store it as the relevant numeric type, as it would be more efficient.
  Posted by Austin Bennett on June 22, 2017
I understand what Martin was saying 9 years ago but unfortunately it's no less true now than it was then. He's thinking of efficiency in a categorical context. This would be true if we were talking about searching and crawling but we're talking about storage here. So how the data is found comes secondary to the method used to store it. Using the precise data type for the data in question will result in the optimum conditions for it to be both found and stored. Now, if we could develop the, "Junk Drawer" data type for stashing mismatching/unrelated JSON strings I do believe we can call it a day!
Sign Up Login You must be logged in to post a comment.