that's very much gonna depend on what your selects look like. For example, a low-cardinality but often-where'd field makes an interesting candidate, as such a partitioning will take the size of your table scans down. If you know that you'll mostly access just last month's data, partition on year+month.
YMMV. On Mon, Feb 22, 2010 at 11:23 PM, Jerry Schwartz <jschwa...@the-infoshop.com > wrote: > I’d like to know your opinions about partitioning the following table. > Here’s the relevant snippet: > > > > Create Table: CREATE TABLE `prod_price` ( > > `prod_price_id` varchar(15) NOT NULL DEFAULT '', > > `prod_id` varchar(15) DEFAULT NULL, > > … > > PRIMARY KEY (`prod_price_id`), > > KEY `prod_id` (`prod_id`) > > ) ENGINE=MyISAM DEFAULT CHARSET=utf8 > > > > Here’s the deal. The primary key, `prod_price_id`, is rarely used. Prices, > as you might expect, are fetched by `prod_id`. Both keys are randomly > generated strings. (Before you ask, I am not a mental health professional > and am therefore not qualified to judge my predecessor.) > > > > How could I partition this table in a useful way? > > > > Regards, > > > > Jerry Schwartz > > The Infoshop by Global Information Incorporated > > 195 Farmington Ave. > > Farmington, CT 06032 > > > > 860.674.8796 / FAX: 860.674.8341 > > > > <http://www.the-infoshop.com> www.the-infoshop.com > > > > -- Bier met grenadyn Is als mosterd by den wyn Sy die't drinkt, is eene kwezel Hy die't drinkt, is ras een ezel
