Comments on: COUNT(*) for Innodb Tables

By: SELECT COUNT(*) sehr langsam - php.de

SELECT COUNT(*) sehr langsam - php.de — Tue, 08 Sep 2009 15:47:38 +0000

[...] Zählen für MySQL kein Problem ist. Selbst bei 8 Mio. Zeilen. übliches work-around sind trigger bei INSERT/DELETE mit einer zusätzlichen tabelle. __________________ AC/DC Fanpage ifyouwantblood.de (Stewie [...]

By: peter

peter — Wed, 26 Aug 2009 16:16:59 +0000

SC,

Note these stats are approximate.

By: SC

SC — Wed, 26 Aug 2009 15:14:23 +0000

If your table has a primary key, you can also get the count from
show index from , the cardinality of the key will give you count of the rows in the table.

By: Cloudspace - A Cool Little Company's Thoughts, News, Happenings

Cloudspace - A Cool Little Company's Thoughts, News, Happenings — Thu, 06 Aug 2009 14:57:03 +0000

[...] never contain a NULL value, and tell MySQL to ‘use index (index_name)’. Also, thanks to Wallace, who commented on the MySQL Performance Blog Share and [...]

By: Wallace

Wallace — Fri, 03 Apr 2009 11:40:55 +0000

Why the performance gap?

Running this slow query took 138 seconds (2 min 18.09 sec)
SELECT COUNT(*) FROM dbmail_messageblks;
+———-+
| COUNT(*) |
+———-+
| 262788 |
+———-+
1 row in set (2 min 18.09 sec)

After optimizing the SQL, it took 0.27 seconds.
SELECT COUNT(*) FROM dbmail_messageblks use index(physmessage_id_index);
+———-+
| COUNT(*) |
+———-+
| 262796 |
+———-+
1 row in set (0.27 sec)

> SHOW CREATE TABLE dbmail_messageblks\G
*************************** 1. row ***************************
Table: dbmail_messageblks
Create Table: CREATE TABLE `dbmail_messageblks` (
`messageblk_idnr` bigint(21) NOT NULL auto_increment,
`physmessage_id` bigint(21) NOT NULL default ‘0′,
`messageblk` longblob NOT NULL,
`blocksize` bigint(21) NOT NULL default ‘0′,
`is_header` tinyint(1) NOT NULL default ‘0′,
PRIMARY KEY (`messageblk_idnr`),
KEY `physmessage_id_index` (`physmessage_id`),
KEY `physmessage_id_is_header_index` (`physmessage_id`,`is_header`),
CONSTRAINT `dbmail_messageblks_ibfk_1` FOREIGN KEY (`physmessage_id`) REFERENCES `dbmail_physmessage` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=602519 DEFAULT CHARSET=utf8

> EXPLAIN SELECT COUNT(*) FROM dbmail_messageblks\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: dbmail_messageblks
type: index
possible_keys: NULL
key: PRIMARY
key_len: 8
ref: NULL
rows: 1930308
Extra: Using index

> EXPLAIN SELECT COUNT(*) FROM dbmail_messageblks use index(physmessage_id_index)\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: dbmail_messageblks
type: index
possible_keys: NULL
key: physmessage_id_index
key_len: 8
ref: NULL
rows: 1930310
Extra: Using index

By: nop

nop — Tue, 17 Feb 2009 01:28:46 +0000

correction: replace “8 seconds” with “5 minutes, 8 seconds”.

By: nop

nop — Tue, 17 Feb 2009 01:18:53 +0000

ready for a headache? try “select count($field) from $table;” and compare the time it takes to “select count($field) from $table use index($field);”
($field is the primary key (int autoincrement) in $table which was converted from myisam and has around 900k rows in it).

for me, the standard count without use index takes around 8 seconds – the count with forced index takes below 0.1 seconds.

any thoughts on why this is so?

By: Fekke

Fekke — Sun, 21 Dec 2008 05:26:57 +0000

3,000 records may be a problem. If you have three tables with 1,000 records each and you do a join involving the three tables with no indexes at all then you would have 1,000,000,000 records full scan to fetch the results.

So the optimization you acquire by creating the proper indexes not only relies on how many records your tables have but also what your queries are.

By: peter

peter — Sun, 20 Jul 2008 16:04:46 +0000

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.

By: Ries van Twisk

Ries van Twisk — Fri, 18 Jul 2008 14:33:22 +0000

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