Comments on: To SQL_CALC_FOUND_ROWS or not to SQL_CALC_FOUND_ROWS? http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/ Everything about MySQL Performance Sat, 21 Nov 2009 14:15:21 -0800 http://wordpress.org/?v=2.8.4 hourly 1 By: Prasanna http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/comment-page-1/#comment-661064 Prasanna Fri, 02 Oct 2009 14:38:01 +0000 http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/#comment-661064 One question or may be suggestion - count(*) will be slower than count(primary_key). What you think? One question or may be suggestion – count(*) will be slower than count(primary_key). What you think?

]]> By: Ani http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/comment-page-1/#comment-651968 Ani Sat, 12 Sep 2009 12:31:42 +0000 http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/#comment-651968 Hello, I would like to state a simple point here. Please visit the mysql official documentation here http://dev.mysql.com/doc/refman/5.1/en/information-functions.html Please have a look at FOUND_ROWS() function. They have mentioned that it is much faster to use the query with sql_calc_found_rows rather than using a query again. And I don't find any reason not to trust them. Ani Hello,

I would like to state a simple point here. Please visit the mysql official documentation here http://dev.mysql.com/doc/refman/5.1/en/information-functions.html

Please have a look at FOUND_ROWS() function. They have mentioned that it is much faster to use the query with sql_calc_found_rows rather than using a query again. And I don’t find any reason not to trust them.

Ani

]]> By: ibrahim oğuz http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/comment-page-1/#comment-651637 ibrahim oğuz Fri, 11 Sep 2009 09:09:30 +0000 http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/#comment-651637 select count(*) from users group by city for this query if you use count this not will give you true result. in this case you have to use mysql_num_rows or SQL_CALC_FOUND_ROWS , mysql_num_rows runs very slow. we have only one option it is SQL_CALC_FOUND_ROWS. if any one have a solution let me know? thanks. select count(*) from users group by city
for this query if you use count this not will give you true result. in this case you have to use mysql_num_rows or SQL_CALC_FOUND_ROWS , mysql_num_rows runs very slow. we have only one option it is SQL_CALC_FOUND_ROWS.

if any one have a solution let me know?

thanks.

]]> By: WordPress still uses the nasty SQL_CALC_FOUND_ROWS « _ck_ says… http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/comment-page-1/#comment-614390 WordPress still uses the nasty SQL_CALC_FOUND_ROWS « _ck_ says… Wed, 22 Jul 2009 18:44:38 +0000 http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/#comment-614390 [...] is typically three times slower than using COUNT() on the same query without LIMIT and ORDER [...] [...] is typically three times slower than using COUNT() on the same query without LIMIT and ORDER [...]

]]> By: Baron Schwartz http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/comment-page-1/#comment-601627 Baron Schwartz Wed, 01 Jul 2009 01:06:01 +0000 http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/#comment-601627 I think the comments on this blog can be answered with "your mileage may vary." In the "real world" I have seen severe performance degradation many times. I'm sure there are cases where it doesn't degrade performance, and I don't notice because I'm looking at what IS the performance problem on a server. I think the comments on this blog can be answered with “your mileage may vary.” In the “real world” I have seen severe performance degradation many times. I’m sure there are cases where it doesn’t degrade performance, and I don’t notice because I’m looking at what IS the performance problem on a server.

]]> By: Menno http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/comment-page-1/#comment-601288 Menno Tue, 30 Jun 2009 18:43:46 +0000 http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/#comment-601288 I found that when doing complex multitable selects, SQL_CALC_FOUND_ROWS adds virtually no extra execution time to the query. Like Brian said, the example mentioned in this blog post is about as far from a real world scenario as possible. I found that when doing complex multitable selects, SQL_CALC_FOUND_ROWS adds virtually no extra execution time to the query.
Like Brian said, the example mentioned in this blog post is about as far from a real world scenario as possible.

]]> By: 关于用SQL实现分页的一个优化方法 | 鸭嘴的blog http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/comment-page-1/#comment-554849 关于用SQL实现分页的一个优化方法 | 鸭嘴的blog Sun, 03 May 2009 14:31:57 +0000 http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/#comment-554849 [...] To SQL_CALC_FOUND_ROWS or not to SQL_CALC_FOUND_ROWS? 事实证明，当查询语句中的WHERE和ORDER的条件有合适的索引，选择两次查询而不是SQL_CALC_FOUND_ROWS [...] [...] To SQL_CALC_FOUND_ROWS or not to SQL_CALC_FOUND_ROWS? 事实证明，当查询语句中的WHERE和ORDER的条件有合适的索引，选择两次查询而不是SQL_CALC_FOUND_ROWS [...]

]]> By: Brian http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/comment-page-1/#comment-512986 Brian Fri, 20 Mar 2009 02:50:35 +0000 http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/#comment-512986 In my case COUNT(*) was the hog that's been driving my search slow, and SQL_CALC_FOUND_ROWS saved me, and like george suggests I've been using ORDER BY, JOIN, not some childish case like the one presented here. In my case COUNT(*) was the hog that’s been driving my search slow, and SQL_CALC_FOUND_ROWS saved me, and like george suggests I’ve been using ORDER BY, JOIN, not some childish case like the one presented here.

]]> By: george http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/comment-page-1/#comment-490258 george Thu, 26 Feb 2009 12:58:31 +0000 http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/#comment-490258 Could you please repeat this test with a proper case featuring 2x JOIN, a WHERE clause, a GROUP_BY, and an ORDER_BY, please? my point is, your test is most probably misleading. Could you please repeat this test with a proper case featuring 2x JOIN, a WHERE clause, a GROUP_BY, and an ORDER_BY, please?
my point is, your test is most probably misleading.

]]> By: Marcyes / benchmarking Counting Rows in MySQL for Pagination http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/comment-page-1/#comment-482232 Marcyes / benchmarking Counting Rows in MySQL for Pagination Thu, 19 Feb 2009 10:54:50 +0000 http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/#comment-482232 [...] up to date reliably.So I did what any self-respecting programmer does and turned to Google. I found some interesting info on the subject of getting row counts, including some optimizations that I felt [...] [...] up to date reliably.So I did what any self-respecting programmer does and turned to Google. I found some interesting info on the subject of getting row counts, including some optimizations that I felt [...]

]]>