未分類
15 4 月 2020

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

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

資深大佬 : Orenoid 17

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

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

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

大佬有話說 (6)

  • 主 資深大佬 : Orenoid

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

  • 資深大佬 : leonme

    数据量如何？

  • 資深大佬 : fortunezhang

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

  • 資深大佬 : opengps

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

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

  • 主 資深大佬 : Orenoid

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

  • 資深大佬 : opengps

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