<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: COUNT(*) for Innodb Tables</title>
	<atom:link href="http://www.mysqlperformanceblog.com/2006/12/01/count-for-innodb-tables/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.mysqlperformanceblog.com/2006/12/01/count-for-innodb-tables/</link>
	<description>Everything about MySQL Performance</description>
	<pubDate>Sun, 07 Sep 2008 07:48:22 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: peter</title>
		<link>http://www.mysqlperformanceblog.com/2006/12/01/count-for-innodb-tables/#comment-331977</link>
		<dc:creator>peter</dc:creator>
		<pubDate>Sun, 20 Jul 2008 16:04:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2006/12/01/count-for-innodb-tables/#comment-331977</guid>
		<description>Ries, Kishore

Indeed 3000 records is very small unless these are 10MB faxes stored directly in the database :)   Wrong indexing or query which MySQL can't optimize well is likely reason.  If you report the EXPLAIN on our forums we might be able to help.</description>
		<content:encoded><![CDATA[<p>Ries, Kishore</p>
<p>Indeed 3000 records is very small unless these are 10MB faxes stored directly in the database <img src='http://www.mysqlperformanceblog.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' />   Wrong indexing or query which MySQL can&#8217;t optimize well is likely reason.  If you report the EXPLAIN on our forums we might be able to help.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ries van Twisk</title>
		<link>http://www.mysqlperformanceblog.com/2006/12/01/count-for-innodb-tables/#comment-330847</link>
		<dc:creator>Ries van Twisk</dc:creator>
		<pubDate>Fri, 18 Jul 2008 14:33:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2006/12/01/count-for-innodb-tables/#comment-330847</guid>
		<description>to Kishore.

I you need to read upon SQL, usage of indexes etc. 3000 records is nothing for any DB and shouldn't be slow in any case.
Most likely your DB is not properly normalized and you don't have proper indexes.

Ries</description>
		<content:encoded><![CDATA[<p>to Kishore.</p>
<p>I you need to read upon SQL, usage of indexes etc. 3000 records is nothing for any DB and shouldn&#8217;t be slow in any case.<br />
Most likely your DB is not properly normalized and you don&#8217;t have proper indexes.</p>
<p>Ries</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kishore</title>
		<link>http://www.mysqlperformanceblog.com/2006/12/01/count-for-innodb-tables/#comment-317431</link>
		<dc:creator>Kishore</dc:creator>
		<pubDate>Wed, 25 Jun 2008 05:54:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2006/12/01/count-for-innodb-tables/#comment-317431</guid>
		<description>Dear Friends,
I am getting headache with MySql. I am new to .net and MYSQl.
At present lots of Issues occured in MySql ...but the problem is slow..
"Whenever We are executing the Query it is taking lot'z of time to execute. Our tables contains nearly 3000 records..."
How can I optimize the Stored procedures..
(or)
How can I change this Sp into faster manner...
"Thanks In advance"</description>
		<content:encoded><![CDATA[<p>Dear Friends,<br />
I am getting headache with MySql. I am new to .net and MYSQl.<br />
At present lots of Issues occured in MySql &#8230;but the problem is slow..<br />
&#8220;Whenever We are executing the Query it is taking lot&#8217;z of time to execute. Our tables contains nearly 3000 records&#8230;&#8221;<br />
How can I optimize the Stored procedures..<br />
(or)<br />
How can I change this Sp into faster manner&#8230;<br />
&#8220;Thanks In advance&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Swapceinski</title>
		<link>http://www.mysqlperformanceblog.com/2006/12/01/count-for-innodb-tables/#comment-283794</link>
		<dc:creator>John Swapceinski</dc:creator>
		<pubDate>Sun, 20 Apr 2008 18:20:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2006/12/01/count-for-innodb-tables/#comment-283794</guid>
		<description>If you want a quick and dirty count of the number of rows in a InnoDB table, this seems to work:

explain select count(*) from Table;

The result is fast and will give you a "rows" count that should be within 10% of the number of rows in the Table.  So it seems the row count is being cached SOMEWHERE (I don't know where).  BTW, I am using MySQL v5.0.45.</description>
		<content:encoded><![CDATA[<p>If you want a quick and dirty count of the number of rows in a InnoDB table, this seems to work:</p>
<p>explain select count(*) from Table;</p>
<p>The result is fast and will give you a &#8220;rows&#8221; count that should be within 10% of the number of rows in the Table.  So it seems the row count is being cached SOMEWHERE (I don&#8217;t know where).  BTW, I am using MySQL v5.0.45.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Technocation, Inc.</title>
		<link>http://www.mysqlperformanceblog.com/2006/12/01/count-for-innodb-tables/#comment-166496</link>
		<dc:creator>Technocation, Inc.</dc:creator>
		<pubDate>Wed, 12 Sep 2007 02:31:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2006/12/01/count-for-innodb-tables/#comment-166496</guid>
		<description>&lt;strong&gt;OurSQL Episode 2: Wild Performance Tips...&lt;/strong&gt;

...</description>
		<content:encoded><![CDATA[<p><strong>OurSQL Episode 2: Wild Performance Tips&#8230;</strong></p>
<p>&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: GSIY &#8230; Ruby-Rails Portal</title>
		<link>http://www.mysqlperformanceblog.com/2006/12/01/count-for-innodb-tables/#comment-163866</link>
		<dc:creator>GSIY &#8230; Ruby-Rails Portal</dc:creator>
		<pubDate>Wed, 05 Sep 2007 16:00:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2006/12/01/count-for-innodb-tables/#comment-163866</guid>
		<description>[...] of transactions, foreign keys and other niceties, you might be aware of its limitations, like much slower count(*). Our DBAs are in a constant lookout for slow queries in production and the ways to keep DBs happy [...]</description>
		<content:encoded><![CDATA[<p>[...] of transactions, foreign keys and other niceties, you might be aware of its limitations, like much slower count(*). Our DBAs are in a constant lookout for slow queries in production and the ways to keep DBs happy [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: kiran</title>
		<link>http://www.mysqlperformanceblog.com/2006/12/01/count-for-innodb-tables/#comment-156096</link>
		<dc:creator>kiran</dc:creator>
		<pubDate>Wed, 15 Aug 2007 09:24:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2006/12/01/count-for-innodb-tables/#comment-156096</guid>
		<description>How to find the top values of table row?</description>
		<content:encoded><![CDATA[<p>How to find the top values of table row?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John</title>
		<link>http://www.mysqlperformanceblog.com/2006/12/01/count-for-innodb-tables/#comment-136742</link>
		<dc:creator>John</dc:creator>
		<pubDate>Mon, 18 Jun 2007 05:14:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2006/12/01/count-for-innodb-tables/#comment-136742</guid>
		<description>I am seeing a query take up to 2 seconds (viewing the listing of members in my site) because at the top there's a count.  What steps can I take to speed this up? I've thought about doing a quick count total cache stored in a separate field, but that won't work either, because depending on the search criteria, the count number can change at any time.</description>
		<content:encoded><![CDATA[<p>I am seeing a query take up to 2 seconds (viewing the listing of members in my site) because at the top there&#8217;s a count.  What steps can I take to speed this up? I&#8217;ve thought about doing a quick count total cache stored in a separate field, but that won&#8217;t work either, because depending on the search criteria, the count number can change at any time.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: puRe aka Marcel Oelke &#187; MySQL Performance: Use counter tables</title>
		<link>http://www.mysqlperformanceblog.com/2006/12/01/count-for-innodb-tables/#comment-101630</link>
		<dc:creator>puRe aka Marcel Oelke &#187; MySQL Performance: Use counter tables</dc:creator>
		<pubDate>Tue, 03 Apr 2007 11:16:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2006/12/01/count-for-innodb-tables/#comment-101630</guid>
		<description>[...] I guess many of you know, that using SELECT count(*) FROM table is problematic and slow when using Innodb tables. This actually only applies to COUNT(*) queries without WHERE a clause as mentioned in the MySQL Performance Blog. [...]</description>
		<content:encoded><![CDATA[<p>[...] I guess many of you know, that using SELECT count(*) FROM table is problematic and slow when using Innodb tables. This actually only applies to COUNT(*) queries without WHERE a clause as mentioned in the MySQL Performance Blog. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: peter</title>
		<link>http://www.mysqlperformanceblog.com/2006/12/01/count-for-innodb-tables/#comment-25642</link>
		<dc:creator>peter</dc:creator>
		<pubDate>Thu, 28 Dec 2006 12:40:50 +0000</pubDate>
		<guid isPermaLink="false">http://www.mysqlperformanceblog.com/2006/12/01/count-for-innodb-tables/#comment-25642</guid>
		<description>Sean, 

The question in this case is semantics.  SELECT COUNT(*)  must return accurate value by standards, There is no way it would be made to return wrong data by default as this may break some application. So  we're speaking about option which will need to be specified such as inaccurate_count=1 ?    Still not everyone will be able to use it because single instance can be shared by multiple applications.    Having  Some form of SQL FLAG, such as  SELECT APPROXIMATE COUNT(*) would be better but will require application changes and at the same time one could use info from SHOW TABLE STATUS.</description>
		<content:encoded><![CDATA[<p>Sean, </p>
<p>The question in this case is semantics.  SELECT COUNT(*)  must return accurate value by standards, There is no way it would be made to return wrong data by default as this may break some application. So  we&#8217;re speaking about option which will need to be specified such as inaccurate_count=1 ?    Still not everyone will be able to use it because single instance can be shared by multiple applications.    Having  Some form of SQL FLAG, such as  SELECT APPROXIMATE COUNT(*) would be better but will require application changes and at the same time one could use info from SHOW TABLE STATUS.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
