MySQL发号问题的分析和改进

关于发号器的使用,其实有一个大背景,那就是关于主键的一些设计问题,在MySQL中如果一张表没有主键,实际的数据处理就有点麻烦了。
因为在InnoDB存储引擎中,表都是按照主键的顺序进行存放的,我们叫做聚簇索引表或者索引组织表(IOT)

  1. 显式的创建主键Primary key。
  2. 判断表中是否有非空唯一索引,如果有,则为主键。
  3. 如果都不符合上述条件,则会生成UUID的一个隐式主键(6字节大)

可以使用类似的SQL来看到这个隐藏列:

select _rowid from test

这和主键有什么关系?主要是因为有些时候我们创建主键就是为了创建而创建,没有实际的业务含义,所以会形成一种使用习惯,那就是启用自增列。
自增列的问题很多,有些几句话还说不清楚,大体有如下的一些问题:

  1. 自增列没有业务含义
  2. 过度依赖自增列
  3. 自增列和状态值主键并存,反而影响业务逻辑和性能
  4. MySQL历史遗留bug,在MySQL 8.0该问题才修复

到了这里,我们的需求也基本明确了,我们所说的发号器其实就是要确保每次取到的ID号都是唯一的,当然也显而易见是趋势递增的。

posted @   西门长海  阅读(77)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· Manus重磅发布:全球首款通用AI代理技术深度解析与实战指南
· 被坑几百块钱后,我竟然真的恢复了删除的微信聊天记录!
· 没有Manus邀请码?试试免邀请码的MGX或者开源的OpenManus吧
· 园子的第一款AI主题卫衣上架——"HELLO! HOW CAN I ASSIST YOU TODAY
· 【自荐】一款简洁、开源的在线白板工具 Drawnix
点击右上角即可分享
微信分享提示