MySQL主键设计盘点

目录

  • 主键定义
  • 主键设计和应用原则
  • 主键生成策略
    • 自增ID
    • UUID
    • 自建的id生成器
      • Twitter的snowflake算法

@

最近在项目中用了UUID的方式生成主键,一开始只是想把这种UUID的方式生成主键记录下来,在查阅资料的过程中,又有了一些新的认识和思考。

主键定义

唯一标识表中每行的一个列(或一组列)称为主键。主键用来表示一个特定的行。

主键设计和应用原则

除了满足MySQL强制实施的规则(主键不可重复;一行中主键不可为空)之外,主键的设计和应用应当还遵守以下公认的原则:

  • 不更新主键列中的值;
  • 不重用主键列的值;
  • 不在主键列中使用可能会更改的值。(例如,如果使用一个
    名字作为主键以标识某个供应商,当该供应商合并和更改其
    名字时,必须更改这个主键。)

主键生成策略

自增ID

使用数据库的自动增长(auto_increment),是比较简单和常见的ID生成方案,数据库内部可以确保生成id的唯一性。

优点:

1、数据库自动编号,速度快,而且是增量增长,聚集型主键按顺序存放,对于检索非常有利。

2、 数字型,占用空间小,易排序,在程序中传递方便。

缺点:

1、不支持水平分片架构,水平分片的设计当中,这种方法显然不能保证全局唯一。

2、对数据库有依赖,每种数据库可能实现不一样,数据库切换时候,涉及到代码的修改,不利于扩展

结论:

自增id做主键适用于非分布式架构。

UUID

UUID:通用唯一识别码(英语:Universally Unique Identifier,缩写:UUID)是用于计算机体系中以识别信息数目的一个128位标识符,还有相关的术语:全局唯一标识符(GUID)。
根据标准方法生成,不依赖中央机构的注册和分配,UUID具有唯一性,这与其他大多数编号方案不同。重复UUID码概率接近零,可以忽略不计。UUID是由一组32位数的16进制数字所构成,标准型式包含32个16进制数字,以连字号分为五段,形式为8-4-4-4-12的32个字符。示例:

550e8400-e29b-41d4-a716-446655440000

到目前为止业界一共有5种方式生成UUID,详情可见IETF发布的UUID规范A Universally Unique IDentifier (UUID) URN Namespace

优点:

性能非常高:本地生成,没有网络消耗。

缺点:

1、不易于存储:UUID太长,16字节128位,通常以36长度的字符串表示,很多场景不适用。

2、信息不安全:基于MAC地址生成UUID的算法可能会造成MAC地址泄露,这个漏洞曾被用于寻找梅丽莎病毒的制作者位置。

3、ID作为主键时在特定的环境会存在一些问题,比如需要排序的时候——UUID是无序的。

4、MySQL官方有明确的建议主键要尽量越短越好,36个字符长度的UUID不符合要求。

5、对MySQL索引不利:作为数据库主键,在InnoDB引擎下,UUID的无序性可能会引起数据位置频繁变动,严重影响性能。

关于MySQL 使用自增ID主键和UUID 作为主键的性能比较可以查看参考【8】。

结论:

1、uuid做主键适用于小规模分布式架构用。

2、在使用uuid作为主键的时候,最好设计createtime(创建时间)列和modifytime(修改时间)列以应付可能的排序等场景。

自建的id生成器

Twitter的snowflake算法

Twitter的snowflake算法的核心把时间戳,工作机器id,序列号组合在一起。


除了最高位bit标记为不可用以外,其余三组bit占位均可浮动,看具体的业务需求而定。默认情况下41bit的时间戳可以支持该算法使用到2082年,10bit的工作机器id可以支持1023台机器,序列号支持1毫秒产生4095个自增序列id。

具体可以查看:https://github.com/twitter-archive/snowflake.git (但是最近一次的提交是6年前,显示已经停止了对初始版snowflake的支持)

源码如下:

package com.yjd.comm.util;/**
 * Created by pc on 2017/8/16 0016.
 */

/**
 * Twitter_Snowflake<br>
 * SnowFlake的结构如下(每部分用-分开):<br>
 * 0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000 <br>
 * 1位标识,由于long基本类型在Java中是带符号的,最高位是符号位,正数是0,负数是1,所以id一般是正数,最高位是0<br>
 * 41位时间截(毫秒级),注意,41位时间截不是存储当前时间的时间截,而是存储时间截的差值(当前时间截 - 开始时间截)
 * 得到的值),这里的的开始时间截,一般是我们的id生成器开始使用的时间,由我们程序来指定的(如下下面程序IdWorker类的startTime属性)。41位的时间截,可以使用69年,年T = (1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69<br>
 * 10位的数据机器位,可以部署在1024个节点,包括5位datacenterId和5位workerId<br>
 * 12位序列,毫秒内的计数,12位的计数顺序号支持每个节点每毫秒(同一机器,同一时间截)产生4096个ID序号<br>
 * 加起来刚好64位,为一个Long型。<br>
 * SnowFlake的优点是,整体上按照时间自增排序,并且整个分布式系统内不会产生ID碰撞(由数据中心ID和机器ID作区分),并且效率较高,经测试,SnowFlake每秒能够产生26万ID左右。
 */
public class SnowflakeIdWorker {

    // ==============================Fields===========================================
    /**
     * 开始时间截 (2015-01-01)
     */
    private final long twepoch = 1420041600000L;

    /**
     * 机器id所占的位数
     */
    private final long workerIdBits = 5L;

    /**
     * 数据标识id所占的位数
     */
    private final long datacenterIdBits = 5L;

    /**
     * 支持的最大机器id,结果是31 (这个移位算法可以很快的计算出几位二进制数所能表示的最大十进制数)
     */
    private final long maxWorkerId = -1L ^ (-1L << workerIdBits);

    /**
     * 支持的最大数据标识id,结果是31
     */
    private final long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);

    /**
     * 序列在id中占的位数
     */
    private final long sequenceBits = 12L;

    /**
     * 机器ID向左移12位
     */
    private final long workerIdShift = sequenceBits;

    /**
     * 数据标识id向左移17位(12+5)
     */
    private final long datacenterIdShift = sequenceBits + workerIdBits;

    /**
     * 时间截向左移22位(5+5+12)
     */
    private final long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;

    /**
     * 生成序列的掩码,这里为4095 (0b111111111111=0xfff=4095)
     */
    private final long sequenceMask = -1L ^ (-1L << sequenceBits);

    /**
     * 工作机器ID(0~31)
     */
    private long workerId;

    /**
     * 数据中心ID(0~31)
     */
    private long datacenterId;

    /**
     * 毫秒内序列(0~4095)
     */
    private long sequence = 0L;

    /**
     * 上次生成ID的时间截
     */
    private long lastTimestamp = -1L;

    //==============================Constructors=====================================

    /**
     * 构造函数
     *
     * @param workerId     工作ID (0~31)
     * @param datacenterId 数据中心ID (0~31)
     */
    public SnowflakeIdWorker(long workerId, long datacenterId) {
        if (workerId > maxWorkerId || workerId < 0) {
            throw new IllegalArgumentException(String.format("worker Id can't be greater than %d or less than 0", maxWorkerId));
        }
        if (datacenterId > maxDatacenterId || datacenterId < 0) {
            throw new IllegalArgumentException(String.format("datacenter Id can't be greater than %d or less than 0", maxDatacenterId));
        }
        this.workerId = workerId;
        this.datacenterId = datacenterId;
    }

    // ==============================Methods==========================================

    /**
     * 获得下一个ID (该方法是线程安全的)
     *
     * @return SnowflakeId
     */
    public synchronized long nextId() {
        long timestamp = timeGen();

        //如果当前时间小于上一次ID生成的时间戳,说明系统时钟回退过这个时候应当抛出异常
        if (timestamp < lastTimestamp) {
            throw new RuntimeException(
                    String.format("Clock moved backwards.  Refusing to generate id for %d milliseconds", lastTimestamp - timestamp));
        }

        //如果是同一时间生成的,则进行毫秒内序列
        if (lastTimestamp == timestamp) {
            sequence = (sequence + 1) & sequenceMask;
            //毫秒内序列溢出
            if (sequence == 0) {
                //阻塞到下一个毫秒,获得新的时间戳
                timestamp = tilNextMillis(lastTimestamp);
            }
        }
        //时间戳改变,毫秒内序列重置
        else {
            sequence = 0L;
        }

        //上次生成ID的时间截
        lastTimestamp = timestamp;

        //移位并通过或运算拼到一起组成64位的ID
        return ((timestamp - twepoch) << timestampLeftShift) //
                | (datacenterId << datacenterIdShift) //
                | (workerId << workerIdShift) //
                | sequence;
    }

    /**
     * 阻塞到下一个毫秒,直到获得新的时间戳
     *
     * @param lastTimestamp 上次生成ID的时间截
     * @return 当前时间戳
     */
    protected long tilNextMillis(long lastTimestamp) {
        long timestamp = timeGen();
        while (timestamp <= lastTimestamp) {
            timestamp = timeGen();
        }
        return timestamp;
    }

    /**
     * 返回以毫秒为单位的当前时间
     *
     * @return 当前时间(毫秒)
     */
    protected long timeGen() {
        return System.currentTimeMillis();
    }

    //==============================Test=============================================

    /**
     * 测试
     */
    public static void main(String[] args) {
        SnowflakeIdWorker idWorker = new SnowflakeIdWorker(1, 1);
        long startime = System.currentTimeMillis();
        for (int i = 0; i < 4000000; i++) {
            long id = idWorker.nextId();
//            System.out.println(Long.toBinaryString(id));
//            System.out.println(id);
        }
        System.out.println(System.currentTimeMillis() - startime);
    }
}

优点:

1、毫秒数在高位,自增序列在低位,整个ID都是趋势递增的。
2、 不依赖数据库等第三方系统,以服务的方式部署,稳定性更高,生成ID的性能也是非常高的。
3、可以根据自身业务特性分配bit位,非常灵活。

缺点:

强依赖机器时钟,如果机器上时钟回拨,会导致发号重复或者服务会处于不可用状态。

结论:

用自建的id生成器做主键适用于大规模分布式架构

参考:

【1】:红心李 :MySQL主键设计
【2】:Uncle Nucky :MySQL数据库主键设计原则
【3】:ellis:设计套路:Mysql主键的选取
【4】:路人甲Java:分布式系统生成唯一id常见方案
【5】:《MySQL必知必会》
【6】:美团技术团队:Leaf——美团点评分布式ID生成系统
【7】:UUID performance in MySQL?
【8】:alex.shu:MySQL 使用自增ID主键和UUID 作为主键的优劣比较详细过程(从百万到千万表记录测试)
【9】:咖啡拿铁:如果再有人问你分布式ID,这篇文章丢给他
【10】:漫漫路:Twitter-Snowflake,64位自增ID算法详解

原文地址:https://www.cnblogs.com/three-fighter/p/12347305.html

时间: 2024-10-04 02:30:19

MySQL主键设计盘点的相关文章

MySQL主键设计

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

mysql主键的缺少导致备库hang

最近线上频繁的出现slave延时的情况,经排查发现为用户在删除数据的时候,由于表主键的主键的缺少,同时删除条件没有索引,或或者删除的条件过滤性极差,导致slave出现hang住,严重的影响了生产环境的稳定性,也希望通过这篇博客,来加深主键在innodb引擎中的重要性,希望用户在使用RDS,设计自己的表的时候,一定要为表加上主键,主键可以认为是innodb存储引擎的生命,下面我们就来分析一下这个案例(本案例的生产环境的binlog为row模式,对于myisam存储引擎也有同样的问题):(1).现象

【转载】mysql主键的缺少导致备库hang

最近线上频繁的出现slave延时的情况,经排查发现为用户在删除数据的时候,由于表主键的主键的缺少,同时删除条件没有索引,或或者删除的条件过滤性极差,导致slave出现hang住,严重的影响了生产环境的稳定性,也希望通过这篇博客,来加深主键在innodb引擎中的重要性,希望用户在使用RDS,设计自己的表的时候,一定要为表加上主键,主键可以认为是innodb存储引擎的生命,下面我们就来分析一下这个案例(本案例的生产环境的binlog为row模式,对于myisam存储引擎也有同样的问题):(1).现象

MySQL主键自动生成和生成器表以及JPA主键映射

MySQL主键自动生成 表设计 MySQL有许多主键生成策略,其中很常见的一种是自动生成.一般情况下,主键类型是BIGINT UNSIGNED,自动生成主键的关键词是AUTO_INCREMENT. CREATE TABLE Stock ( id BIGINT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT, NO VARCHAR(255) NOT NULL, name VARCHAR(255) NOT NULL, price DECIMAL(6,2) N

Oracle与Mysql主键、索引及分页的区别小结

Oracle与Mysql主键.索引及分页的区别,学习oracle的朋友可以参考下 区别: 1.主键,Oracle不可以实现自增,mysql可以实现自增. oracle新建序列,SEQ_USER_Id.nextval 2.索引: mysql索引从0开始,Oracle从1开始. 3.分页, mysql: select * from user order by desc limit n ,m. 表示,从第n条数据开始查找,一共查找m条数据. Oracle:select * from user sele

MYSQL主键自动增加的配置

文章一 原文地址: http://ej38.com/showinfo/mysql-202971.html 文章二:   点击转入第二篇文章 在数据库应用,我们经常要用到唯一编号.在MySQL中可通过字段的AUTO_INCREMENT属性来自动生成.MySQL支持多种数据表,每种数据表的自增属性都有所不同. ISAM表 如果把一个NULL插入到一个AUTO_INCREMENT数据列里去,MySQL将自动生成下一个序列编号.编号从1开始,并1为基数递增. 当插入记录时,没有为AUTO_INCREME

MySQL主键 外键 索引

一.什么是主键.外键: 关系型数据库中的一条记录中有若干个属性,若其中某一个属性组(注意是组)能唯一标识一条记录,该属性组就可以成为一个主键比如 : 学生表(学号,姓名,性别,班级) 其中每个学生的学号是唯一的,学号就是一个主键 用户表(用户名.密码.登录级别) 其中用户名是唯一的, 用户名就是一个主键 上机记录表(卡号,学号,姓名.序列号) 上机记录表中单一一个属性无法唯一标识一条记录,学号和姓名的组合才可以唯一标识一条记录,所以 学号和姓名的属性组是一个主键 上机记录表中的序列号不是成绩表的

Mysql主键索引、唯一索引、普通索引、全文索引、组合索引的区别

原文:Mysql主键索引.唯一索引.普通索引.全文索引.组合索引的区别 Mysql索引概念: 说说Mysql索引,看到一个很少比如:索引就好比一本书的目录,它会让你更快的找到内容,显然目录(索引)并不是越多越好,假如这本书1000页,有500也是目录,它当然效率低,目录是要占纸张的,而索引是要占磁盘空间的. Mysql索引主要有两种结构:B+树和hash. hash:hsah索引在mysql比较少用,他以把数据的索引以hash形式组织起来,因此当查找某一条记录的时候,速度非常快.当时因为是has

mysql主键设置成auto_increment时,进行并发性能测试出现主键重复Duplicate entry &#39;xxx&#39; for key &#39;PRIMARY&#39;

mysql主键设置成auto_increment时,进行并发性能测试出现主键重复Duplicate entry 'xxx' for key 'PRIMARY' 解决方法: 在my.cnf的[mysqld]片段中添加设置innodb_autoinc_lock_mode=0 同时注意调大jdbc的活跃链接数,如设置 jdbc.maxActive=300,因为设置innodb_autoinc_lock_mode=0可能导致链接过多. 注意,这种方式只需要在并发性能测试时设置,因为这种方式在插入记录时需