100W 数据量,数据库主键选择
本人学生,没有大型项目开发经验。问题描述如下,请教各位前辈。
数据描述:
可能作为主键的两个属性示例:
cpeName": "cpe:2.3:a:3com:3cdaemon:-:::::::*",
cpeNameId": "BAE41D20-D4AF-4AF0-AA7D-3BD04DA402A7"
数据量:100W 左右
数据库选用 MySQL ,innodb
我的想法是:cpeName 字段太长了,不适合作为主键; cpeNameid 和 UUID 差不多,作为索引查找和插入效率都很低。因为查询数据时绝大多数情况都会以 cpeName 作为查询条件,所以如果以自增 ID 作为主键,基本上很少用到 ID ,而且自增 ID 和其他列毫无关联关系,最终还是需要在 cpeName 上建索引。
感谢各位前辈指点。
100w 随便选
主键用哪个取决于搜索需求吧
正解:jiq yi gy 长整型自增字段做主健,其他字段可做索引
正解:添加一个长整型自增字段做主健,其他字段可做索引
是的,cpeName 还能保证数据唯一性,其他常用的搜索字段都无法保证数据唯一性
如果 cpeName 没有范围查询需求, 也不会用 LIKE 进行查询, 可以用 hash 索引. 这样索引会小很多.MYSQL 是支持 hash 类型的索引的. 如果数据库不支持 hash 索引, 你也可以自己用 cpeName 的 hash(比如 mmhash, crc64 等)作为主键. 这样查询时,只要自己 hash 一下, 再用 hash 值查询就行.
好的,谢谢
如果我用自增主键,再给 cpeName 添加索引,那么相比直接把 cpeName 作为主键索引,不是更浪费空间了吗?
100 万的数据量?你索引都不加性能也不会差,除非在你用的 20 年前的机器来跑数据库。提个建议,如果是自己做着玩的项目,好的想法和需求 比编码能力更重要,做产品第一步是做出来且有人用,不然搞再好的性能 其实意义并不大
才 100w 而已。搞一个数字自增的主键就好了。
主健索引一般是给其他表做 join 关联引用的。你可以 2 选 1 ( 1 )添加一个自增长整数 ( 2 )把 cpenameid 转换成 16 字节二进制格式保存到数据库,然后做主健。2 种方案的效率都不错的。
mysql 有 UUID_TO_BIN()函数可以直接处理 cpenameid ,转换成 BIN 后效率会很高的
万一你的表有别的索引呢,其它索引会用主键当指针指回数据行,你的主键搞这么大会导致这个表的所有索引体积都大很多,不利于保持在内存
你可以先用 自增 ID 做主键测试一下性能看看。 做个实验就知道了。
单个字段查询,把需要索引的字段 md5 以下。以这个 md5 作为索引?100w 真的是很少了。随便玩都行。。
使用 MySQL 自增字段作为主键,那两个业务字段做索引就行了。500W 数据基本无压力。
主键最好是递增的数字类型且与业务无关
这个数据量,不想纠结就直接加个 id 字段
#13 说得对,是哈。使用 cpeNmae 做主键的缺点:①主键太大,性能就降低了;②cpeName 不是自增的,数据的前后顺序是随机存放的,每一次增删都需要调整很多条数据,自增主键,直接按顺序在末尾添加就好了;
明白了,先用自增 ID 试了,谢谢大家
下面是我这段时间来收集的一些有意思的东西。本站这样的文章还很多,如这个,这个,这个。 Javascript Garden,这是学习Javascript最好的网站了。http:/…
我想,大家在上网的时候一定见过很多很多种各式各样的网站导航条的设计。这些导航条基本上来说都是用CSS来做的。这里,我们将向你介绍几种最不错的用CSS设计的网站导航条。希望你会喜…
本来炉石传说国服回归是不打算玩的,但是看到国服开服第五天大部分玩家还是不能正常进行,有点想吃瓜了,该不会国服特供版本改出的 bug 是动了屎山代码,打开了潘多拉魔盒吧。 开猿…