使用MySQL数据库的人，毫无例外的在设计时都会碰到主键的选型，一般都会在下面三种中选择一个或多个，自增长列、UUID以及UUID_SHORT，这集中主键的特性，想必大家都非常了解了，我就不再细说了，在InnoDB引擎中，选择哪种主键更好，网上也有很多帖子有描述，基本上都是建议是自增长列或者搭配UUID作为逻辑主键一起使用，但是如果是ndbcluster引擎呢？

      为此我专门做了一下测试，环境为4台物流机器（2C，8G内存）做的数据节点，NoOfReplicas=2，首先建立三张表。

CREATE TABLE `int_key` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `cname` varchar(36) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=ndbcluster AUTO_INCREMENT=1 DEFAULT CHARSET=latin1;

/*Table structure for table `uuid_key` */

CREATE TABLE `uuid_key` (
  `uuid` varchar(32) NOT NULL,
  `cname` varchar(36) DEFAULT NULL,
  PRIMARY KEY (`uuid`)
) ENGINE=ndbcluster DEFAULT CHARSET=latin1;

/*Table structure for table `uuid_short_key` */

CREATE TABLE `uuid_short_key` (
  `id_short` bigint(20) unsigned NOT NULL,
  `cname` varchar(36) DEFAULT NULL,
  PRIMARY KEY (`id_short`)
) ENGINE=ndbcluster DEFAULT CHARSET=latin1;

建三个存储过程循环分别插入1000万条记录

INSERT INTO int_key (cname) VALUES (UUID());

INSERT INTO uuid_key (UUID, cname) VALUES (REPLACE(UUID(),‘-‘,‘‘),UUID());

INSERT INTO uuid_short_key (id_short, cname) VALUES (uuid_short(), UUID());

这三种主键的表在数据插入时耗时有差异，uuid_short_key表速度最快，最先插入完毕，它插完时，uuid_key表插入了986万条记录，差不多，但是int_key表就慢了，只插入了651万条记录，因此可以认为自增长列主键的表在大数据高并发插入的场景下不占优势。

下面再测试查询的速度：

SELECT COUNT(0) FROM int_key;
SELECT COUNT(0) FROM uuid_short_key;
SELECT COUNT(0) FROM uuid_key;

统计记录数速度都非常快，毫秒级返回结果

SELECT * FROM int_key WHERE id = 418606;
SELECT * FROM uuid_short_key WHERE id_short = 23786248796730416;
SELECT * FROM uuid_key WHERE `uuid` = ‘666cd86c9bbc11e4a819005056a877bb‘;

按主键查询速度也都非常快，毫秒级返回结果

SELECT * FROM int_key WHERE cname = ‘34007ecb-9b06-11e4-a819-005056a877bb‘;
SELECT * FROM uuid_short_key WHERE cname = ‘321c7290-9b89-11e4-a819-005056a877bb‘;
SELECT * FROM uuid_key WHERE cname = ‘666cd882-9bbc-11e4-a819-005056a877bb‘;

安非主键且无索引字段查询测试，我总共每个sql各查了20次，20次耗费的总时间为，第一个是96.12秒，第二个为96.10秒，第三个为101.14秒，可以看到前两张表的查询耗时基本一致 ，而最后一张要慢一些，可能跟uuid所占用的空间比数值型栏位大有关。

从测试结果来看，在基于ndbcluster引擎的MySQL集群中，使用uuid_short作为表的主键，无论在读写上都是最好的选择，以上仅代表本次测试结果反馈观点，供大家参考！

MySQL集群数据库表的主键设计