Reputation: 253
DROP TABLE temp;
CREATE TABLE `temp` (
`CallID` bigint(8) unsigned NOT NULL,
`InfoID` bigint(8) unsigned NOT NULL,
`CallStartTime` datetime NOT NULL,
`PartitionID` int(4) unsigned NOT NULL,
KEY `CallStartTime`(`CallStartTime`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
PARTITION BY HASH (PartitionID)
PARTITIONS 366
I use EXPLAIN in a sample query I get the next result:
EXPLAIN PARTITIONS SELECT * FROM temp where PartitionID = 1
or
EXPLAIN PARTITIONS SELECT * FROM temp where PartitionID = DAYOFYEAR('2013-01-01 10:24:00')
result:
id select_type table partitions type possible_keys key key_len ref rows Extra
1 SIMPLE temp p1 ALL 2 Using where
I don't know why it's using the p1 partition. Here parititon start with p0
Upvotes: 2
Views: 95
Reputation: 253
The HASH partitioning scheme means MySQL translates your arbitrary numerical value into its own hash value. You have defined 366 partitions. What do you think would happen if your query were:
EXPLAIN PARTITIONS SELECT * FROM temp where PartitionID = 400 ?
Your PartitionID cannot mean in this case the real partition's ID/name, since there is no partition 400.
Now, just between the two of us, you might be interested to learn that MySQL's HASHing function is a simple modulus. Thus, 0 maps to partition p0, 1 maps to partition p1, and 400 maps to partition 34 (== 400-366).
Generally speaking you should not be too interested in the identify of the particular partition being used. You should be more interested to know that there is a good balance of partitions.
If the balance doesn't seem right to you, you might consider using the KEY partitioning scheme, where the hashing algorithm is based on a checksum function, which means values are more "randomly" spread as compared to the HASH modulus partitioning scheme.
Upvotes: 1