设计 MySQL 数据表的时候一般都有一列为自增 ID,这样设计原因是什么,有什么好处?
知乎采集:
MyISAM/InnoDB默认用B-Tree索引(可理解为"排好序的快速查找结构")。
InnoDB中,主索引文件上直接存放该行数据,称为聚簇索引。次索引指向对主键的引用;
MyISAM中,主索引和次索引,都指向物理行(磁盘位置);
注意: 对InnoDB来说
1: 主键索引既存储索引值,又在叶子中存储行的数据;
2: 如果没有定义主键,则会使用非空的UNIQUE键做主键 ; 如果没有非空的UNIQUE键,则系统生成一个6字节的rowid做主键;
聚簇索引中,N行形成一个页。如果碰到不规则数据插入时,会造成频繁的页分裂(因为索引要排好序),插入速度比较慢。所以聚簇索引的主键值应尽量是连续增长的值,而不是随机值(不要用随机字符串或UUID),否则会造成大量的页分裂与页移动。
故对于InnoDB的主键,尽量用整型,而且是递增的整型。这样在存储/查询上都是非常高效的。作者:阿烈
链接:https://www.zhihu.com/question/28703540/answer/41805377
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
InnoDB 使用两种索引来组织数据,Clustered Index 和 Second Index
Clustered Index 与 主键有千丝万缕的关系,可以简单认为是相等关系,数据存储会按照主键来进行排序。
如果在建表的时候不提供主键,InnoDB 会自动生成一个主键,这个主键是字符式的,所以当有新数据进来的时候,原先的排序会被打乱,中间的开销会很高。简单说就是那棵树的左旋右旋,很麻烦。
使用自增 ID 充当主键,就可以解决这个问题了,相应的 Second Index 的查询效率也会变高
Clustered Index 与 主键有千丝万缕的关系,可以简单认为是相等关系,数据存储会按照主键来进行排序。
如果在建表的时候不提供主键,InnoDB 会自动生成一个主键,这个主键是字符式的,所以当有新数据进来的时候,原先的排序会被打乱,中间的开销会很高。简单说就是那棵树的左旋右旋,很麻烦。
使用自增 ID 充当主键,就可以解决这个问题了,相应的 Second Index 的查询效率也会变高
作者:匿名用户
链接:https://www.zhihu.com/question/28703540/answer/41794747
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
不谈高逼格东西,从普通人角度来认识。一,id,如同身份证号,名字可以重复,但身份证号是唯一的;二,自动增长,从编程角度来说,更简便,不用花心思去管这块了;三,优势呢,两个表关联,可能用到id,查找记录,可能用到id,就把它当警察叔叔通过身份证号码来找你一样性质——没身份证号码,天不会塌,但会乱。。。
作者:沈磊
链接:https://www.zhihu.com/question/28703540/answer/41864615
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
posted on 2019-02-17 20:58 ExplorerMan 阅读(279) 评论(0) 编辑 收藏 举报