We’re using XtraDB(InnoDB by Percona) tables (version 5.5.14-rel20.5-log), this is a web-mail system that stores all messages in a table, so it is fairly good sized.

I did a simple count(*) on the messages table:

mysql> select count(*) from messages;
+———-+
| count(*) |
+———-+
| 2849204 |
+———-+
1 row in set (5.82 sec)

I did this a dozen times and it came back at around 6 seconds each time.

Then I counted the primary key:
mysql> select count(id) from messages;
+———–+
| count(id) |
+———–+
| 2849205 |
+———–+
1 row in set (6.05 sec)

Basically the same results, even after a dozen iterations. (this is a production system so the count will increase).

Then I counted a column that is a key from another table, not null :

mysql> desc messages;
+—————+————–+——+—–+———+—————-+
| Field | Type | Null | Key | Default | Extra |
+—————+————–+——+—–+———+—————-+
| id | bigint(20) | NO | PRI | NULL | auto_increment |
| id_acct | int(11) | NO | MUL | 0 | |

mysql> select count(id_acct) from awm_messages;
+—————-+
| count(id_acct) |
+—————-+
| 2849213 |
+—————-+
1 row in set (3.40 sec)

Each time, right around 3.5 seconds. I’m not sure if this is just more efficient for InnoDB/XtraDB, or if it’s due to the difference in field type (bigint vs int).

Note these stats are approximate.

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

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?

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.