InnoDB主键设计

InnoDB是clustered-index table，因此对于InnoDB而言，主键具有特殊意义。可以通过主键直接定位到对应的某一数据行记录的物理位置，主键索引指向对应行记录，其他索引则都指向主键索引；因此，可以这么说，InnoDB其实就是一个 B-树索引，这棵B-树的索引就是主键，它的值则是对应的行记录。
在InnoDB数据表设计中，我们需要注意几点：

    • 1. 显式的定义一个 INT 类型自增字段的主键，这个字段可以仅用于做主键，不做其他用途
    • 2. 如果不显式定义主键的话，可能会导致InnoDB每次都需要对新数据行进行排序，严重损害性能
    • 3. 尽量保证不对主键字段进行更新修改，防止主键字段发生变化，引发数据存储碎片，降低IO性能
    • 4. 如果需要对主键字段进行更新，请将该字段转变成一个唯一索引约束字段，另外创建一个没有其他业务意义的自增字段做主键
    • 5. 主键字段类型尽可能小，能用SMALLINT就不用INT，能用INT就不用BIGINT
    • 6. 主键字段放在数据表的第一顺序
时间： 2024-11-09 01:21:15

InnoDB主键设计的相关文章

MySQL主键设计

原文:MySQL主键设计 [TOC] 在项目过程中遇到一个看似极为基础的问题,但是在深入思考后还是引出了不少问题,觉得有必要把这一学习过程进行记录. MySQL主键设计原则 MySQL主键应当是对用户没有意义的. MySQL主键应该是单列的,以便提高连接和筛选操作的效率 永远也不要更新MySQL主键 MySQL主键不应包含动态变化的数据,如时间戳.创建时间列.修改时间列等 MySQL主键应当有计算机自动生成. 主键设计的常用方案 自增ID 优点: 1.数据库自动编号,速度快,而且是增量增长,聚集

MySQL主键设计盘点

目录 主键定义 主键设计和应用原则 主键生成策略 自增ID UUID 自建的id生成器 Twitter的snowflake算法 @ 最近在项目中用了UUID的方式生成主键,一开始只是想把这种UUID的方式生成主键记录下来,在查阅资料的过程中,又有了一些新的认识和思考. 主键定义 唯一标识表中每行的一个列(或一组列)称为主键.主键用来表示一个特定的行. 主键设计和应用原则 除了满足MySQL强制实施的规则(主键不可重复:一行中主键不可为空)之外,主键的设计和应用应当还遵守以下公认的原则: 不更新主

MySQL集群数据库表的主键设计

使用MySQL数据库的人,毫无例外的在设计时都会碰到主键的选型,一般都会在下面三种中选择一个或多个,自增长列.UUID以及UUID_SHORT,这集中主键的特性,想必大家都非常了解了,我就不再细说了,在InnoDB引擎中,选择哪种主键更好,网上也有很多帖子有描述,基本上都是建议是自增长列或者搭配UUID作为逻辑主键一起使用,但是如果是ndbcluster引擎呢? 为此我专门做了一下测试,环境为4台物流机器(2C,8G内存)做的数据节点,NoOfReplicas=2,首先建立三张表. CREATE

MYSQL INNODB主键使用varchar和int有什么区别？

本文和大家分享的主要是MYSQL 数据库主键使用varchar和int的区别,一起来看看吧,希望对大家学习mysql有所帮助. 我现在总结的3个问题: 1.tablespace中空间浪费 当然我们知道使用varchar可能会导致辅助索引比较大,因为用到varchar可能存储的字符较多,同时 在行头也存在一个可变字段字符区域(1-2)字节 而辅助索引叶子结点毕竟都存储了主键值,这样至少会多varchar数据字节数量+1(或者2) 字节- 4(int)字节空间. 如果辅助索引比较多空间浪费是可想而知

主表和子表主键设计

将主表主键设置为ID,另外将子表主键设置为AID,子表的外键ID和主表一样.那么当发生对主表记录进行删除操作,可以方便的对关联的子表数据一并删除! declare @selectStr nvarchar(1000) set @selectStr='delete from Bdrdrecord11 ' + @searchString+' delete from Bdrdrecords11 '+@searchString exec (@selectStr)

主键索引小结

InnoDB主键特点 1.索引定义时,若不显示包含主键,会隐式加入主键值. 2.索引定义时,若显示包含主键,会加入主键值. 3.在5.6.8以后,优化器已能自动识别索引末尾的主键值(Index Extensions),在这之前则需要显式加上主键列才可以被识别 案例:某InnoDB表,没有自增列主键,使用一段时间后,产生碎片,重整表空间后,从13G变成了9G. 主键选择建议: 1.对业务透明,无意义,免受业务变化影响. 2.主键要很少修改和删除. 3.主键最好是自增的. 4.不要具有动态属性,例如

mysq数据库设计（主键与外键）

主键可以是真实实体的属性,但是常用的好的解决方案是,利用一个与实体信息不相关的属性,作为唯一标示(加个id字段)主键与业务逻辑不发生关系,只用来标示记录 可以在定义完字段后,再定义多列主键(组合主键) 例:primary key(id,name,age);(不是说3个字段都是主键,因为一个表只能有一个主键,可以是3个字段组合成的主键) 设计: 两个实体表内,存在相同的主键字段 如果记录的主键值等于另一个关系表内记录的主键则两天记录对应 1:1对应  数据库设计的时候(常用的信息和不常用的信息分开

数据库模型设计——关系的实现，主键的设计

一.关系的实现 在实体关系模型中,我们知道有三种关系:一对一.一对多.多对多.这只是概念上的关系,但是在真实的关系数据库中,我们只有外键,并没有这三种关系,那么我们就来说一说在关系数据库管理系统中,怎么实现这三种关系. 一对多 这里先讲解一对多,因为这个关系最简单.一对多和多对一是一回事,所以就不再提多对一这个词.一对多的概念是一个对象A会对应多个对象B,而从B的角度看,一个对象B只会对于一个对象A.比如说班级和学生就是一对多关系.一个班级对应多个学生,一个学生只会对于一个班级. 一对多的关系之

自增长主键Id的设计

一.引言 在使用ORM框架时,一个表有一个主键是必须的,如果没有主键,就没有办法来唯一的更新一条记录.在Sql Server数据库和Mysql数据库设置自增长的主键是一件很轻松的事情,如果在Oracle数据库中设置自增长的主键是比较繁琐的.本文不讨论数据库里单表的自增长问题,探讨的是多表自增长唯一Id的设计.如果各位看官遇到这个多表自增长唯一Id的这个需求,会怎么处理呢? 二.GUID的介绍 关于自增长主键的问题,有些人可能会想到.Net中的GUID,先对这个GUID进行测试. public v