Skip navigation links

User Comments

Posted by [name withheld] on November 28 2002 12:27am[Delete] [Edit]

My brother had a case where he wanted to sort
randomly but ALSO use LIMIT so he could page
results - of course random will be different each time.

He wanted a random order that was not random for
the same session; so here is the idea:

In the web-side code calculate a numeric value which
is likely to stay the same for a session, perhaps
based on some session id, or timed-expiring cookie
value, etc, or from short-term stable HTTP headers.

Also require a numeric and well distributed value for
each record (doesn't have to be unique but works
well if it is).

Then:

... order by rand(numeric_field + session_value)
LIMIT blah;

So we see the ordering is preserved as
numeric_field+session_value will be the same for a
session, and numeric_field + session value are NOT
the same from row to row so we still get random
ordering.

Sam Liddicott

Posted by Hyungjin Ahn on January 9 2003 5:17pm[Delete] [Edit]

I might be caused by compiler ability to count to upto 30 places under zero. Win32 mysql probably mighe be compiled with 32bit compiler rather than 64bit. -- Hyungjin Ahn(ahj6@hotmail.com)

Posted by Girish Kshirsagar on November 27 2003 8:06pm[Delete] [Edit]

You may need to compare columns in databases after converting say a string column to a numeric column. These comparisons are automatic

Example
in the WHERE clause you may have to do something like this

oem.oem_id=substring(sku,5,3)

Here sku is a string who substring starting from location 5 from left and then having total length of 3 is compared with a numeric value of oem_id to satisfy the WHERE clause.

For more details see
http://www.bitmechanic.com/mail-archives/mysql/May1997/0494.html

Posted by [name withheld] on December 8 2003 1:01pm[Delete] [Edit]

I wanted to round to the nearest 0 or 5 cents in currency and this query worked:
select round((((cost*100) - (cost*100)%5) /100), 2) from SessionCost;

Posted by [name withheld] on December 22 2003 4:27am[Delete] [Edit]

If "SELECT * FROM tab ORDER BY RAND()" doesn't work for you. Try to put a random value between the brackets.

Posted by Justin Laing on January 6 2005 9:45am[Delete] [Edit]

Here is my work around for MySQL rounding issues (On most systems it rounds to the nearest even number on 5). This mess of a calculation will round up always in mysql, which is how most people in the united states think about rounding:

num = the number you are rounding

ROUND( TRUNCATE(num,2) + REPLACE( ( (num*1000) - ( TRUNCATE(num,2) *1000) / 1000, '5', '6'), 2)

This example rounds to 2 decimal places. If you want to round to three decimals just switch out the 2s for 3s and the 1000s for 10000s, etc.

It basically works by replacing all the fives beyond the two decimal places with sixes, which will always round up. Then calling the round function.

Posted by Joel Maxson on January 22 2005 5:38pm[Delete] [Edit]

Another way to round up to two decimals is using the following formula:
floor(num * 100 + .55)/100

Posted by Tim White on February 18 2005 7:48pm[Delete] [Edit]

This may be self-evident but:
In a list where some elements had priority and others not I needed to randomise the prioritised items and not the rest. The prioritised entries all had a value of 1 in a field called 'enhanced' and all entries had an abbreviated name ('abbrev') that they were otherwise sorted by. Using
ORDER BY (RAND() * enhanced) desc, abbrev
I could change the order of the enhanced listings yet maintain an alphabetical listing thereafter.

Posted by Alejandro Vargas on September 27 2005 11:53am[Delete] [Edit]

WARNING WITH ROUND AND FORMAT FUNCTIONS:

As mentioned in the manual, ROUND function has problems with values near to the limit values. The same prblem is found in the format function Let's see it:

round(1.15,1)=1.2 OK
round(1.25,1)=1.2 BAD, sould be 1.3
round(1.35,1)=1.4 OK
round(1.45,1)=1.4 BAD, sould be 1.5
round(1.55,1)=1.6 OK

And so on...

A walkarround for this sould be to use truncate adding 0,06. The same problem in found in the format function.

+---------------+----------------+-----------------------+
| round(1.45,1) | FORMAT(1.45,1) | truncate(1.45+0.06,1) |
+---------------+----------------+-----------------------+
| 1.4 | 1.4 | 1.5 |
+---------------+----------------+-----------------------+

Of corse, if you want to use more than one digit, you should add as many 0 as you need to de value added in the truncate function. Note that in case of using 2 digits, the result of format is correct but round stills failing. It is more reliable to do the calculation using your own formula, with truncate.

+----------------+-----------------+-------------------------+
| round(1.145,2) | FORMAT(1.145,2) | truncate(1.145+0.006,2) |
+----------------+-----------------+-------------------------+
| 1.14 | 1.15 | 1.15 |
+----------------+-----------------+-------------------------+

Posted by Veerappan Kannan on January 3 2006 9:16am[Delete] [Edit]

I think the "bads" are actually bankers rounding

Posted by Craig Martin on January 10 2006 2:31am[Delete] [Edit]

As truncate comment above, but negative number safe:

Take special care when using the the unsafe version with grouping functions like SUM(), as the end result can be way off if there is a big mix of negative/positive numbers.

sign(num) * truncate(abs(num)+0.06,1)

E.g...

+-----------------------+------------------------+-------------------------------------------+
| truncate(1.45+0.06,1) | truncate(-1.45+0.06,1) | sign(-1.45) * truncate(abs(-1.45)+0.06,1) |
+-----------------------+------------------------+-------------------------------------------+
| 1.5 | WRONG --> -1.3 | CORRECT --> -1.5 |
+-----------------------+------------------------+-------------------------------------------+

Posted by Ken Halsted on January 25 2006 4:28pm[Delete] [Edit]

I finally had to come up with my own solution for rounding with currency in the U.S.

Most of us consider this:

25.725 to be 25 dollars and 73 cents

But mysql was returning: round(25.725,2) as 25.72 which was throwing off my calc.

So, my workaround after not finding a solution is:

if num=25.725
============================
truncate(num + 0.0051,2)
============================

will yield this result: 25.73, which is correct.

I hope this helps someone else.

Ken

Posted by Justin Laing on March 2 2006 9:17pm[Delete] [Edit]

The rounding functions above are a little bit off from what most people would consider standard rounding.

If you use 6 as the number you are adding to the digit beyond significance then you will be rounding up 0.4s as well as 0.5s.

Here is my method:
rounding to two decimals
TRUNCATE(num + (SIGN(num) * 0.005), 2)
example 1
TRUNCATE(0.004 + (SIGN(0.004) * 0.005),2) = TRUNCATE(0.009,2) = 0.00
example 2
TRUNCATE(0.005 + (SIGN(0.005) * 0.005),2) = TRUNCATE(0.010,2) = 0.01

for three decimals it would be
TRUNCATE(num + (SIGN(num) * 0.0005), 3)
etc.

BTW this seems to be how PHP's round function works, so if you are trying to get calculations in PHP to match MySQL this is how I did it.

Posted by Tim Reynolds on April 15 2006 7:01pm[Delete] [Edit]

Am I mistaken about the command for an integer ranged RAND function...

Given what is printed here:
FLOOR(i + RAND() * (j - i))
I only ever get results in the range of i to j-1.
Shouldn't it be
FLOOR(i + RAND() * (j - i + 1 )) ?
I am getting results in the range I need with that. Maybe I am missing something, maybe once in a great while there will be a result that is j+1 and I have just not seen it.

BTW, I am using it as:
CREATE FUNCTION IRAND(param1 INT, param2 INT) RETURNS INT
RETURN FLOOR(param1 + RAND() * (param2-param1+1)) ;

Posted by Hans on May 31 2006 11:02am[Delete] [Edit]

That is true. The RAND() function returns a value 0.0 <= x <= 1.0
Thus, the values '0.0' and '1.0' can be returned althoug the changes are very very little.
In the example, where one wants a value between 7 and 12 inclusive, the value of '12' will hardly ever be returned.
I wanted a value of '0' or '1' (i.e. yes or no), so I used FLOOR(RAND() + 0.5), cuz if I'd used FLOOR(i + RAND() * (j – i), i.e. FLOOR(0 + RAND() * (1 – 0)) which evaluates to (FLOOR(RAND()), I would have gotten only one '1' and a trillillizillion 0's.



Posted by Florian Paulus on July 11 2006 9:40am[Delete] [Edit]

ROUND(X,Y)

ok i experienced like the description says different behaviour on rounding on different systems

so based on the examples by other ppl who might work for their issue but are neither save nor a
general purpose solution i have come up with my own solution for rounding up on 5

the number of decimal places you want : X
number : Y

general solution :

TRUNCATE((Y+SIGN(Y)*(POW(10,(1-X))/18)),X)

example (the other solutions fail here) :

y = 12.449
x = 1
result : 12.5

hope this helps you too

Posted by James Puddicombe on February 1 2007 2:44am[Delete] [Edit]

Simple but effective function for rounding to two decimals correctly (eg. 0.625 rounds to 0.63), unlike with the broken 'round' function

CREATE FUNCTION `v_round`(round_me DOUBLE)
RETURNS decimal(10,2)
DETERMINISTIC
SQL SECURITY DEFINER
COMMENT ''
BEGIN
return round_me;
END;

Posted by michael brenden on February 13 2007 9:50pm[Delete] [Edit]

Since using MySQL's RAND() function on a large rowset is notoriously slow:

To quickly select a random row, basically, do it in two SELECTS:

1. first SELECT finds out number of rows available, usnig a WHERE clause if desired.

2. web code chooses a random row from the number of rows (from step 1.) and saves this number in $x.

3. second SELECT (using the same WHERE clause in step 1.) uses LIMIT 1,$x.

Posted by József Rekedt-Nagy on March 28 2007 5:49am[Delete] [Edit]

Actually Order by Rand() Limit(1,X) won't work on larger sets, as it has to read through X-1 records to return the 1 you need.
In avarage it means reading through <NumberOfRecords>/2 records every time, thus it's slow.

Posted by Nate Wiger on April 8 2007 7:12pm[Delete] [Edit]

Yes, using limit is a silly way of doing that. Why not just select with id = the random id you picked?

Here's some Ruby:

max = dbh.query("select max(id) from table").fetch_row.first
rand_id = rand(max)
row = dbh.query("select * from table where id = #{rand_id}").fetch_hash
puts "Fetched: #{row['id']}"

Posted by Hero Ulster Magoncia on April 13 2007 8:11am[Delete] [Edit]

Nate:
Doing it that way doesn't work for everyone, some id values less than the max id might no longer exist in the table due to deletes.

Here's a simple solution (in php):

mysql_query('START TRANSACTION');

$count=mysql_fetch_row(mysql_query('SELECT COUNT(*) FROM table'));

$randomRow=mysql_fetch_row(mysql_query('SELECT * FROM table LIMIT '.(mt_rand(0,$count[0]-1)).',1'));

mysql_query('ROLLBACK');

Haven't really tested it, but you'd get the idea.
It's similar to michael's idea (posted above), only he had the limit parameters in the wrong order.

Posted by Mike McKee on February 11 2008 7:40am[Delete] [Edit]

Instead of using RAND and LIMIT tricks for randomness, with their limitations on speed, if you have a primary key that's an auto-incrementer, you could do it with these two SELECT like so:

SELECT MAX(pkey) FROM articles;

...then grab a random number (shown as $r below) between 1 and max in your code. Now return back to SQL like so:

SELECT * FROM articles where pkey > $r LIMIT $limit;

...where $limit is the number of rows you want to likely return.

...Then, to create the illusion of more randomness, just use an ORDER BY clause on the second SELECT above based on something arbitrary. For instance, if 'articles' has a column like author name and another like category, you could change the SELECT statement above like:

SELECT * FROM articles where pkey > $r ORDER BY category, name LIMIT $limit;

...So, by using this strategy, it's faster than having to randomly determine your pkeys and selecting only one record at a time.

In my case, I wanted to sort classified listings with some close approximation of randomness in order to rotate the listings, and this strategy has worked for me.

Posted by Gerhard Wolkerstorfer on April 4 2008 9:55am[Delete] [Edit]

After I had problems with the ROUND() function in an accounting application where i need commercial rounding I wrote this stored function that works very well for my needs:

CREATE FUNCTION ROUND_COMMERCIAL(value DOUBLE, preci INT(11)) RETURNS DOUBLE NO SQL
RETURN TRUNCATE((value * POW(10, preci)) + (IF(value = 0, 1,(value / ABS(value)))*(0.5 * POW(1, preci*-1))), 0) / POW(10, preci);

Posted by Szot Kamil on September 23 2008 12:03pm[Delete] [Edit]

If you want to select more records randomly you can use following method:

SET @toGet=10;
SET @left=(SELECT COUNT(*) FROM tableName)+1;

SELECT *, @toGet:=@toGet-1
FROM tableName
WHERE (@left:=@left-1)>0 AND RAND()<@toGet/@left;

It's much faster than ORDER BY RAND() LIMIT 10 (especially if you want to fetch small random subset of rows stored in table) but if it happens to return same set of rows, it returns them always in same order. If you want them to have random order then you have to scramble them after fetching using subquery:

SET @toGet=10;
SET @left=(SELECT COUNT(*) FROM tableName)+1;
SELECT * FROM (
SELECT *, @toGet:=@toGet-1
FROM tableName
WHERE (@left:=@left-1)>0 AND RAND()<@toGet/@left
) t ORDER BY RAND()

or on client side.

Posted by Dave Turner on February 2 2009 9:39pm[Delete] [Edit]

Oddly truncate produces 2 different results for the same mathematical function with variations in placement of truncate in relation to a conditional:

mysql> select version(),if(2.268>1.249,truncate(ceil(((2.268-1.249)/6+.01)*100)/100,2),'0.00') as fscpm;

+------------+-------+
| version() | fscpm |
+------------+-------+
| 5.0.27-log | 0.18 |
+------------+-------+

mysql> select version(),truncate(if(2.268>1.249,ceil(((2.268-1.249)/6+.01)*100)/100,'0.00'),2) as fscpm;
+------------+-------+
| version() | fscpm |
+------------+-------+
| 5.0.27-log | 0.17 |
+------------+-------+

Posted by Matthew Flaschen on March 28 2009 7:52am[Delete] [Edit]

Nearest even rounding is not bad. In fact, it results in less statistically biased results than always rounding up.

Posted by Guy Gordon on April 18 2009 6:38pm[Delete] [Edit]

If you reached this page looking for functions like MIN(a,b,...) and MAX(a,b,...) they are named LEAST()and GREATEST(), and are in section 11.2.3. Comparison Functions and Operators.

Posted by Mike N on January 29 2011 1:12am[Delete] [Edit]

For those of you who need to implement banker's rounding in MySQL (handy if you're doing invoice reports and the numbers need to match up with accounting software like Simply Accounting that use banker's rounding), this is what I use:

CREATE DEFINER=`root`@`%` FUNCTION `BROUND`( value DECIMAL(65,30), places TINYINT(3) UNSIGNED ) RETURNS decimal(65,30) COMMENT 'WARNING over decimal(65,30) will round normally!'
DETERMINISTIC
RETURN
CASE WHEN
LOCATE( '.', value ) >= 1
AND LENGTH( SUBSTRING( value, LOCATE( '.', value ) +1 ) ) < 31
AND places > -1
AND LENGTH( value ) - LOCATE( '.', value ) > places
AND SUBSTRING( value, LOCATE( '.', value ) + places + 1, 1 ) = 5
AND SUBSTRING( value, LOCATE( '.', value ) + places + 2 ) = 0
AND SUBSTRING( value, LOCATE( '.', value ) + places + (CASE WHEN places = 0 THEN -1 ELSE 0 END ), 1 ) % 2 = 1

THEN
SUBSTRING( value, 1, LOCATE( '.', value ) + places + (CASE WHEN places = 0 THEN -1 ELSE 0 END ) )
ELSE
ROUND( value, places )
END;

WARNINGS:

- The old function I had posted here before today was wrong, to anyone who used it I am deeply sorry.

- Also do not use Felipe's function below as it is broken because a correct BROUND(6.434503,3) function should indeed return 6.435, NOT 6.434, as there is a 3 to the right of the 5. However BROUND(6.434500,3) WILL return 6.434. In banker's rounding, the only difference between regular rounding occurs when what is being rounded either ends in a 5, or ends in a 5 with a few zeroes after it. If however you do want this incorrect behaviour for some reason, you can remove "AND SUBSTRING( value, LOCATE( '.', value ) + places + 2 ) = 0" from this or use Felipe's function instead.

- Note that if you pass a value greater than 29 into my second parameter you will get regular rounding, because the DECIMAL data type has a precision of 30, and to pass anything larger than 29 in the second parameter would mean you would have gone over that limit. To avoid getting a fatal error when doing this, and for simplicity, I used strings in this function, and made it fail over to ROUND() in this instance.

- Do your own testing first of course

Posted by Felipe Loredo on November 13 2010 8:38pm[Delete] [Edit]

The BROUND posted by Mike N on March 9 2010 4:47pm doesn't works with bround(6.434503,3). The correct result is 6,435 but the function returns 6.434000000000000000000000000000.

Posted by Felipe Loredo on March 5 2011 10:17pm[Delete] [Edit]

I've created this function for Bankers rounding:

CREATE FUNCTION BankersRound(Val DECIMAL(32,16), Digits INT)
RETURNS DECIMAL(32,16)
RETURN
IF(ABS(Val - ROUND(Val, Digits)) * POWER(10, Digits+1) = 5,
IF(CONVERT(TRUNCATE(ABS(Val) * POWER(10,Digits), 0),UNSIGNED) % 2,
ROUND(Val,Digits),
TRUNCATE(Val,Digits)
),
ROUND(Val, Digits)
);

The input test was

select BankersRound(1.346,3),BankersRound(4.735500,3),BankersRound(7.834500,3),BankersRound(2.983600,3),BankersRound(6.434503,3);

and the expected result

1.346 4.736 7.834 2.984 6.435

and i got

1.3460000000000000, 4.7360000000000000, 7.8340000000000000, 2.9840000000000000, 6.4350000000000000

on MySQL 5.1.42

Posted by Mike N on January 29 2011 1:14am[Delete] [Edit]

Before today, Felipe's comment above stating that my function was broken was correct. As of 2011-01-28, it is now correct, and actually his is wrong, though his was more correct than my function before I fixed it today. See my comment above for an explanation of why this is.

Posted by Felipe Loredo on March 5 2011 10:16pm[Delete] [Edit]

I'm a bit confused. After some time thinking about your explanation and testing my function I still don't know why it's wrong. As you can see
select BankersRound(6.434503,3);
returns
6.4350000000000000
as there is a 3 to the right of the 5. So if can you help me to see why I'm wrong?

PS: Sorry for inconvenience, I don't want to be rude with you. For common purposes, for instace, if you have a decimal column (my case) you can use my version. If I'm not wrong it's probably faster. Although if you need more precision or work with bigger numbers you can use Mike's version. Finally I don't think we need to fight for this. ;-)

Sorry for the beautiful English

Posted by Károly Csabay on May 26 2011 2:51pm[Delete] [Edit]

FLOOR, when its argument is a negative, is working in a mathematic manner. While FLOOR(2.5) returns 2, FLOOR(-2.5), however, returns -3. If you feel strange this behavior use @v-MOD(@v,1) instead of FLOOR.

SET @v = - 2.5;
SELECT @v - MOD( @v , 1 ) , FLOOR( @v )

You'll gain:

@v-MOD(@v,1) FLOOR(@v)
-2.000000000000000000000000000000 -3

Posted by Christopher Rigg-Milner on October 3 2011 3:49pm[Delete] [Edit]

I had the need to do some Swedish Rounding on a value.
In order words I needed to round up or down to the nearest 5 cents.

It took me some time to work it out so I thought I would document it here in order to save somebody else the hair loss.

The basic formula was:-

ROUND( value / 5, 2 ) * 5.

My calc was a little more complex ...
ROUND( (v1 + ( v2 / 3 ) ) / 5, 2 ) * 5.

Some test result are:-

+--------+-------+------------+--------+
| v1 | v2 | simplecalc | answer |
+--------+-------+------------+--------+
| 46.25 | 24.50 | 54.416667 | 54.40 | // round down
| 46.25 | 44.05 | 60.933333 | 60.95 | // round up
| 79.15 | 24.50 | 87.316667 | 87.30 | // etc
| 79.15 | 44.05 | 93.833333 | 93.85 |
| 111.10 | 24.50 | 119.266667 | 119.25 |
| 111.10 | 44.05 | 125.783333 | 125.80 |
| 26.00 | 17.50 | 31.833333 | 31.85 |
| 45.50 | 15.50 | 50.666667 | 50.65 |
| 67.50 | 15.50 | 72.666667 | 72.65 |
| 26.00 | 31.55 | 36.516667 | 36.50 |
| 45.50 | 27.95 | 54.816667 | 54.80 |
| 67.50 | 27.95 | 76.816667 | 76.80 |
+--------+-------+------------+--------+

I was then asked to round everything UP to the nearest 5 cents.

The formula for this is:-

ROUND( ( ( v1 + ( v2 / 3 ) + 0.03 ) ) / 5, 2 ) * 5

+--------+-------+------------+--------+
| v1 | v2 | simplecalc | answer |
+--------+-------+------------+--------+
| 46.25 | 24.50 | 54.416667 | 54.45 |
| 46.25 | 44.05 | 60.933333 | 60.95 |
| 79.15 | 24.50 | 87.316667 | 87.35 |
| 79.15 | 44.05 | 93.833333 | 93.85 |
| 111.10 | 24.50 | 119.266667 | 119.30 |
| 111.10 | 44.05 | 125.783333 | 125.80 |
| 26.00 | 17.50 | 31.833333 | 31.85 |
| 45.50 | 15.50 | 50.666667 | 50.70 |
| 67.50 | 15.50 | 72.666667 | 72.70 |
| 26.00 | 31.55 | 36.516667 | 36.55 |
| 45.50 | 27.95 | 54.816667 | 54.85 |
| 67.50 | 27.95 | 76.816667 | 76.85 |
+--------+-------+------------+--------+

I do hope this helps somebody.

Posted by G Henle on May 7 2012 5:30pm[Delete] [Edit]

Note: While CONV(N, from_base, to_base) does accept a string for N and returns a string. The return is still limited to type unsigned/signed bigint.

SET @N:= CAST(SHA1(RAND()) AS CHAR);
SELECT @N, CONV(@N, 16, 10), ~0 as max_bigint_unsigned;

+------------------------------------------+----------------------+----------------------+
| @N | CONV(@N, 16, 10) | max_bigint_unsigned |
+------------------------------------------+----------------------+----------------------+
| 36cf9111723dba5bb0fe6e91465323d1390f252c | 18446744073709551615 | 18446744073709551615 |
+------------------------------------------+----------------------+----------------------+
1 row in set (0.00 sec)