数据库自增主键可能产生的问题

简介:

在MySQL中经常会配置自增长属性的字段作为主键,特别是使用InnoDB存储引擎,

因为InnoDB的聚集索引的特性,使用自增长属性的字段当主键性能更好,但是使用自增主键也可能会带来一些问题。
举个例子,使用自增主键对数据库做分库分表,可能出现一些诸如主键重复等的问题,或者在数据库导入的时候,可能会因为主键出现一些问题。

主要业务表的主键应该配置一个合理的策略,尽量避免自增AUTO_INCREMENT。

针对主键自增可能产生的问题,下面这两篇文章有相关的讨论:

INNODB自增主键的一些问题
mysql自增列导致主键重复问题分析

>>针对主键增长方式的解决方案

来自知乎问题-高并发网站如何解决数据库主键自增的时候出现重复?

(1)设置主键自增为何不可取
这样的话,数据库本身是单点,不可拆库,因为id会重复。

(2)依赖数据库自增机制达到全局ID唯一
使用如下语句:
REPLACE INTO Tickets64 (stub) VALUES ('a'); 
SELECT LAST_INSERT_ID();
这样可以保证全局ID唯一,但这个Tickets64表依旧是个单点。

(3)依赖数据库自增机制达到全局ID唯一并消除单点
在2的基础上,部署两个(多个)数据库实例,
设置自增步长为2(多个则为实例数),即auto-increment-increment = 2
设置auto-increment-offset分别为1,2.....
这样第一台数据库服务器的自增id为 1 3 5 7 9
第二台为2 4 6 8 10

(4)解决每次请求全局ID都读库写库压力过大的问题
比如第一次启动业务服务,会请求一个唯一id为3559
如果是2、3的方法,则id为3559,这样每次都请求数据库,对数据库压力比较大
可以用3559 * 65536(举个例子,并不一定是65536)+ 内存自增变量来作为id
当内存自增变量到达65535时,从数据库重新获取一个自增id
这样即使有多台业务服务器,id也不会重复:
第一台 3559 * 65536 + 1,2,3.....65535
第二台 3560 * 65536 + 1,2,3.....65535
然后第一台到65535了,换一个数据库自增id,这时候可能是3561 * 65536 + 1,2,3....

 


目录
相关文章
|
8月前
|
算法 NoSQL 关系型数据库
数据库主键一定要自增吗?有哪些场景不建议自增?
数据库主键一定要自增吗?有哪些场景不建议自增?
283 0
|
8月前
|
数据库 OceanBase
在OceanBase数据库中,当使用主键自增功能插入一条带有主键的数据
在OceanBase数据库中,当使用主键自增功能插入一条带有主键的数据
1126 1
|
10月前
|
算法 关系型数据库 MySQL
数据库主键
数据库主键
102 0
|
Oracle 关系型数据库 MySQL
数据库中设置列/字段自增
介绍数据库中设置列/字段自增(Oracle和Mysql)的实现方式
数据库中设置列/字段自增
|
SQL 测试技术 数据库
Navicat使自增主键归1
截断表:可以用于删除表中的所有数据。 截断表命令还会回收所有索引的分配页。
194 0
Navicat使自增主键归1
|
存储 安全 关系型数据库
Mysql表创建,约束,主键,存储引擎的使用
1.约束概述 约束的作用就是保证表中的数据有效 分类: 非空约束 not null(表中数据不能为NULL) 唯一性约束 unique (约束的字段不能重复,但是可以为NULL,也就是NULL可以重复) 主键约束 primary key (主键不能为NULL,同时不可以重复) 外键约束 foreign key 检查约束 check(Mysql不支持) 联合唯一性:🎈
113 0
|
XML 数据库 数据格式
数据库报错!外键问题。
数据库报错!外键问题。
72 0
|
Java 关系型数据库 测试技术
数据库是否应该使用外键约束?
数据库是否应该使用外键约束?
208 0
数据库是否应该使用外键约束?
|
关系型数据库 MySQL 数据库
MySQL初级篇——数据库中表的主键、外键及常用约束
MySQL初级篇——数据库中表的主键、外键及常用约束
|
数据库 索引
数据库中的主键、外键、索引的区别
数据库中的主键、外键、索引的区别
391 1