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

mysql生成主键id

基础概念

MySQL中的主键(Primary Key)是表中的一个或多个字段,用于唯一标识表中的每一行数据。主键具有以下特性:

  1. 唯一性:主键的值在表中必须是唯一的,不允许有重复。
  2. 非空性:主键的值不能为空。
  3. 唯一索引:主键字段会自动创建一个唯一索引,以提高查询效率。

生成主键ID的方式

MySQL中生成主键ID主要有以下几种方式:

  1. 自增字段(AUTO_INCREMENT)
    • 这是最常用的方式,适用于大多数场景。
    • 定义方式:在创建表时,为主键字段添加AUTO_INCREMENT属性。
    • 定义方式:在创建表时,为主键字段添加AUTO_INCREMENT属性。
  • UUID
    • UUID(Universally Unique Identifier)是一种全局唯一的标识符,适用于分布式系统或需要跨数据库唯一性的场景。
    • 定义方式:使用CHAR(36)BINARY(16)类型,并手动插入UUID值。
    • 定义方式:使用CHAR(36)BINARY(16)类型,并手动插入UUID值。
    • 插入数据时:
    • 插入数据时:
  • 序列(Sequence)
    • MySQL本身不支持序列,但可以通过自定义函数或存储过程来实现类似的功能。
    • 适用于需要生成连续且唯一的ID的场景。
    • 适用于需要生成连续且唯一的ID的场景。

应用场景

  • 自增字段:适用于大多数单数据库实例的应用,简单易用。
  • UUID:适用于分布式系统、跨数据库唯一性要求高的场景。
  • 序列:适用于需要生成连续且唯一ID的场景,但实现相对复杂。

常见问题及解决方法

  1. 自增字段溢出
    • MySQL的自增字段类型为INT时,最大值为2147483647。当达到这个值后,再插入数据会报错。
    • 解决方法:将自增字段类型改为BIGINT,最大值为9223372036854775807。
    • 解决方法:将自增字段类型改为BIGINT,最大值为9223372036854775807。
  • UUID性能问题
    • UUID的长度较长(36个字符),插入和查询性能相对较低。
    • 解决方法:在应用层生成UUID,并在插入数据时手动指定。
  • 序列并发问题
    • 自定义序列在并发插入时可能会出现重复ID的问题。
    • 解决方法:使用数据库事务和锁机制来保证序列的唯一性。
    • 解决方法:使用数据库事务和锁机制来保证序列的唯一性。

参考链接

希望这些信息对你有所帮助!如果有更多问题,请随时提问。

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

相关·内容

基于Saas主键生成主键id

1.主键生成策略方式 ? 主键生成策略 2.基于Saas主键生成主键id流程 由于我们的系统时基于Saas的,因此生成主键时,需要以租户id(TenantId)为基础进行生成。...为了生成id符合我们的租户的要求,通常都会现将租户表建好,然后基于租户表中的租户id进行主键id生成。此时便产生基于租户id生成主键,那么怎样生成主键id呢?可以查看下图: ?...基于多租户生成方式 3.主键id生成实现的具体方式 首先需要对当前的id进行拦截操作,也即使用aop的切面Aspect对切点进行拦截,在进行新增的时候进行拦截: @Pointcut("execution...(* com.xtt..*.dao.mapper..*.insert*(..))") public void primaryKeyRule() {} 也就是说在进行主键生成时,我们拦截好需要生成主键...如果当前通过字节码拿到的声明方法getTenant,通过租户方法拿到租户id。拿到租户id后,就可以进行主键id获取了。

1.8K20
  • MySQL ORDER BY主键id加LIMIT限制走错索引

    背景及现象 report_product_sales_data表数据量2800万; 经测试,在当前数据量情况下,order by主键id,limit最大到49的时候可以用到索引report_product_sales_data_hq_code_orgz_id_index...,大于49时就走PRIMARY主键索引。...这边时,MySQL改变了执行计划,选择了PRIMARY主键索引               "clause": "ORDER BY",               "index_order_summary...在order by 主键id时,limit值的大小达到了某个临界值后,改变了执行计划,选择了主键索引,但不知道具体的规则究竟是怎样。...where 总结 在order by id的情况下,MySQL由于自身的优化器选择,为了避免某些排序的消耗,可能会走非预期的PRIMARY主键索引; order by 和 limit 结合使用,如果where

    1.8K10

    MySQL ORDER BY主键id加LIMIT限制走错索引

    背景及现象 report_product_sales_data表数据量2800万; 经测试,在当前数据量情况下,order by主键id,limit最大到49的时候可以用到索引report_product_sales_data_hq_code_orgz_id_index...,大于49时就走PRIMARY主键索引。...这边时,MySQL改变了执行计划,选择了PRIMARY主键索引 "clause": "ORDER BY", "index_order_summary...在order by 主键id时,limit值的大小达到了某个临界值后,改变了执行计划,选择了主键索引,但不知道具体的规则究竟是怎样。...where 总结 在order by id的情况下,MySQL由于自身的优化器选择,为了避免某些排序的消耗,可能会走非预期的PRIMARY主键索引; 对于数据量比较大,而且执行量很高的分页sql,尽可能将所有的查询字段包括在索引中

    6.7K32

    Mysql主主模式和主键id冲突问题

    Mysql双机热备,简单的说,就是要保持两台数据库的数据同步。始终保持两个数据库数据一致。 主要有主备方式、双主方式;,实现双主互备,双主都可以写入;实现简单的负载均衡。...问题描述:因为多主中都可以对服务器有写权限,所以设计到自增长重复问题 解决方法: 我们只要保证两台服务器上插入的自增长数据不同就可以了 如:A插入奇数ID,B插偶数ID,当然如果服务器多的话...auto_increment_offset = 1 auto_increment_increment = 2 这样A的auto_increment字段产生的数值是:1, 3, 5, 7, …等奇数ID...auto_increment_offset = 2 auto_increment_increment = 2 这样B的auto_increment字段产生的数值是:2, 4, 6, 8, …等偶数ID

    1.3K10

    MySQL中分库分表之后,ID主键的处理

    MySQL中分库分表之后,ID主键的处理 在大规模的应用系统中,为了应对数据量的增长和提高系统的可扩展性,通常会采用数据库分库分表的方案。...使用全局唯一ID(Global Unique Identifier, GUID) 全局唯一ID是一种不依赖于数据库自增机制的主键生成方案。...使用数据库自增ID和分片ID 另一种处理分库分表后ID主键的方案是结合数据库自增ID和分片ID。分片ID是根据拆分规则生成的,用于标识数据在哪个分片中。...在每个分片中,使用数据库的自增ID生成主键。 使用数据库自增ID和分片ID的方案相对简单,但需要保证分片ID的正确性和一致性,并且需要在查询时考虑分片的路由。...总结 在MySQL的分库分表方案中,ID主键的处理是一个重要的问题。本文介绍了几种常见的处理方案,包括使用全局唯一ID、分布式唯一ID生成算法和结合数据库自增ID和分片ID

    94910

    Mybatis-Plus3.0默认主键策略导致自动生成19位长度主键id的坑

    底层ORM框架用的是Mybatis-Plus,我寻思了一下,这看起来像是在插入数据库旧自动生成id,导致并非默认使用MySql的自增AUTO_INCREMENT的id。...19的数字当做该条数据的id插入到MySql,导致虽然MySql表设置了自增,但被该1468844351843872769影响了,导致下一条数据自动递增值变成了1468844351843872770,这种过长的...[image.png] 到这里,就确定,这个长数字的id,是在代码层次就自动生成了,最后进入对应的实体类中,发现该映射数据表的id字段,并没有显示设置对应的主键生成策略。...; ...... } Mybatis-Plus主要有以下几种主键生成策略—— @Gette public enum IdType { /* * 数据库ID自增...", type = IdType.INPUT) private Long id; ...... } 百度网上的说法,当Mybatis-Plus实体类没有显示设置主键策略时,将默认使用雪花算法生成

    5.4K130

    MyBatisPlus 主键ID生产规则

    在MyBatis-Plus中,主键ID生成规则可以通过注解或配置文件进行配置。以下是常见的主键ID生成规则: 自增主键(AUTO_INCREMENT):使用数据库的自增特性生成主键ID。...在MySQL中,可以使用@TableId(type = IdType.AUTO)注解或配置文件中的idType = AUTO来指定该规则。 UUID主键:使用UUID(通用唯一标识符)生成主键ID。...雪花算法主键(Snowflake):使用Twitter的雪花算法生成分布式唯一ID。...在MySQL中,可以使用@TableId(type = IdType.ASSIGN_ID)注解或配置文件中的idType = ASSIGN_ID来指定该规则。...自定义主键生成策略:可以通过实现IdentifierGenerator接口来自定义主键生成策略。在自定义的主键生成策略中,你可以根据自己的需求生成唯一的主键ID,并将其应用于实体类的主键字段。

    1.2K30

    面试官竟然问我订单ID是怎么生成的?难道不是MySQL自增主键

    开始面试了,你知道订单ID是怎么生成的吗? 啥?订单ID怎么生成?美女怎么不按套路出牌!HashMap实现原理,我已经倒背如流,你不问。瞎问什么订单ID。 我: 还能咋生成?用数据库主键自增呗。...数据库主键顺序自增,每天有多少订单量被竞争对手看的一清二楚,商业机密都暴露了。 况且单机MySQL只能支持几百量级的并发,我们公司每天千万订单量,hold不住啊。...我: 既然MySQL的并发量不行,我们是不是可以提前从MySQL获取一批自增ID,加载到本地内存中,然后从内存中并发取,这并发性能岂不是杠杠滴。 面试官: 你还挺上道,这种叫号段模式。...32位字符串会占用更大的空间,无序的字符串作数据库主键,每次插入数据库的时候,MySQL为了维护B+树结构,需要频繁调整节点顺序,影响性能。况且字符串太长,也没有任何业务含义,pass。...数值且有序递增:数值占用的空间更小,有序递增能保证插入MySQL的时候更高性能。 嵌入业务含义:如果订单ID里面能嵌入业务含义,就能通过订单ID知道是哪个业务线生成的,便于排查问题。

    1.9K31

    插件推荐 - twitter分布式主键id生成器与SID

    推荐一个插件,那就是idworker,用了一年了,还是挺好用,先来说说干嘛的吧,鉴于现在主键生成模式先来探讨一下 1、id自增:比较普遍,但是在数据备份恢复的时候,容易出错,只适用于小数据量的表,或者小型后台管理系统...2、uuid:uuid可以保证不重复,但是不建议使用,理由是实在太长了,一窜字符串不人性化,uuid适合token,据我所知,我一朋友的公司的部分项目的所有id都是使用的uuid,鉴于是个大型erp,...也就无所谓了... 3、时间戳+随机数字:比较简单的做法,可以这么做,但是不建议大型系统使用 4、使用redis自增,这样就需要搭建单独的一个id服务器,每次id使用后就要+1,由于redis是单线程的...生成器,非常好用,可以分布式部署,也能直接使用,非常方便,可以说基本上不会发生id重复的情况,而id看似也很人性化 这是正在使用的订单表id,可以看出,id为16位,外加10位sid,sid是simple...这是腾讯天天快报的主键,可以看到也是同样的做法,由此可证,非常实用 ? 看看用法: 首先你要在spring配置文件中声明,这样表示他是个单例,idworker要在单例下使用,不然id会重复 ?

    1.6K60

    Mysql为何建议使用自增id主键,有什么优点

    如果插入的值比最大值id大,则只需要最后记录后面插入一个新记录。如果新插入的ID值在原先的有序中间,就相对麻烦了,需要逻辑上挪动后面的数据,空出位置。...插入新记录的时候可以不指定 ID 的值,系统会获取当前 ID 最大值加 1 作为下一条记录的 ID 值。 也就是说,自增主键的插入数据模式,正符合了递增插入的场景。...假设你的表中确实有一个唯一字段,比如字符串类型的身份证号,那应该用身份证号做主键,还是用自增字段做主键呢? 由于每个非主键索引的叶子节点上都是主键的值。...InnoDB使用的是聚簇索引,将主键组织到一棵B+树中,而行数据就储存在叶子节点上,若使用"where id = xxx"这样的条件查找主键,则按照B+树的检索算法便可查找到对应的叶节点,以后得到行数据...所以,对于InnoDB表,咱们通常都会定义一个自增的ID列为主键 更新主键的代价很高,由于将会致使被更新的行移动。所以,对于InnoDB表,咱们通常定义主键为不可更新。

    2K31
    领券