Comments on: The Secret of SQL_CALC_FOUND_ROWS http://www.michikono.com/2007/08/07/the-secret-of-sql_calc_found_rows/ Stuff only Michi cares to read Sun, 22 Jan 2012 10:48:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Tim http://www.michikono.com/2007/08/07/the-secret-of-sql_calc_found_rows/#comment-15123 Tim Thu, 21 Jan 2010 17:59:39 +0000 http://www.michiknows.com/2007/08/07/the-secret-of-sql_calc_found_rows/#comment-15123 btw: LIMIT 2,1 will return the third row, not the second row. btw: LIMIT 2,1 will return the third row, not the second row.

]]> By: Nick http://www.michikono.com/2007/08/07/the-secret-of-sql_calc_found_rows/#comment-15119 Nick Tue, 19 Jan 2010 05:17:16 +0000 http://www.michiknows.com/2007/08/07/the-secret-of-sql_calc_found_rows/#comment-15119 This is not "definitely faster" than using count(*). In fact, when I tried it, the result was many times slower than the original two queries combined. From the comments on http://dev.mysql.com/doc/refman/5.0/en/information-functions.html Posted by Wade Bowmer on May 14 2006 11:40pm Be aware that using SQL_CALC_FOUND_ROWS and FOUND_ROWS() disables ORDER BY ... LIMIT optimizations (see bugs http://bugs.mysql.com/bug.php?id=18454 and http://bugs.mysql.com/bug.php?id=19553). Until it's fixed, you should run your own benchmarks with and without it. This is not “definitely faster” than using count(*). In fact, when I tried it, the result was many times slower than the original two queries combined.

From the comments on http://dev.mysql.com/doc/refman/5.0/en/information-functions.html
Posted by Wade Bowmer on May 14 2006 11:40pm
Be aware that using SQL_CALC_FOUND_ROWS and FOUND_ROWS() disables ORDER BY … LIMIT optimizations (see bugs http://bugs.mysql.com/bug.php?id=18454 and http://bugs.mysql.com/bug.php?id=19553). Until it’s fixed, you should run your own benchmarks with and without it.

]]> By: Michi http://www.michikono.com/2007/08/07/the-secret-of-sql_calc_found_rows/#comment-6858 Michi Wed, 08 Aug 2007 16:05:34 +0000 http://www.michiknows.com/2007/08/07/the-secret-of-sql_calc_found_rows/#comment-6858 of course. but in many cases, knowing a general total is "good enough." facebook did this. even google does this. in cases where knowing the exact total in a constantly changing table is a requirement, you would obviously avoid this solution. however, in a 40 million record result set for a search, being off one or two is no big deal. however, reducing subsequent page loads (after the caching) from 5 minutes down to 0.2 seconds IS a big deal. of course. but in many cases, knowing a general total is “good enough.” facebook did this. even google does this. in cases where knowing the exact total in a constantly changing table is a requirement, you would obviously avoid this solution. however, in a 40 million record result set for a search, being off one or two is no big deal. however, reducing subsequent page loads (after the caching) from 5 minutes down to 0.2 seconds IS a big deal.

]]> By: jason http://www.michikono.com/2007/08/07/the-secret-of-sql_calc_found_rows/#comment-6814 jason Wed, 08 Aug 2007 12:17:21 +0000 http://www.michiknows.com/2007/08/07/the-secret-of-sql_calc_found_rows/#comment-6814 Correct me if I'm wrong, but in relation to Ben's question about safety: if you do cache the total number of rows in the URL you need to be careful in instances where other users might be making submissions to the database. That could cause a scenario where user A's session thinks there are a total of 100 rows, but user B just added 10 more. If user A is viewing all of those records with a paginated navigation, that there's the potential for conflicts and you'd need to plan/code accordingly. Correct me if I’m wrong, but in relation to Ben’s question about safety: if you do cache the total number of rows in the URL you need to be careful in instances where other users might be making submissions to the database. That could cause a scenario where user A’s session thinks there are a total of 100 rows, but user B just added 10 more. If user A is viewing all of those records with a paginated navigation, that there’s the potential for conflicts and you’d need to plan/code accordingly.

]]> By: Michi http://www.michikono.com/2007/08/07/the-secret-of-sql_calc_found_rows/#comment-6706 Michi Tue, 07 Aug 2007 23:55:10 +0000 http://www.michiknows.com/2007/08/07/the-secret-of-sql_calc_found_rows/#comment-6706 It is safe. It is session specific. "session" means for a single connection instance (such as a page load). It does not persist, and it is not shared (unless you are using connection pooling). You "flush" it by making a new SELECT query statement. From the MySQL documentation: "In the absence of the SQL_CALC_FOUND_ROWS option in the most recent SELECT statement, FOUND_ROWS() returns the number of rows in the result set returned by that statement." It is safe. It is session specific. “session” means for a single connection instance (such as a page load). It does not persist, and it is not shared (unless you are using connection pooling).

You “flush” it by making a new SELECT query statement. From the MySQL documentation:

“In the absence of the SQL_CALC_FOUND_ROWS option in the most recent SELECT statement, FOUND_ROWS() returns the number of rows in the result set returned by that statement.”

]]> By: Ben Cornwell http://www.michikono.com/2007/08/07/the-secret-of-sql_calc_found_rows/#comment-6688 Ben Cornwell Tue, 07 Aug 2007 21:49:24 +0000 http://www.michiknows.com/2007/08/07/the-secret-of-sql_calc_found_rows/#comment-6688 Sounds interesting, but how safe is it? Can it be realistically relied upon where you have more than one user accessing the db? Does the calculated value persist between different and/or subsequent connections? Also, how do you flush the value when you change the where clause? Sounds interesting, but how safe is it? Can it be realistically relied upon where you have more than one user accessing the db? Does the calculated value persist between different and/or subsequent connections?

Also, how do you flush the value when you change the where clause?

]]>