100W 数据量，数据库主键选择

[steelshadow39]

本人学生，没有大型项目开发经验。问题描述如下，请教各位前辈。

1. 数据描述：
   • 可能作为主键的两个属性示例：
     1. cpeName": "cpe:2.3:a:3com:3cdaemon:-:::::::*",
     2. cpeNameId": "BAE41D20-D4AF-4AF0-AA7D-3BD04DA402A7"
   • 数据量：100W 左右
2. 数据库选用 MySQL ，innodb

我的想法是：cpeName 字段太长了，不适合作为主键； cpeNameid 和 UUID 差不多，作为索引查找和插入效率都很低。因为查询数据时绝大多数情况都会以 cpeName 作为查询条件，所以如果以自增 ID 作为主键，基本上很少用到 ID ，而且自增 ID 和其他列毫无关联关系，最终还是需要在 cpeName 上建索引。

感谢各位前辈指点。

[liprais]

100w 随便选

[iOCZ]

主键用哪个取决于搜索需求吧

[yinmin]

正解：jiq yi gy 长整型自增字段做主健，其他字段可做索引

[yinmin]

正解：添加一个长整型自增字段做主健，其他字段可做索引

[steelshadow39]

@iOCZ 是的，cpeName 还能保证数据唯一性，其他常用的搜索字段都无法保证数据唯一性

[igeeky]

如果 cpeName 没有范围查询需求, 也不会用 LIKE 进行查询, 可以用 hash 索引. 这样索引会小很多.
MYSQL 是支持 hash 类型的索引的.
如果数据库不支持 hash 索引, 你也可以自己用 cpeName 的 hash(比如 mmhash, crc64 等)作为主键. 这样查询时,只要自己 hash 一下, 再用 hash 值查询就行.

[steelshadow39]

@igeeky 好的，谢谢

[steelshadow39]

@yinmin 如果我用自增主键，再给 cpeName 添加索引，那么相比直接把 cpeName 作为主键索引，不是更浪费空间了吗？

[esee]

100 万的数据量?你索引都不加性能也不会差,除非在你用的 20 年前的机器来跑数据库。
提个建议，如果是自己做着玩的项目，好的想法和需求 比编码能力更重要，做产品第一步是做出来且有人用，不然搞再好的性能 其实意义并不大

[ytmsdy]

才 100w 而已。搞一个数字自增的主键就好了。

[yinmin]

@steelshadow39 主健索引一般是给其他表做 join 关联引用的。你可以 2 选 1 （ 1 ）添加一个自增长整数 （ 2 ）把 cpenameid 转换成 16 字节二进制格式保存到数据库，然后做主健。2 种方案的效率都不错的。

[yinmin]

mysql 有 UUID_TO_BIN()函数可以直接处理 cpenameid ，转换成 BIN 后效率会很高的

[makelove]

@steelshadow39 万一你的表有别的索引呢，其它索引会用主键当指针指回数据行，你的主键搞这么大会导致这个表的所有索引体积都大很多，不利于保持在内存

[wangyongbo]

你可以先用 自增 ID 做主键测试一下性能看看。 做个实验就知道了。

[cabing]

单个字段查询，把需要索引的字段 md5 以下。以这个 md5 作为索引？

100w 真的是很少了。随便玩都行。。

[Belmode]

使用 MySQL 自增字段作为主键，那两个业务字段做索引就行了。
500W 数据基本无压力。

[fzdwx]

主键最好是递增的数字类型且与业务无关

[IvanLi127]

这个数据量，不想纠结就直接加个 id 字段

[CQdake]

@makelove #13 说得对，是哈。
使用 cpeNmae 做主键的缺点：
①主键太大，性能就降低了；
②cpeName 不是自增的，数据的前后顺序是随机存放的，每一次增删都需要调整很多条数据，自增主键，直接按顺序在末尾添加就好了；

[steelshadow39]

明白了，先用自增 ID 试了，谢谢大家