Mysql 数据库需不需要主键 Id？

理论上当然可以不需要自增 ID 当主键，但是实际这么操作会被人打的

万一有两个人都是叫“张三”，同时 20 岁，咋办

另外用非自增 ID 做主键，会增加随机写入的概率，insert 操作性能会降低

如果同名同岁怎么办...

这是学生的毕业设计才会出现的情况吧。
没有主键，怎么非常明确简单的定位一条数据？
写 sql，查找删除的时候，估计多谢几次就像打人了

同意，这是典型没有经验的设计体现，或者说压根没有设计。

我觉得唯一的可能就是为了防止名字重复，设计者为了偷懒不在后端验证，直接数据库禁止。
比如注册时提交的姓名重复，一般做法是先 select 数据库判断重复，再插入。它这样可以省去查询这一步，直接 insert，失败成功一目了然。
而为什么要把 A 表分离出来，也是为了查询性能。有好有坏吧，主要看网站业务。
另外 A 表应该不会加 age 字段，只会加不常修改的。

@fancy111 防止重复弄成唯一键就好了, 主键 id 还是不能省的.

问题非常大。。
更新岁数，物理删除数据，同名怎么办，除非你告诉我这个不用更新岁数和不删除

@Jooooooooo 既然用不到 ID，那当然可以省。

@fancy111 #7 数据库层面的防止重复可以用 unique index i_name_age(name, age)

这就是瞎搞，鉴定完毕

@littleylv 就是这么用啊，那省掉 ID 有问题吗？ ID 在业务上用不到。

不一定需要自增主键
但以 name + age 作为联合主键是谁出的馊主意... ... 你至少给我用个身份证号，手机号什么的吧

要,而且主键不要与业务关联

别的不提，真在数据库里面用 age ？每年改一次？

@fancy111 自增主键对于 MySQL InnoDB 来说，插入性能和空间利用率更高。另外，如果要更新 name 或 age，更新主键比更新非主键效率低

@fancy111 #13 表面上来看当然没问题，作为简单的系统设计省掉 id 当然没问题
不过，你可以试试下次在你的工作里这么设计表试试，我看看你同事打不打你

肯定要啦，不然编辑更新删除问题很大，新增插入倒没啥

@littleylv 这里只是举个例子，实际不是这个表
@Uyuhz

大学生水平的人写的

非自增的主键插入时一定要检查是否唯一，这个损失就洗不了。

@ytmsdy 唉，反正现在数据库里面大部分都是这种设计，也有极少部分是有 id 的，估计不是一个人写的，木已成舟

不说 id，看到 age 就被吓哭了...这一定是被外在和内在因素影响深思熟虑挣扎出来的结果！

@loading
@littlewing 只是举个例子，实际不是这张表

一般情况下，表是需要一个 ID 字段标识唯一一条数据记录，这个 ID 不一定跟业务发生关联。

@littlewing 自增主键对于 MySQL InnoDB 来说，插入性能和空间利用率更高？ 你想当然是吗？谁告诉你自增插入性能高？
更新的话我已经说了，这个表肯定不会这样设计。

@littleylv 看清楚我的回答，我并没说这个设计就好。数据库的设计本身就是跟项目结合的，哪个性能好选哪个。搞编程的思维都这么死板的话没啥发展前途。

你举得例子叫业务主键（只不过你举得例子不好），自增的 ID 是逻辑主键。

做数仓的一般比较倾向于业务主键，应用系统的喜欢逻辑主键。

设计良好的使用业务主键的系统，看上去真舒服！！！

@fancy111 自增主键保证 insert 数据能够顺序写入，这样说没什么问题

@heyjei 额，怎么说呢，这个业务确实不是什么 Web 应用，偏内部系统，但是有一部分内容需要白屏化，所以涉及到一些增删改查，没有 id 主键确实头疼

不用主键 ID, 会让 mysql 插入的时候进行随机写入排序，毕竟 B-tree 索引是按顺序存储的， 而且以后也不利于运用到聚簇索引和覆盖索引啊。 除非你用的不是 innodb 引擎，而是其他的

@wangbenjun5 你可以试着去接受业务主键，特别是这种业务复杂的内部系统，用着用着就会发现真香。。

自增的 ID，CRUD 方便了，但是要想理解业务，就蒙圈了，而且还特容易产生脏数据。

主键还是要的。

看起来像是把 mysql 当成 mongo 在用了, 这样做的好处就是查询快吧, 比如我查 B 表的时候就直接可以知道对应的 name 而不是要和 A 表关联一次才知道 name

mysql 的 innodb 是必须的，其他的数据库可以建议，我个人只对 MySQL 比较了解，供你参考：
InnoDB 引擎表是基于 B+树的索引组织表；
InnoDB 会选择主键作为聚集索引、如果没有显式定义主键，则 InnoDB 会选择第一个不包含有 NULL 值的唯一索引作为主键索引；
数据记录本身被存于主索引（一颗 B+Tree ）的叶子节点上。这就要求同一个叶子节点内（大小为一个内存页或磁盘页）的各条数据记录按主键顺序存放，因此每当有一条新的记录插入时，MySQL 会根据其主键将其插入适当的节点和位置，如果页面达到装载因子（ InnoDB 默认为 15/16 ），则开辟一个新的页（节点）

如果表使用自增主键，那么每次插入新的记录，记录就会顺序添加到当前索引节点的后续位置，当一页写满，就会自动开辟一个新的页；

如果使用非自增主键（如果身份证号或学号等），由于每次插入主键的值近似于随机，因此每次新纪录都要被插到现有索引页得中间某个位置，此时 MySQL 不得不为了将新记录插到合适位置而移动数据，甚至目标页面可能已经被回写到磁盘上而从缓存中清掉，此时又要从磁盘上读回来，这增加了很多开销，同时频繁的移动、分页操作造成了大量的碎片，得到了不够紧凑的索引结构，后续不得不通过 OPTIMIZE TABLE 来重建表并优化填充页面；

以上是《高性能 MySQL 》中的原话

大概意思就是：InnoDB 表的数据写入顺序能和 B+树索引的叶子节点顺序一致的话，这时候存取效率是最高的，而主键可能不是递增关系时(例如字符串、UUID、多字段联合唯一索引的情况)，该表的存取效率就会比较差。

所以一般 mysql 又用 innodb 的情况下一律加上自增 id，如果你说的两个表，B 表是 A 表的附属表，B 表的 ID 可以不设置自增，直接存 A 表的 ID 作为主键即可

大部分的情况下是需要的 id 作为 primary key 的.如果表是 inodb 引擎的话,他是通过主键聚集数据的, 通过联合索引做主键,会增加 mysql 插入数据的时间,而且索引更大.而且会导致页分裂和碎片话.

@fancy111 瞎搞, 扩展性什么的完全不考虑. 之后要往外扔数据也用 name+age 当实体标记别人会用奇怪的眼神看你的

大学生都不这么写，别黑我们大学生...

遵循数据库范式到哪个程度 业务简单的话都行 如果业务比较复杂设计的人出来谢罪

可以不用主键。
但是不用主键的时候，聚集索引列的设置一定要合理。

另外会引发某些其他问题：例如 EF 对无主键表不能自动代码生成

看我的使用案例（虽然是 SQL server ）： https://www.opengps.cn/Blog/View.aspx?id=284&from=v2ex

复合主键其实设计上，在很多业务中是最优解（ lz 这个当然不合适）。但确实容易出性能问题，我觉得和 mysql 本身不优化性能过烂也不无关系……

开心就好

可以试试不要 痛过才知道香

小项目无所谓，多人项目要做好被喷的准备。

你这是在瞎搞！

主键和业务相关，问题很多。

@heyjei 你那是数据宽表，基本不会做修改删除操作。

我碰到过没有主键的...

阿里巴巴《 Java 开发手册》

[强制]
表必备三字段：id, create_time, update_time。

说明：
其中 id 必为主键，类型为 bigint unsigned、单表时自增、步长为 1。
create_time, update_time 的类型均为 datetime 类型



https://github.com/alibaba/p3c/blob/master/%E9%98%BF%E9%87%8C%E5%B7%B4%E5%B7%B4Java%E5%BC%80%E5%8F%91%E6%89%8B%E5%86%8C%EF%BC%88%E5%8D%8E%E5%B1%B1%E7%89%88%EF%BC%89.pdf

典型的小学生
好奇写法

而且代码变量名还能用中文呢， 没想到吧.jpg

@tabris17 #27 你的理解完全反了，顺序主键提高的是 select 效率，但降低 insert 效率。随机写入不需要寻址，不需要考虑重复、乱序、并发等问题，明显要比顺序写入快。

@wangbenjun5 你的理解也反了，单列（字段）主键，从来都不是数据库设计或者数据库范式的要求，而是程序业务设计或者性能优化（更多的是后者）的要求，数据库范式甚至都没要求必须有主键。业务设计上要求单字段主键也是被逼无奈的被动要求。不管是为了识别还是关联，对象总得有 ID ；单字段 ID 明显比多字段复合 ID 舒服多了； ID 不能轻易修改：所以业务设计就给了个不成熟的规范：对象必须有一个业务无关的单字段 ID。这个规范有一个缺点，不是多了个字段，而是对象原本业务相关的自然 ID 被掩盖掉了。总归来说，加一个业务无关 ID，优点大于缺点，所以这个规范就这么用下来了。但是要记住这是程序设计规范，不是数据库设计规范。

@littleylv 不要局限于这个例子

@xiaowangge #44 一刀切 /懒政规范，就别搬出来了，徒让人笑话。举几个例子：用户表的主键叫做 user_id 是不是违反规范；是用 create_time 同时表示注册时间和记录创建时间，还是用 register_time、create_time 分别表示注册时间、记录创建时间；历史记录类型数据只插入不更新，放个 update_time 字段是不是脱裤子放屁。

不想要主键的人，想啥呢

@tant 补充一点，如果没有显示定义自增 id，会自动选择第一个不含空值的唯一索引当主键。但是这个也没有的时候，MySQL 应该会自动生成一个隐藏的自增字段当主键

@passerbytiny 抱歉，你的理解才是有问题的。

我才你可能是想说顺序写入在高并发的情况下会引发热点造成性能问题。
排除这种极端情况，随机写入导致的拆分页操作才是真正的性能灾难

@loading age 难道不是每天一次

复合主键也是主键，也挺常用，比如用在关联表中。
只是在你这里的 name+age 不适合而已。

innodb 没有主键，插入速度慢。

逻辑上没问题，表小当然可以这么玩。自增主键的好处是插入的时候是顺序的。

@assad 其实楼主举的例子不恰当，之前做过的项目，一些关联表，确实没有主键，确实拿的就是两个字段合并做一个的，业务表里面，我见过，比如省份名字, province_name,city_name,postcode，各种关联， 确实没有主键，还有一种就是设计工资等级，比如 1W-2W 是 A 级别，2-3WB 级，这样的。。。当时做项目好奇，但是还是不建议这么做，检索的时候，性能那叫一个垃圾。

@fancy111 31 楼的 tant 已经解释的非常清楚了，你可以参考

@passerbytiny 你也别出来回复了，徒让人笑话。

@passerbytiny innodb 在插入数据的时候本身就是有序的，所以才需要创建一个自增 id，否则每次新增一个记录都需要做移动数据，页分裂等操作，缓存空间中的数据也需要频繁更新。

@loading 哈哈，我就干过数据库加 age，还有出生年月也在。而且身份证号码还能重复。
反正产品发话了，我就不管了

联合主键一般是别的表的主键联合起来用，不是你上面的这个场景

没有主键 mysql 内部也会给你创建一个~

@tabris17 #50 @Lonely #56 两位这是做过什么事，@我是没提醒的。

至于 tabris17 你的回复，你的目光局限到了 InnoDB 引擎上面。热点问题那可不是极端情况，在大数据存储上可是首要问题，关系数据库上热点问题仍然存在，只不过数据量小的时候无需关注罢了，数据量一大照样得使用表分区来避免热点。InnoDB 引擎下若真因为非顺序主键拆分页造成性能灾难，那主因是 InnoDB 引擎而不是顺序主键，难不成 InnoDB 引擎要告诉所有人“我太娇贵，那些用 UUID 当主键的我伺候不了”。

正好又来了 @arry 的新通知，那就一并回复了，性能跟业务逻辑之间，是要做取舍的，不能为了微小的性能提升而牺牲过多业务逻辑的简洁性。现在 InnoDB 要求顺序主键，业务上需要自增主键来自动生成主键，二者正好相互支持。但如果哪天业务上需要把主键换成 UUID 了，要么 InnoDB 引擎能保证性能损失不大，要么就要换掉 Mysql 了。

需要说明一点，本人不是数据库开发者，或者表面是 Java 本质是 SQL 开发的程序员，我推崇的是用 JPA/Hibernate 完全隐藏掉任何数据库细节，并且在主键选择上倾向于 UUID 和自然主键。

很多表比如就用身份证来做主键了, 手机号码了, 也不一定非要多一个 ID 啊, 理解了, 做表关联还是非常方便的, 否则 FID 多了, 真不容易记住.

我倾向于有 ID 主键的原因主要是基于实践。其实如果一个人能预测未来，那从逻辑上看有没有 ID 主键根本无所谓。
但是问题在于没人能预测未来，今天你建了一个表以 name+出生地来标识一个确定的人，明天可能就需要根据这个表来扩展出一堆的表来存储别的什么东西。要是万一前面那个表需要改成 Name+出生地+出生日期才能标识一个确定的人。
我实在就想不出来到底该怎么处理后面那堆派生出来的表了.......

性能冗余的话，只要不出错就行。

官方推荐需要有自增主键，数据紧凑，页分裂操作少。

@passerbytiny 用自增主键并不需要牺牲多少业务简洁性，至少在我见过的代码中，直接显式使用主键来进行业务操作的非常少。所以几乎不存在业务上把自增主键改成 uuid 这种情况，反而是自然主键这种和业务强关联的字段，会因为业务的变更而产生重复 冲突的情况。
而使用 uuid 这种情况就更不能理解了，使用 uuid 必然会使得效率降低，而且占用更多的空间。

@arry #66 你别告诉我你们系统中基本没有 findById、editById、deleteById 之类的方法。业务变更必然要修改代码，有冲突解决就行了，为了避免将来可能有的冲突而现在不用自然主键，这属于超前设计，现在敏捷开发盛行，已经不受推崇了。你大概没做过更换系统时候的数据割接，那时候只有 UUID 主键是不会冲突的，自增主键和自然主键都会冲突（但是，若提前将主键定位 UUID 也是超前设计，不推荐）。

我推崇 UUID 的原因是它是最省事的主键。自增主键或序列主键都依赖数据库，同时，相比于有顺序有意义的数值，毫无顺序毫无意义的 UUID 才更像 ID。最后那一句就不回了，前面已经说得很清楚了。

顺便提一下，抛开数据库往外面看，git、docker 都是用 UUID 当主键的。

主键必须和数据无关，这不是常识吗=。=
竟然还有人这样写，服了

#76 楼上的建议很正确，主键必须和业务无关。而且如果不是百分之百确定不需要主键，那就加上。

我喜欢 shortid uuid 太长 不舒服

@passerbytiny 我却是觉得用 user_id 真的是设计有问题，你的表名已经指定是的 user 表，然后 id 还要叫 user_id，这是很多余的写法。

复合主键，数据更新后，重建索引是噩梦

这个帖子发得很一般，一来是举的例子时候被发现是不恰当的例子，二来是这帖子根本不是在探讨，只是在吐槽

这种写法很棒 :)

补充下，真是需要脑洞的啊。

肯定是用自增啊。。楼主说的这个更适合用复合唯一索引。

曾经我有一张单表撑了 1 亿多的数据，大量重复的数据在里面，要筛选出来删除。啥索引都不好使了，只能通过自增 id 遍历，加载一部分到内存里慢慢筛选，慢慢删除。那一刻我真的感谢当时用了 id 自增这玩意

我之前用过一个小 erp，没有主键，我的 sql 编辑器为了防止出错，在更新内容的时候采用 where 所有字段，然后还 top 1,感觉太不可思议了

@wmhx #70 选取主键的一个基本原则是：不使用任何业务相关的字段作为主键。因为主键是用来唯一定位记录的，修改了主键，会造成一系列的影响。因此，身份证号、手机号、邮箱地址这些看上去可以唯一的字段，均不可用作主键。

elasticsearch 就是这么做的。。。主键的作用是作为数据库组织数据用的，以 mysql 为例默认的 innodb 使用聚簇索引, 决定了数据的位置, 辅助索引也都会带上主键信息, 所以选择随着时间递增且占用空间较小的主键比较符合时间局部性原理，能够充分利用磁盘预读

这同名咋办？。。。。

@fx 选修过数据库设计就不会干这种事。。。

头一次见识这样的“附属表”设计，真是“涨姿势”了

有些表是可以不用主键的，楼主学一下 EAV 模型

@bzj 漏了 2 个字 不用 id 作为主键

K 线数据，可以用复合，股票代码时间

阿里新零售数据库设计与实战
非推广

必须要自增主键，没有商量的余地，也没有必要在这方面耗费精力。

MySQL 墙裂推荐使用自增主键，非自增主键效率会差很多，没有主键更差，其他数据库的话，有的可能对非自增主键支持好一点，效率上不会比自增主键差太多

按需而论。
并不是所有的项目都需要自增 ID 或者 UUID 主键。

对于简单项目的部分场景，直接用复合主键同时约束组合唯一性，大数据量节省资源也正常。