首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

如何将bigIncrements('id')转换为uuid('id')作为主键?

在 Laravel 中,可以通过以下步骤将 bigIncrements('id') 转换为 uuid('id') 作为主键:

  1. 首先,确保你的数据库表已经创建,并且使用 bigIncrements('id') 作为主键。
  2. 在对应的模型文件中,使用 uuid trait 来替换默认的 incrementingkeyType 属性。在模型文件的顶部添加以下代码:
代码语言:txt
复制
use Illuminate\Database\Eloquent\Model;
use Illuminate\Support\Str;

class YourModel extends Model
{
    use \Illuminate\Database\Eloquent\SoftDeletes;
    use \App\Traits\UsesUuid; // 添加这一行

    // ...
}
  1. 创建一个新的 trait 文件,命名为 UsesUuid.php(可以根据自己的喜好选择文件名),并将以下代码添加到该文件中:
代码语言:txt
复制
<?php

namespace App\Traits;

use Illuminate\Support\Str;

trait UsesUuid
{
    /**
     * Boot function from Laravel.
     */
    protected static function bootUsesUuid()
    {
        static::creating(function ($model) {
            if (! $model->getKey()) {
                $model->{$model->getKeyName()} = (string) Str::uuid();
            }
        });
    }

    /**
     * Get the value indicating whether the IDs are incrementing.
     *
     * @return bool
     */
    public function getIncrementing()
    {
        return false;
    }

    /**
     * Get the type of the primary key.
     *
     * @return string
     */
    public function getKeyType()
    {
        return 'string';
    }
}
  1. 确保你的项目中已经安装了 ramsey/uuid 包,可以通过 Composer 进行安装:
代码语言:txt
复制
composer require ramsey/uuid
  1. 运行数据库迁移命令,将主键类型从 bigIncrements 转换为 uuid
代码语言:txt
复制
php artisan migrate

现在,你的模型将使用 uuid 作为主键,每次创建新记录时都会自动生成一个唯一的 UUID。

这是一个将 bigIncrements('id') 转换为 uuid('id') 的方法,它可以确保主键使用 UUID 来保持唯一性。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

使用雪花id或uuid作为MySQL主键,被老板怼了一顿!

磊哥,前几天在做项目demo的时候,使用雪花id或uuid作为Mysql主键,被老板怼了一顿!...一、MySQL和程序实例 1.1 要说明这个问题,我们首先来建立三张表 分别是user_auto_key,user_uuid,user_random_key,分别表示自动增长的主键,uuid作为主键,随机...key作为主键,其它我们完全保持不变.根据控制变量法,我们只把每个表的主键使用不同的策略生成,而其他的字段完全一样,然后测试一下表的插入速度和查询速度: 注:这里的随机key其实是指用雪花算法算出来的前后不连续不重复无规律的...用户uuid表 ? 随机主键表: ?...带着疑问,我们来探讨一下这个问题: 二、使用uuid和自增id的索引结构对比 2.1 使用自增id的内部结构 ? 自增的主键的值是顺序的,所以Innodb把每一条记录都存储在一条记录的后面。

8.9K32
  • 使用雪花id或uuid作为Mysql主键,被老板怼了一顿!

    ,而是推荐连续自增的主键id,官方的推荐是auto_increment,那么为什么不建议采用uuid,使用uuid究竟有什么坏处?...一、mysql和程序实例 1.1 要说明这个问题,我们首先来建立三张表 分别是user_auto_key,user_uuid,user_random_key,分别表示自动增长的主键,uuid作为主键,随机...key作为主键,其它我们完全保持不变。...带着疑问,我们来探讨一下这个问题: 二、使用uuid和自增id的索引结构对比 2.1 使用自增id的内部结构 自增的主键的值是顺序的,所以Innodb把每一条记录都存储在一条记录的后面。...减少了页分裂和碎片的产生 2.2 使用uuid的索引内部结构 因为uuid相对顺序的自增id来说是毫无规律可言的,新行的值不一定要比之前的主键的值要大,所以innodb无法做到总是把新行插入到索引的最后

    1.2K20

    使用雪花id或uuid作为Mysql主键,被老板怼了一顿!

    前言: 在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一),而是推荐连续自增的主键id,官方的推荐是auto_increment,那么为什么不建议采用...# mysql和程序实例 1.要说明这个问题,我们首先来建立三张表 分别是user_auto_key,user_uuid,user_random_key,分别表示自动增长的主键,uuid作为主键,随机key...作为主键,其它我们完全保持不变.根据控制变量法,我们只把每个表的主键使用不同的策略生成,而其他的字段完全一样,然后测试一下表的插入速度和查询速度: 注:这里的随机key其实是指用雪花算法算出来的前后不连续不重复无规律的...带着疑问,我们来探讨一下这个问题: # 使用uuid和自增id的索引结构对比 1.使用自增id的内部结构 自增的主键的值是顺序的,所以Innodb把每一条记录都存储在一条记录的后面。...因为uuid相对顺序的自增id来说是毫无规律可言的,新行的值不一定要比之前的主键的值要大,所以innodb无法做到总是把新行插入到索引的最后,而是需要为新行寻找新的合适的位置从而来分配新的空间。

    1.6K10

    使用雪花id或uuid作为Mysql主键,被老板怼了一顿!

    ---- 前言 在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一,单机递增),而是推荐连续自增的主键id,官方的推荐是auto_increment...,user_random_key,分别表示自动增长的主键,uuid作为主键,随机key作为主键,其它我们完全保持不变....用户uuid表 ? 随机主键表: ?...带着疑问,我们来探讨一下这个问题: 二、使用uuid和自增id的索引结构对比 2.1.使用自增id的内部结构 ? 自增的主键的值是顺序的,所以Innodb把每一条记录都存储在一条记录的后面。...因为uuid相对顺序的自增id来说是毫无规律可言的,新行的值不一定要比之前的主键的值要大,所以innodb无法做到总是把新行插入到索引的最后,而是需要为新行寻找新的合适的位置从而来分配新的空间。

    2.2K10

    使用雪花 id 或 uuid 作为 MySQL 主键,被老板怼了一顿!

    `,`user_random_key`, 分别表示自动增长的主键, uuid 作为主键, 随机 key 作为主键, 其它我们完全保持不变....带着疑问, 我们来探讨一下这个问题: ### 二、使用 uuid 和自增 id 的索引结构对比 **2.1 使用自增 id 的内部结构** !...结论:使用 innodb 应该尽可能的按主键的自增顺序插入,并且尽可能使用单调的增加的聚簇键的值来插入新行 **2.3 使用自增 id 的缺点** 那么使用自增的 id 就完全没有坏处了吗?...并不是,自增 id 也会存在以下几点问题: ①:别人一旦爬取你的数据库, 就可以根据数据库的自增 id 获取到你的业务增长信息,很容易分析出你的经营情况 ②:对于高并发的负载,innodb 在按主键进行插入的时候会造成明显的锁争用...的生成策略在大数据量的数据插入表现,然后分析了 id 的机制不同在 mysql 的索引结构以及优缺点,深入的解释了为何 uuid 和随机不重复 id 在数据插入中的性能损耗,详细的解释了这个问题。

    2.9K00

    mysql 自增id和UUID做主键性能分析,及最优方案

    1.为什么要使用uuid做主键 (1).其实在innodb存储引擎下,自增长的id做主键性能已经达到了最佳。不论是存储和读取速度都是最快的,而且占的存储空间也是最小。...(2).但是在我们实际到项目中会碰到问题,历史数据表的主键id会与数据表的id重复,两张自增id做主键的表合并时,id一定会有冲突,但如果各自的id还关联了其他表,这就很不好操作。...(3).如果使用UUID,生成的ID不仅是表独立的,而且是库独立的。对以后的数据操作很有好处,可以说一劳永逸。 2.UUID优缺点 缺点: 1....为了存储和查询性能应该使用自增长id做主键。...(2).对于InnoDB的主索引,数据会按照主键进行排序,由于UUID的无序性,InnoDB会产生巨大的IO压力,此时不适合使用UUID做物理主键,可以把它作为逻辑主键,物理主键依然使用自增ID。

    8.4K20

    数据库面试题【十四、主键使用自增ID还是UUID】

    推荐使用自增ID,不要使用UUID。...因为在InnoDB存储引擎中,主键索引是作为聚簇索引存在的,也就是说,主键索引的B+树叶子节点上存储了主键索引以及全部的数据(按照顺序),如果主键索引是自增ID,那么只需要不断向后排列即可,如果是UUID...,由于到来的ID与原来的大小不确定,会造成非常多的数据插入,数据移动,然后导致产生很多的内存碎片,进而造成插入性能的下降。...总之,在数据量大一些的情况下,用自增主键性能会好一些。 关于主键是聚簇索引,如果没有主键,InnoDB会选择一个唯一键来作为聚簇索引,如果没有唯一键,会生成一个隐式的主键。

    56240

    被追着问UUID和自增ID做主键哪个好,为什么?

    之前无意间看到群友讨论到用什么做主键比较好 其实 UUID 和自增主键 ID 是常用于数据库主键的两种方式,各自具有独特的优缺点。...然而,UUID 作为主键 ID 也存在一些缺点: 存储空间较大:UUID 通常以字符串形式存储,占用的存储空间较大。 不适合范围查询:由于不是自增的,不支持范围查询。...自增 ID 在 MySQL 中,可以通过设置 AUTO_INCREMENT 属性实现 ID 的自增长,通常用于作为主键 ID。...使用自增 ID 作为主键的好处包括: 存储空间节省:ID 为数字,占用的位数比 UUID 小得多,因此在存储空间上更加节省。 查询效率高:ID 递增,利于 B+Tree 索引的查询效率提高。...DCE(Distributed Computing Environment)安全的 UUID 这个版本的 UUID 算法与基于时间戳的 UUID 相同,但会将时间戳的前 4 位替换为 POSIX 的 UID

    1.5K10

    InnoDB引擎为什么推荐使用自增ID作为主键?

    如果主键为自增 id 的话,MySQL 在写满一个数据页的时候,直接申请另一个新数据页接着写就可以了。...如果主键是非自增 id,为了确保索引有序,MySQL 就需要将每次插入的数据都放到合适的位置上。...自增id 可以保证每次插入时B+索引是从右边扩展的,可以避免B+树频繁合并和分裂(对比使用UUID而言)。如果使用字符串主键和随机主键,会使得数据随机插入,效率比较差。...普通索引的叶子节点上保存的是主键 id 的值,如果主键 id 占空间较大的话,那将会成倍增加 MySQL 空间占用大小。 ◆ 三、什么时候不需用自增主键?...◆ 四、主键自增带来的劣势是什么? 在高并发的场景下,自增主键也有一些弊端。 在InnoDB中按主键顺序插入可能会造成明显的争用。

    3.7K30

    为什么UUID不适合作为分布式全局唯一ID?

    在先前的文章中,我介绍了如何利用号段模式和雪花算法来创建分布式 ID。今天,我将探讨如何使用 UUID 来实现分布式 ID,并分析为何 UUID 不适宜作为分布式系统中的全局唯一 ID。...那你是不是很疑惑,为什么我说 UUID 不适合作为分布式全局唯一 ID 呢?因为 UUID 有利也有弊,在实际使用的时候,弊端影响更大。...对于数据库主键 ID,我们不仅要考虑全局唯一性和信息安全,还要考虑有序性,以及数据库的索引效率等因素。5 个版本的 UUID 生成都无法满足有序性,包含基于时间的 UUID 也不是。...假设,我们有一个主键列为 ID 的表,表中的 ID 分别为 5、9、11、15。这棵树简化后,大概是这样的。这棵树的叶子节点保存了完整的数据记录。...UUID 不依赖于数据库和外部其他服务,可以直接在本地服务实时计算并生成一个可用的 UUID 作为业务 ID。同时,UUID 满足全局唯一性和安全性。

    9600

    一步步带你了解ID发号器是什么、为什么、如何做!

    一、前言 上一篇文章《面试必备:如何将一个长URL转换为一个短URL?》...中谈到如何将长地址URL转换为短地址URL,其中谈到了一个比较理想的解决方案就是使用发号器生成一个唯一的整数ID,然后转换为62进制,作为短地址URL。...可以看出,User表中的100W数据被分到两个数据库中,在每一个数据库内部主键ID是自增的,但是却没法保证全局主键ID自增的,这显然是错误的!如何解决这种问题哪?...但是使用UUID是有点小问题的,主要体现在: UUID无法保证趋势递增; UUID过长,往往用32位字符串表示,占用数据库空间较大,做主键的时候索引中主键ID占据的空间较大; UUID作为主键建立索引查询效率低...,常见优化方案为转化为两个uint64整数存储; 由于使用实现版本的不一样,在高并发情况下可能会出现UUID重复的情况; UUID虽然能够保证全局主键ID的唯一性,但是UUID并不具有有序性,会导致B+

    1.3K20

    Spring boot Mybatis-XML方式通用Mapper插件(七)

    :设置生成UUID的方法,需要用OGNL方式配置,不限制返回值,但是必须和字段类型匹配 IDENTITY:取回主键的方式 DB2: VALUES IDENTITY_VAL_LOCAL() MYSQL:.... 6.建议一定是有一个@Id注解作为主键的字段,可以有多个@Id注解的字段作为联合主键. 7.默认情况下,实体类中如果不存在包含@Id注解的字段,所有的字段都会作为主键字段进行使用(这种效率极低)....,驼峰转换为下划线形式 uppercase:转换为大写 lowercase:转换为小写 重点强调 @Transient 注解 许多人由于不仔细看文档,频繁在这个问题上出错。...主键策略(仅用于insert方法) 通用Mapper还提供了序列(支持Oracle)、UUID(任意数据库,字段长度32)、主键自增(类似Mysql,Hsqldb)三种方式,其中序列和UUID可以配置多个...@GeneratedValue(generator = "UUID") 可以用于任意字符串类型长度超过32位的字段 @Id @GeneratedValue(generator = "UUID") private

    3.5K10

    碎片化 | 第四阶段-48-hibernate概述和配置-视频

    如清晰度低,可转PC网页观看高清版本: http://v.qq.com/x/page/h0567lzrhs1.html ---- ---- 版权声明:本视频、课件属本公众号作者所有,如有侵权,将追究法律责任...Hibernate提供了很多内置的主键生成器,可以在添加时自动生成主键值。...,eg:mysql、oracle 如果是mysql数据库,那么此时的主键生成策略则为identity 如果是oracle数据库,那么此时的主键生成策略为:sequence 4.increment 可以不给主键...ID进行set值,默认是使用数据表的主键ID最大值+1作为ID值 5.uuid/hilo 采用uuid或hilo算法生成一个主键值。...uuid生成一个字符串值 6.assigned 默认值。在进行添加操作时,程序员需要在代码中使用setXxx()设置主键值

    82960

    浅谈几种常见的分布式ID

    ❖ 优点 使用UUID作为主键具有以下优点: UUID值在表,数据库甚至在服务器上都是唯一的,允许您从不同数据库合并行或跨服务器分发数据库。...作为主键问题 UUID()函数产生的值,并不适合作为InnoDB引擎表的主键。因为格式无序,作为索引组织表存储会带来管理上的不小开销。...- UUID_TO_BIN()函数将UUID从人类可读格式(VARCHAR)转换成用于存储的紧凑格式(BINARY)格式 - BIN_TO_UUID()函数将UUID从紧凑格式(BINARY)转换为人类可读格式...例如在开源项目 Apache ShardingSphere 中可通过规则的配置,在其分片表中使用 NanoID作为主键生成器。...例如在开源项目 Apache ShardingSphere 中可通过规则的配置,在其分片表中使用 SnowFlake作为主键生成器。

    1.5K20

    数据库避坑指南:MySQL里那些常见的错误设计规范,你中了几个?

    主键的设计 错误的设计规范:主键建议使用自增 ID 值,不要使用 UUID,MD5,HASH,字符串作为主键 这个设计规范在很多文章中都能看到,自增主键的优点有占用空间小,有序,使用起来简单等优点。...因此,在并发场景中,更推荐 UUID 做主键或业务自定义生成主键。 我们可以直接在 MySQ L使用 UUID() 函数来获取 UUID 的值。...; 将字符串其转换为二进制值存储,空间最终从之前的 36 个字节缩短为了 16 字节。...此外,由于 UUID_TO_BIN 转换为的结果是16 字节,仅比自增 ID 增加 8 个字节,最后存储占用的空间也仅比自增大了 3G。...而且由于 UUID 能保证全局唯一,因此使用 UUID 的收益远远大于自增 ID。可能你已经习惯了用自增做主键,但是在并发场景下,更推荐 UUID 这样的全局唯一值做主键。

    1.1K20

    数据结构(ER数据库)设计规范 原

    MySql(InnoDB)索引特性 由于InnoDB的行数据排列是以主键数据(Oracle是ROW_ID)作为b+树索引,而扩展的索引都以主键索引作为数据对象——这种方式称为聚集索引。...如果直接使用UUID既充当物理主键又充当业务主键,由于 UUID并无法保障数据的递增性(?),会导数据碎片已经主键索引更新效率。...传统中间解决方案 基于Mysql目前也可以自动生成UUID,所以有一种中间解决方案是在分布式系统的数据库中物理主键使用Mysql的自增Sequence,逻辑主键使用UUID,所有的ER关联都使用UUID...如果将其转换为16进制或[0~9a~z]满表的36进制。长度还能极大的压缩。...此外如果并发并没有达到极高的程度时,可以让入口服务器来统一生成access_id作为后续业务新增数据时的主键,当然这也没法完全解决这个问题。

    1.6K30

    Mybatis-Plus基础功能测试使用

    主键生成策略 推荐阅读:分布式系统唯一id生成:https://www.cnblogs.com/haoxinyue/p/5208136.html 自3.3.0开始,默认使用雪花算法+UUID(不含中划线...其核心思想是:使用41bit作为毫秒数,10bit作为机器的ID(5个bit是数据中心,5个bit的机器ID),12bit作为毫秒内的流水号(意味着每个节点在每毫秒可以产生 4096 个 ID),最后还有一个符号位...ASSIGN_UUID 主键的数据类型必须是 String,自动生成 UUID 进行赋值 UUID 这需要你的id为String,也就是数据库id改为varchar类型。...现在叫ASSIGN_UUID 方法 主键生成策略 主键类型 说明 nextId ASSIGN_ID,ID_WORKER,ID_WORKER_STR Long,Integer,String 支持自动转换为...String类型,但数值类型不支持自动转换,需精准匹配,例如返回Long,实体主键就不支持定义为Integer nextUUID ASSIGN_UUID,UUID String 默认不含中划线的UUID

    89010

    ByteByteGo学习笔记:URL短链服务设计

    (图4 展示了一个简化的数据库表 URL_MAPPING 设计,包含三列:id (主键,自增ID), shortURL (短URL字符串), longURL (原始长URL字符串)。)...id (BIGINT, Primary Key, Auto Increment): 作为主键,使用自增的BIGINT类型,保证唯一性和高效索引。它不仅是表的主键,也将作为生成短URL的基础。...可以使用更复杂的ID生成策略,例如 UUID 或 分布式ID生成器(Snowflake 算法等),提高安全性。基数 62 转换方法是更适合URL短链服务的方案。...生成唯一ID: 调用分布式唯一ID生成器获取一个新的唯一ID。基数 62 转换: 将生成的唯一ID转换为基数 62 编码,得到 hashValue (短URL的后半部分)。...常见的分布式ID生成方案包括:UUID (Universally Unique Identifier): UUID 由算法生成,保证全局唯一性,但UUID通常较长,且无序,不适合作为短URL的一部分,但可以作为数据库表

    8900
    领券