views:

672

answers:

3

I have a table that essentially looks like this:

CREATE TABLE myTable (
    id INT auto_increment,
    field1 TINYINT,
    field2 CHAR(2),
    field3 INT,
    theDate DATE,
    otherStuff VARCHAR(20)
    PRIMARY KEY (id)
    UNIQUE KEY (field1, field2, field3)
)

I'd like to partition the table based on the month and year of theDate, however the manual is telling me I'm not allowed:

All columns used in the partitioning expression for a partitioned table must be part of every unique key that the table may have. In other words, every unique key on the table must use every column in the table's partitioning expression

What are my options here? Can I still partition the table?

A: 

No, not in the current form.

You could remove the primary key and instead just make "id" a normal index. The secondary unique index would still be a problem and you would need to remove this or change the partitioning scheme to involve theDate column.

Harrison Fisk
what a massive PITA. :-(
nickf
A: 

If you are partitioning based on the year and month of a datetime column, have you thought about having a table for each year-month combo and then using a merge table? I know this doesn't directly answer your question, but thought it may help...

Lytol
Hi Lytol, I had considered that, however I'd heard that they're actually slower than just having one large table. Do you have any insights?
nickf
+1  A: 

I wrote a blog post about this issue here Scaling Rails with MySQL table partitioning (rails uses integer PKs). The same technique should work in your case, except, unfortunately you have to drop the [field1, field2, field3] unique key.

Dropping a unique key was a problem I dealt with too (though not mentioned in the post). I worked around it by implemented an existence check before creating the record, realizing that we'd still get occasional dupes due to the race condition. In practice, that didn't turn out to be a problem. However, the increased query throughput required scaling up the innodb buffer size 'cause the i/o's we're brutal.

spidaman
thanks for the insights.
nickf