Comments on: To SQL_CALC_FOUND_ROWS or not to SQL_CALC_FOUND_ROWS?

By: Roy N

Roy N — Tue, 07 Feb 2012 13:41:27 +0000

PS: the query was fairly complex with a couple of joins (all indexed) despite not being extremely large. the datasets returned were about 100 – 500 matches on average, and the main table <100k rows. innodb.

By: Roy N

Roy N — Tue, 07 Feb 2012 13:40:00 +0000

I just deployed sql_calc_rows on a high traffic large server (16gb ram ssd, yada yada, high availability setup with multiple slaves, etc) and it completely brought the server to its knees… select tables were running for hundreds of seconds “copying data into tmp table” or something like that…

in our pre-production tests, time for access was much better, but under load it could not perform unfortunately…

back to using double queries…

By: Scott Noyes

Scott Noyes — Fri, 07 Oct 2011 17:00:33 +0000

I just repeated the test shown here (except that I got bored and killed the initial set of INSERTs at 8M instead of 10M). After warming up the cache, I get 0.06 seconds for the SQL_CALC_FOUND_ROWS approach, and 0.02 seconds for the COUNT(*) approach. The EXPLAIN plans are identical.

By: Paul

Paul — Tue, 08 Mar 2011 08:39:36 +0000

Hello,

I tried the SQL_CALC_FOUND_ROWS/FOUND_ROWS query method vs the select/count() query method, both using WHERE … LIKE ‘%…%’ , ORDER BY, and LIMIT X,Y on a real table with ~72,000 entries (MYISAM).

Result: The SQL_CALC_FOUND_ROWS/FOUND_ROWS method is 90% faster than the select/count() method in this case!

By: Vili

Vili — Wed, 28 Jul 2010 09:01:21 +0000

On a table with about 5 million rows (average row length is 71, engine: MyISAM) these are my measurements:

17.000s – SELECT SQL_CALC_FOUND_ROWS * FROM tab WHERE id>600000 LIMIT 10000
00.100s – SELECT * FROM tab WHERE id>600000 LIMIT 10000

02.250s – SELECT SQL_CALC_FOUND_ROWS * FROM tab WHERE id<600000 LIMIT 10000
00.100s – SELECT * FROM tab WHERE id<600000 LIMIT 10000

00.062s – SELECT SQL_CALC_FOUND_ROWS * FROM tab LIMIT 10000
00.062s – SELECT * FROM tab LIMIT 10000

The primary `id` field is INT(10) UNSIGNED NOT NULL AUTO_INCREMENT.

If there is a WHERE the SCFR is slowing down the query.
But the time difference between id… is also remarkable.

By: zeojex

zeojex — Mon, 28 Jun 2010 14:01:45 +0000

For a current project that i need to optimize, i use SQL_CALC_FOUND_ROWS.
I did some tests too and this solution was faster than using 2 queries even if i use appropriate indexes.
But my query are complex : 10 table-relations, almost 10 conditions in where clause, with group by and limit…so a very bad query !
You probably right on your test because you use simple query…??
I will do other tests to be sure.

Thx from france !

By: Peter Lieverdink

Peter Lieverdink — Wed, 26 May 2010 09:00:56 +0000

I’ve noticed for some time that I actually get opposite results to what the blog suggests. Running two queries is pretty much never faster than SQL_CALC_FOUND_ROWS when I use it.

I’ve run a bunch of benchmarks, and on larger datasets it’s pretty much twice as fast as COUNT(*) and then a SELECT.

http://cafuego.net/2010/05/26/fast-paging-real-world

By: Daniel

Daniel — Fri, 02 Apr 2010 14:29:07 +0000

Hi.

FYI, in my benchmarks it’s about 50% faster to SELECT “null” instead of “*” if you just want to do a FOUND_ROWS():

SELECT /*! SQL_CALC_FOUND_ROWS */ NULL FROM aaa LIMIT 0 UNION ALL SELECT NULL FROM bbb LIMIT 0
instead of
SELECT /*! SQL_CALC_FOUND_ROWS */ * FROM aaa LIMIT 0 UNION ALL SELECT * FROM bbb LIMIT 0;

and then
SELECT FOUND_ROWS();

By: Jim Heng

Jim Heng — Mon, 08 Mar 2010 09:42:04 +0000

Agree with Nadeem

If you are using SELECT SQL_CALC_FOUND_ROWS, MySQL must calculate how many rows are in the full result set. However, this is faster than running the query again without LIMIT, because the result set need not be sent to the client.

By: Nadeem

Nadeem — Tue, 23 Feb 2010 20:06:29 +0000

I’m agree with “Matt” comment, yes actually SQL_COUNT_FOUND_ROWS use when someone required result + paging with single query in associative array so this always make a good sense to use SQL_COUNT_FOUND_ROWS otherwise COUNT(field with Key) use to take the result of your desire.

Hope this contribute!