I have a table with high precision value, stored as Float. When I query the table for that value it returns rounded off value, rounded to 1st digit. But when I run the below query I am getting the value that I have stored,
SELECT MY_FLOAT_COL*1 FROM MY_TABLE;
What's going on inside Mysql?
If you want to store exact values, you'd use the DECIMAL data types.
By manual of FLOAT:
The FLOAT and DOUBLE types represent approximate numeric data values. MySQL uses four bytes for single-precision values
The thing to mention here is approximation.
You can read more on floats here: http://dev.mysql.com/doc/internals/en/floating-point-types.html
Related
I have a mysql database with a table X having float unsigned column amount.
The value is saved properly with two decimal places when the value is less than 10000.
But for data more than that it is rounding off two decimal places to one.
I am not sure if >10000 is causing this but thats the primary suspect.
The value is being mapped to Float amount in the application entity.
I don't know why numbers are getting rounded off for some amount values.
Did anyone face similar issue?
MySQL performs rounding when storing values according to the length of Float column. The quick fix is to set the length of the Float column in your MySql table e.g. FLOAT(11,2)
MySQL reference can be found here: Floating-Point Types (Approximate Value).
Is there any reason to use a DOUBLE(n, 0) over a BIGINT(n) in MySQL? If the data will never have a decimal portion, is there any reason to store as a DOUBLE?
There is only one reason to ever use DOUBLE or FLOAT in MySQL -- if scale and/or storage efficiency are important, but precision is not. This is not a limitation of MySQL, but rather of floating point numbers in general, which is that they are stored as approximate values.
Integers will be stored cleanly up to only about 2⁵³, which is smaller than BIGINT. Most (though not all) integers beyond that range will be stored as a value that is only close to correct.
Floating-point numbers sometimes cause confusion because they are approximate and not stored as exact values. A floating-point value as written in an SQL statement may not be the same as the value represented internally. Attempts to treat floating-point values as exact in comparisons may lead to problems. They are also subject to platform or implementation dependencies.
— Problems with Floating Point Values
For integers, use one of the *INT types. For decimal, use DECIMAL.
I'm somewhat confused on defining the correct definition for a float table column. This is required to create a database table to store large numbers which have up to eight decimal places. I need to be able to store anywhere from and between the following two.
0.00000001 - 10000000
Would that be defined as float(16) as the argument is the maximum number of digits that need to be displayed. Perhaps I have misunderstood the column definition entirely.
FLOAT is approximate datatype and I would not recommend it to use for storing exact values.
For storing exact numbers you should use DECIMAL datatype:
CREATE TABLE tab(col DECIMAL(20,10));
Should be more than sufficent for your needs.
I have the following SQL query.
SELECT SUM(final_insurance_total) as total
FROM `leads`
GROUP BY leads.status
I have a single row of data in the lead table with a value for final_insurance_total of 458796. The data type for final_insurance_total is float.
For some reason, MySQL is summing a single row as "458796.375".
If I change the query to
SELECT (final_insurance_total) as total
FROM `leads`
GROUP BY leads.status
the correct value is returned. What in the world is going on?
The FLOAT and DOUBLE types in MySQL (as well as in other databases and programming language runtimes) are represented in a special way, which leads to the values stored being approximations, not exact values. See MySQL docs, as well as general information on floating-point arithmetics.
In order to store and operate with exact values, use the type DECIMAL (see https://dev.mysql.com/doc/refman/5.1/en/precision-math-decimal-characteristics.html).
EDIT: I have run some tests, and while floating-point precision errors are quite common, this particular one looks to be specific to the implementation of SUM() in MySQL. In other words, it is a bug that has been there for a long time. In any case, you should use DECIMAL as your field type.
FLOAT does not guarantee precision where any calculation is made. If you use a simple SELECT, no calculation is made, so you get the original value. But if you use SUM(), even with one row, at least one addition is executed (0 + current_value).
Do you really need FLOAT? For example, if you have 2 decimal digits, you could use INT and multiply all values by 100 before all INSERTs. When SELECTing results, you will divide by 100.
If the user is not a sysadmin and cannot change the datatype of the field such as FLOAT, the user can use CAST to produce the desired output.
I'm trying to store a currency value in MySQL (InnoDb) and I need to write queries to aggregate some records (sum) and I'm having problem with the precision of the the output!
I've set the field's type to double and my values are some what precise but the MySQL's operators are not as precise as I need. For what it is worth, PHP's default operators are not precise enough either but there's bc* functions in PHP which can do the trick.
I was wondering if there's any way to tune the precision of MySQL operators? Including aggregation functions?
For the record, storing to and retrieving from MySQL won't affect my values which means double is an ideal type for my fields.
Since money needs an exact representation don't use data types that are only approximate like double which is a floating-point. You can use a fixed-point numeric data type for that like
numeric(15,2)
15 is the precision (total length of value including decimal places)
2 is the number of digits after decimal point
See MySQL Numeric Types:
These types are used when it is important to preserve exact precision, for example with monetary data.