请教个关于 MySQL 物理主键和逻辑主键的问题

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

V2EX 提问指南

这是一个创建于 1674 天前的主题，其中的信息可能已经有所发展或是发生改变。

最近设计数据库表结构，翻查资料的时候看到 v2 有个帖子里给出了这么一个方案：

用自增 ID 做物理主键，再加一个 uuid 做逻辑主键（加 unique 索引），在外键关联的时候用逻辑主键，这样子在分库的时候无痛，也不会遇到 uuid 作为物理主键的时候遇到的性能问题。唯一的 issuse 就是会浪费一部分存储空间

我的疑问是，基于 InnoDB 引擎去实践这个方案的话，若需要通过逻辑主键读取行，是必须要回表的吧。
这种程度的开销是可接受的吗，还是说视具体查询而定？

主键

逻辑

uuid

物理

6 条回复 • 2020-04-16 16:05:06 +08:00

Orenoid

2020-04-16 12:49:02 +08:00 via Android

为啥我发帖经常自带没人搭理的 debuff…

leonme

2020-04-16 13:04:59 +08:00

数据量如何？

fortunezhang

2020-04-16 13:07:51 +08:00 via Android

平时用的话，除非客户说明，否则不用逻辑主键。一方面麻烦，另一方面感觉不如主键快（没有凭证，我瞎猜的）。
但是逻辑主键比物理主键，有时候安全。

opengps

2020-04-16 13:17:17 +08:00 via Android

无论你用什么去查询，都是要回到表里查询的，只不过查的过程省时间了

自增物理主键用来解决数据落盘是按顺序的，来保证写入不随机，保证写性能同时给以后的表分区做提前准备
逻辑主键为了解决读的问题，一步到位找到“门牌号”，总比从某个范围里用某种方法去多次筛选要简单的多

Orenoid

2020-04-16 13:45:17 +08:00

@opengps #4
谢谢，如果用物理主键查询的话，应该是只扫描一次聚簇索引就可以拿到数据了。但如果用逻辑主键查询，那么还需要先到二级索引里拿到物理主键的值，然后再扫描一次聚簇索引。
我觉得这个方案其他地方都挺好的，但唯独要需要通过逻辑主键查询（比如表联结）的时候会多一些开销，不知道影响大不大。
@leonme #2
公司的业务其实远没有到考虑分布式和分区的程度，纯粹是出于学习目的，研究这个方案的可行性。。

opengps

2020-04-16 16:05:06 +08:00

@Orenoid 你可以换个名词来理解：我有篇博客，在 v2 分享多次了，你可以参考理解下我说的意思，相对比回复的更条理： https://www.opengps.cn/Blog/View.aspx?id=284&from=v2ex
物理主键>时间戳聚集索引
逻辑主键>主要查询条件