哆啦A梦丶幻想 2019-09-26 12:02 采纳率: 0%
浏览 941

MySQL InnoDB引擎,主键自增的实用性高吗? 主键自增的优点和缺点如何取舍?

在使用InnoDB存储引擎时,如果没有特别的需要,请永远使用一个与业务无关的自增字段作为主键。

   经常看到有帖子或博客讨论主键选择问题,有人建议使用业务无关的自增主键,有人觉得没有必要,完全可以使用如学号或身份证号这种唯一字段作为主键。不论支持哪种论点,大多数论据都是业务层面的。如果从数据库索引优化角度看,使用InnoDB引擎而不使用自增主键绝对是一个糟糕的主意。

   InnoDB使用聚集索引,数据记录本身被存于主索引(一颗B+Tree)的叶子节点上。这就要求同一个叶子节点内(大小为一个内存页或磁盘页)的各条数据记录按主键顺序存放,因此每当有一条新的记录插入时,MySQL会根据其主键将其插入适当的节点和位置,如果页面达到装载因子(InnoDB默认为15/16),则开辟一个新的页(节点)。

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

https://blog.codinglabs.org/uploads/pictures/theory-of-mysql-index/13.png


   这样就会形成一个紧凑的索引结构,近似顺序填满。由于每次插入时也不需要移动已有数据,因此效率很高,也不会增加很多开销在维护索引上。

   如果使用非自增主键(如果身份证号或学号等),由于每次插入主键的值近似于随机,因此每次新纪录都要被插到现有索引页得中间某个位置:

https://blog.codinglabs.org/uploads/pictures/theory-of-mysql-index/14.png

   此时MySQL不得不为了将新记录插到合适位置而移动数据,甚至目标页面可能已经被回写到磁盘上而从缓存中清掉,此时又要从磁盘上读回来,这增加了很多开销,同时频繁的移动、分页操作造成了大量的碎片,得到了不够紧凑的索引结构,后续不得不通过OPTIMIZE TABLE来重建表并优化填充页面。

   因此,只要可以,请尽量在InnoDB上采用自增字段做主键。

文章资料来自:https://blog.codinglabs.org/articles/theory-of-mysql-index.html

  • 写回答

1条回答 默认 最新

  • threenewbee 2019-09-26 12:13
    关注

    建议使用业务无关的字段作为主键。对于数据量明显小于2的31次方的字段,完全可以也应该用主键自增,id对用户也是相对友好的(和guid相比)
    使用业务无关的字段作为主键有两个原因,一个是你要假设业务永远是可能变更的,不要想当然,给自己挖坑。
    另一个是,如果你的程序要扩展到多租户环境,或者需要合并不同的数据库(比如多个分支公司的数据库,历史数据库等),这样设计的好处就体现出来了。

    评论

报告相同问题?

悬赏问题

  • ¥15 代码的修改,添加和运行完善
  • ¥15 krpano-场景分组和自定义地图分组
  • ¥15 lammps Gpu加速出错
  • ¥15 关于PLUS模型中kapaa值的问题
  • ¥15 关于博途V17进行仿真时无法建立连接问题
  • ¥15 机器学习教材中的例题询问
  • ¥15 求.net core 几款免费的pdf编辑器
  • ¥15 为什么安装HCL 和virtualbox之后没有找到VirtualBoxHost-OnlyNetWork?
  • ¥15 C# P/Invoke的效率问题
  • ¥20 thinkphp适配人大金仓问题