Opened 14 years ago
Last modified 41 minutes ago
#18836 assigned enhancement
ORDER BY RAND() is slow
Reported by: | Owned by: | ||
---|---|---|---|
Milestone: | 6.9 | Priority: | normal |
Severity: | minor | Version: | |
Component: | Query | Keywords: | early has- has-test-info dev-feedback |
Focuses: | performance | Cc: |
Description (last modified by )
WP_Query currently accepts 'orderby' => 'rand' which translates to ORDER BY RAND().
This is very slow when you have many posts, since it effectively calls RAND() for each row.
A faster way would be to call RAND() only once and put it in the LIMIT clause.
The only thing is that we have to make sure that the generated number is smaller than (total number of posts - number of posts to fetch).
So, this would require to do an extra query to calculate the total. It should still be faster than the current method.
If we want to get more than one post, we can get them in any order and then call shuffle() on the resulting array.
Attachments (1)
Change History (35)
#7
@
11 years ago
- Keywords needs-unit-tests added
- Milestone changed from Awaiting Review to Future Release
A for this would be fun.
#8
@
10 years ago
Tests with MySQL EXPLAIN shows no creation of temporary tables. The execution time with ~900 posts is also 2-3 times faster.
I ran the standard phpunit tests - no additional error was found.
#11
@
10 years ago
Looks like your got missed, MisdaX. Sorry about that.
Can we confirm which unit tests cover the ORDER BY RAND()
functionality please? Not that it's really very testable, but still.
#12
@
10 years ago
It is indeed difficult. I tried to reduce the impact of the as best as I can. I tested a vanilla wordpress and a ed wordpress with the whole unit test package to ensure that I broke nothing.
I assumed that there are tests which cover the ordering part of the function. No change in the result of the unit tests was a sign for me that everything should be ok. Unfortunately I have no idea how I can provide a suitable test for a random order functionality :-)
Independently, it would be nice if someone could provide a performane test with a big database.

This ticket was mentioned in โPR #6241 on โWordPress/wordpress-develop by โ@pbearne.
14 months ago #13
- Keywords has-unit-tests added; needs-unit-tests removed
This update modifies the 'test_orderby' function assertion to accommodate expected 'rand()' value in the SQL query request. An additional unit test 'test_wp_query_orderby_rand' is also introduced to verify that the 'orderby' => 'rand' parameter provides seemingly random results upon multiple requests.
Trac ticket: 18836
#14
@
14 months ago
- Keywords has- removed
- Owner set to pbearne
- Status changed from new to assigned
Hi
I created a test to check we get a random order.
but the code provided in the did not provide a random order so more work is needed.

This ticket was mentioned in โSlack in #core-performance by pbearne. โView the logs.
14 months ago

This ticket was mentioned in โSlack in #core by audrasjb. โView the logs.
3 months ago
#20
@
3 months ago
- Milestone changed from 6.8 to 6.9
As per today's bug scrub: It's a bit late in the release cycle to introduce Query/DB changes, so I'm moving it to 6.9 with the early
keyword.
Please note that there is a WPCS issue in the current PR.

This ticket was mentioned in โSlack in #core-performance by adamsilverstein. โView the logs.
7 weeks ago
#23
@
7 weeks ago
We discussed this today in the Performance bug scrub and the question came up: is this still true: "ORDER BY RAND() is slow" or has this issue been resolved already?
#25
@
3 weeks ago
I've passed my WP-Query benchmarking template and here are the results:
These are the 3 queries benchmarked in a pool of 10K posts, $post_per_page
= 1K, 10 iterations each
new WP_Query([
'post_type' => 'post',
'posts_per_page' => $posts_per_page,
'orderby' => 'rand',
'no_found_rows' => true,
'cache_results' => false
]);
new WP_Query([
'post_type' => 'post',
'posts_per_page' => $posts_per_page,
'orderby' => 'date',
'order' => 'DESC',
'no_found_rows' => true,
'cache_results' => false
]);
new WP_Query([
'post_type' => 'post',
'posts_per_page' => $posts_per_page,
'orderby' => 'title',
'order' => 'DESC',
'no_found_rows' => true,
'cache_results' => false
]);
Tomorrow I will be checking the new implementation pushed by @pbearne to see if it actually improves the rand implementation and create a proper testing report.
#26
@
3 weeks ago
- Keywords changes-requested added; needs-testing has-unit-tests has- removed
Combined Issue Reproduction and Test Report
Description
โ This report can't validate that the indicated works as expected.
tested: โhttps://.com/WordPress/wordpress-develop/pull/6241.diff
Environment
- WordPress: 6.9-alpha-60093-src
- PHP: 8.4.6
- Server: nginx/1.27.5
- Database: mysqli (Server: 8.4.5 / Client: mysqlnd 8.4.6)
- Browser: Chrome 135.0.0.0
- OS: Windows 10/11
- Theme: Twenty Twenty-Five 1.2
- MU Plugins: None activated
- Plugins:
- Test Reports 1.2.0
- WQROC 1.0.0
- WP Query Benchmarking 1.0.0
Expected Results with
- Random sort works.
- Benchmark indicates improvement.
Actual Results
- โ Random sort fails with the
- โ There is a slight performance improvement
Additional Notes
There are some things wrong with this :
- Firstly, as shown here, there is no randomization with this :
Before (without ): โhttps://streamable.com/p6mjct
After (with ): โhttps://streamable.com/dnf6ob
- Secondly, as we can see in the screenshots attached, the performance is slightly improved.
- Third, the unit test is always returning OK because it's technically not checking for randomized queries adequately. Ideally, it should generate a ton more posts because with such little size: 10 interactions for only 3 units. In case that the unit test was right, it could be triggering false asserts once in a while in the automated protocol (i.e. Actions). This could be awful because people, unrelated to this , could go crazy trying to figure out why this test actually failed for them on an unrelated topic, so minimizing or completely ditching this is ideal in this case. Apart to that, as I say, the test itself wrong because it triggers and fully breaks too early.
- Finally, there are already some unit tests aimed to
orderby
rand liketest_orderby()
so this new test could be, moreover, redundant.
Further research on this algorithm is required.
Supplemental Artifacts
- Without the : โhttps://i.imgur.com/0RPY1sg.png
- With the : โhttps://i.imgur.com/uREFVyH.png
#27
@
3 weeks ago
- Keywords close added
Adding more beef to the grill, I completely forgot the most obvious testโฆ number of queries
This is without any modifications, just bare queries like the mentioned here
After all this testing, I'm starting to think that this ticket is completely obsolete by now.
With all this info provided, I would add this as a candidate for close
โ wont-fix
#28
@
3 weeks ago
- Keywords close removed
After hour and a half trying to understand โthe algorithm, I think I've come with a solution with the idea that @scribu was suggesting one decade ago, and I think I got it.
The performance gains are important:
I'm still double-checking the code, but I will provide a tomorrow, just wanted to remove the close
proposal because maybe there is an opportunity for optimization here.
Test Demo: โhttps://streamable.com/m5iklq

This ticket was mentioned in โPR #8715 on โWordPress/wordpress-develop by โ@SirLouen.
3 weeks ago #29
- Keywords has- added
Brief Testing Info Ideas
- First you might need to publish a lot of posts. The more, the better, 10 for example
- Use a Query like:
$query = new WP_Query([ 'posts_per_page' => 10, 'fields' => 'ids', 'post_status' => 'publish', 'orderby' => 'ID', 'order' => 'ASC' ]);
- And fix the result (because you need to check if future WP_Queries return the same order or not)
$fixed_ids = $query->posts;
- Finally we generate another WP_Query, but this time with the
orderby
andrand
for the exact same posts we got previously. Do this multiple times, check generation order to see if there is some sort of randomness in each generation.
$query = new WP_Query([
'post__in' => $fixed_ids,
'posts_per_page' => 10,
'orderby' => 'rand',
'post_status' => 'publish',
'ignore_sticky_posts' => true,
'fields' => 'ids',
]);
- For the performance part, use
microtime
andget_num_queries()
accompanied bydefine( 'SAVEQUERIES', true );
Trac ticket: https://core.trac.wordpress.org/ticket/18836
#30 follow-up: โ 31
@
3 weeks ago
- Keywords has-testing-info dev-feedback added; changes-requested removed
Note that I have ignored the unit-tests because there are already unit-test for orderby rand in ::test_orderby()
#31 in reply to: โ 30
@
3 weeks ago
Replying to SirLouen:
Note that I have ignored the unit-tests because there are already unit-test for orderby rand in
::test_orderby()
Good work @SirLouen
No, let's get this in core
#32
@
3 days ago
Testing Instructions Improved
- Use this plugin in a new clean environment: โhttps://.com/SirLouen/wp-query-benchmarking-v2
- First generate 10K posts to have a populated DB
- Run the performance tests with and without the .
You are welcome to review and improve the plugin to add more test cases or improve the mock data.
Here's a method of doing it all in a single query:
โhttp://explainextended.com/2009/03/01/selecting-random-rows/
Not sure how feasible it would be for WP.