Get rows product (multiplication)

I guess this would work...

SELECT IF(MOD(COUNT(data < 0),2)=1        , EXP(SUM(LOG(data)))*-1        , EXP(SUM(LOG(data))))          x   FROM my_table;

If you need this type of calculations often, I suggest you store the signs and the logarithms in separate columns.

The signs can be stored as 1 (for positives), -1 (for negatives) and 0 (for zero.)

The logarithm can be assigned for zero as 0 (or any other value) but it should not be used in calculations.

Then the calculation would be:

SELECT     CASE WHEN EXISTS (SELECT 1 FROM test WHERE <condition> AND datasign = 0)         THEN 0         ELSE (SELECT 1-2*(SUM(datasign=-1)%2) FROM test WHERE <condition>)    END AS resultsign,    CASE WHEN EXISTS (SELECT 1 FROM test WHERE <condition> AND datasign = 0)         THEN -1            -- undefined log for result 0         ELSE (SELECT SUM(datalog) FROM test WHERE <condition> AND datasign <> 0)    END AS resultlog  ;

This way, you have no overflow problems. You can check the resultlog if it exceeds some limits or just try to calculate resultdata = resultsign * EXP(resultlog) and see if an error is thrown.

This question is a remarkable one in the sea of low quality ones. Thank you, even reading it was a pleasure.

Precision

The exp(log(a)+log(b)) idea is a good one in itself. However, after reading "What Every Computer Scientist Should Know About Floating-Point Arithmetic", make sure you use DECIMAL or NUMERIC data types to be sure you are using Precision Math, or else your values will be surprisingly inaccurate. For a couple of million rows, errors can add up very quickly! DECIMAL (as per the MySQL doc) has a maximum of 65 digits precision, while for example 64bit IEEE754 floating point values have only up to 16 digits (log10(2^52) = 15.65) precision!

Overflow

As per the relevant part of the MySQL doc:

• Integer overflow results in silent wraparound.
• DECIMAL overflow results in a truncated result and a warning.
• Floating-point overflow produces a NULL result. Overflow for some operations can result in +INF, -INF, or NaN.

So you can detect floating point overflow if it would ever happen.

Sadly, if a series of operations would result in a correct value, fitting into the data type used, but at least one subresult in the process of calculations would not, then you won't get the correct value at the end.

Performance

Premature optimization is the root of all evil. Try it, and if it is slow, take the appropriate actions. Doing this might not be lightning quick, but still might be quicker than getting all the results, and doing it on the application server. Only measurements can decide which gets to be quicker...