Question

We are running MySQL/ISAM database with a following table:

create table measurements (
  `tm_stamp` int(11) NOT NULL DEFAULT '0',
  `fk_channel` int(11) NOT NULL DEFAULT '0',
  `value` int(11) DEFAULT NULL,
  PRIMARY KEY (`tm_stamp`,`fk_channel`)
);

The tm_stamp–fk_channel combination is required unique, hence the compound primary key. Now, for certain irrelevant reason, the database will be migrated to InnoDB engine. Upon googling something about it, i found out that the key will dictate the physical ordering of the data on the disk. 90% of the queries currently go as follows:

SELECT value FROM measurements
WHERE fk_channel=A AND tm_stamp>=B and tm_stamp<=C
ORDER BY tm_stamp ASC

Inserts are 99% in order of tm_stamp, it’s a storage for dataloggers network. The table has low millions of rows but growing steadily. The questions are

1. Should the sole change of storage engine result in any significant performance change, better or worse?
2. Does the order of columns in the index matter with regards to the most popular SELECT? This blog suggest something along that line.
3. Thanks to the nature of clustered index, may we perhaps leave out the ORDER BY clause and gain some performance?

Answer 1

Edit 1:

It appears that changing the primary key from

PRIMARY KEY (`tm_stamp`,`fk_channel`)

to

PRIMARY KEY (`fk_channel`,`tm_stamp`)

always makes sense, for both MyISAM and InnoDB. See http://sqlfiddle.com/#!2/0aa08/1 for proof this is so.

Original answer:

To determine if changing

PRIMARY KEY (`tm_stamp`,`fk_channel`)

to

PRIMARY KEY (`fk_channel`,`tm_stamp`)

would improve your query’s performance, you need to determine which field’s values cardinality is higher (which field’s values are more varied). Running

SELECT COUNT(DISTINCT tm_stamp), COUNT(DISTINCT fk_channel) FROM measurements;

will give you the cardinality of the columns.

So, to answer your question properly we first need to know: What are the common range of values between B and C? 60? 3,600? 86,400? more?

For example, let’s say that

SELECT COUNT(DISTINCT tm_stamp), COUNT(DISTINCT fk_channel) FROM measurements;

returns 32,768 and 256. 32,768 divided by 256 is 128. This tells us that tm_stamp has 128 unique values for every value of fk_channel.

So if the difference between B and C is usually less than 128, then leave tm_stamp as the first field in the primary key. If 128 or greater, then make fk_channel the first field.

Another question: Does fk_channel need to be an INT (4 billion unique values, half of which are negative)? If not, then changing fk_channel to TINYINT UNSIGNED (if you have 256 unique values), or SMALLINT UNSIGNED (65536 unique values) would save a lot of time and space.

For example, let’s say you have 256 maximum possible fk_channel values, and 65,536 possible values, then you could change your schema via:

create table measurements_new (
  tm_stamp INT UNSIGNED NOT NULL DEFAULT '0',
  fk_channel TINYINT UNSIGNED NOT NULL DEFAULT '0', -- remove UNSIGNED if values can be negative
  value SMALLINT UNSIGNED DEFAULT NULL, -- remove UNSIGNED if values can be negative
  PRIMARY KEY (tm_stamp,fk_channel)
) ENGINE=InnoDB
SELECT
  tm_stamp,
  fk_channel,
  value
FROM
  measurements
ORDER BY
  tm_stamp,
  fk_channel;

RENAME TABLE measurements TO measurements_old, measurements_new TO measurements;

This will store the existing data in the new table in PRIMARY KEY order, which will improve performance somewhat.