15 messages in com.mysql.lists.clusterRe: Will I have a runaway primary key...
FromSent OnAttachments
Jayson Larose04 Dec 2006 08:41 
mizi...@aim.com04 Dec 2006 09:20 
Jayson Larose04 Dec 2006 11:03 
Kevin Burton04 Dec 2006 13:28 
Adam Dixon04 Dec 2006 14:55 
Kevin Burton04 Dec 2006 15:23 
Jayson Larose04 Dec 2006 16:21 
Anatoly Pidruchny04 Dec 2006 17:23 
Kevin Burton04 Dec 2006 19:04 
Jayson Larose04 Dec 2006 20:51 
Anatoly Pidruchny04 Dec 2006 21:09 
mizi...@aim.com05 Dec 2006 08:56 
mizi...@netscape.net05 Dec 2006 09:10 
Stewart Smith12 Dec 2006 19:44 
Stewart Smith12 Dec 2006 19:46 
Subject:Re: Will I have a runaway primary key problem in the future if I do this?
From:Adam Dixon (adam@gmail.com)
Date:12/04/2006 02:55:41 PM
List:com.mysql.lists.cluster

Hi,

I have a table without a PK, which does about 5-10 inserts per second,

1) Am I going to have a table that hits its INT (or BIGINT, or whatever) max sometime in the future without periodic table rebuilding, even if there are only 10,000 or so rows in the table due high INSERT/DELETE volume and autoincrement?

In NDB at least, tables without a PK will automatically get a BIGINT UNSIGNED column (pretty sure although its not specifically mentioned in the manual to be a BIGINT) which is a maximum of 18,446,744,073,709,551,615. (or lots)

2) I read that MySQL cluster performs partitioning by default on the primary key. Would there be any performance hit due to this "wandering primary key", like having all your data winding up on one NDB node?

I can say that my particular table with about 32million rows is lightning quick (obviously with correct indexes) Cluster certainly achieved the speed and scalability we needed because of this table.

Regards Adam