MySQL Partitioning: why it's not taking appropriate partition

          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

Answers (1)

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

Related Questions