I prefer to prepare the datasets first, and not depend on the order of evaluation (which you may fail to predict correctly): select * from some_table join (select rand() as random_id) on some_table.the_id = random_id This way it is obvious that rand() will be evaluated only once.
If the intent is actually to select one, and only one, random row from the table than this Stack Overflow entry has a result that is in most cases in the direction I was thinking (LIMIT 1, and have some way of selecting a random entry, remembering that the ID field might be monotonic, but isn't assured to be continuous (have no gaps))
https://stackoverflow.com/questions/19412/how-to-request-a-r...
Unfortunately it seems that it depends on language extensions that are not portable.
EDIT:
It unfortunately also appears that the easiest query scales poorly to large tables as it works by assigning EACH row a random ID and then limiting it to one of those by some order (probably lowest assigned row).
A more effective approach might be a function or procedure based around a pre-recorded 'maximum' ID for the column (assuming it's vaguely monotonic and not a GUID), picking a random result between base and that ID, Verifying it exists, and if it doesn't trying again up to N times before using a fallback procedure. (E.G. after 100 random stabs that fail selecting ~500 records in the range of lastRND +/- 250 and using the ORDER BY rand() or equivalent on that sub-set). If even /that/ fails pick the next or previous record by which is closest.