为什么使用AUTO_RANDOM产生的唯一数的位数长短不固定

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:

【概述】 场景 + 问题概述
表的主键为bigint(20)类型,采用 AUTO_RANDOM(5)生产随机数。正常会产生一个19位的随机数,但是当insert并发量加大时会产生低于19位的随机数,已经发现出现2位和3位数的随机数。

【背景】 做过哪些操作

【现象】 业务和数据库现象

【问题】 当前遇到的问题

【业务影响】

【TiDB 版本】
v4.0.11

【应用软件及版本】

【附件】 相关日志及配置信息

  • TiUP Cluster Display 信息
  • TiUP CLuster Edit config 信息

监控(https://metricstool.pingcap.com/)

  • TiDB-Overview Grafana监控
  • TiDB Grafana 监控
  • TiKV Grafana 监控
  • PD Grafana 监控
  • 对应模块日志(包含问题前后 1 小时日志)

若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

1赞

出现 2位 或者 3 位的随机数帮忙确认一下是否都是通过 auto radom 写入的,auto random 应该是顺序写入的。https://docs.pingcap.com/zh/tidb/stable/auto-random#auto_random-span-classversion-mark从-v310-版本开始引入span

1赞

请注意检查是否存在显式插入

1赞

这个可以排除,我创建一个新表,然在同一个会话insert同一个sql也复现了这个问题。sql语句是不带主键ID的,sql类似下面这种:INSERT INTO sms_test (a,b,c)
VALUES
(1000000,‘N’,‘Y’),
(1000000,‘N’,‘Y’),
(1000000,‘N’,‘Y’);

1赞

能否提供可重现的建表语句以及验证脚本

1赞

CREATE TABLE sms_invoice_test1 (
org_id bigint(11) NOT NULL,
is_delete varchar(1) NOT NULL,
is_active varchar(1) NOT NULL,
created datetime NOT NULL,
createdby varchar(64) NOT NULL,
updated datetime NOT NULL,
updatedby varchar(64) NOT NULL,
ID bigint(20) NOT NULL /*T![auto_rand] AUTO_RANDOM(5) */,
invoice_no varchar(32) NOT NULL,
doc_type varchar(3) NOT NULL,
status varchar(2) NOT NULL,
is_posted varchar(1) NOT NULL,
version bigint(10) DEFAULT NULL,
date_acct datetime NOT NULL,
bpartner_code varchar(32) DEFAULT NULL,
bill_bpartner_code varchar(32) DEFAULT NULL,
grand_total decimal(32,2) NOT NULL,
currency_code varchar(3) NOT NULL,
remark varchar(500) DEFAULT NULL,
multiply_rate decimal(16,4) DEFAULT NULL,
conversion_type_code varchar(32) DEFAULT NULL,
recharge_no varchar(32) DEFAULT NULL,
bpartner_name varchar(200) DEFAULT NULL,
MOD_VALUE bigint(2) DEFAULT NULL,
PRIMARY KEY (ID),
KEY idx_sms_invoice_007 (created),
KEY idx_sms_invoice_006 (updated),
KEY ind_invoice_date_acct1 (date_acct),
KEY ind_doc_type (doc_type,is_delete,is_active,date_acct),
KEY ind_invoice_doc_type (bpartner_code,doc_type),
KEY idx_sms_invoice_003 (invoice_no),
KEY idx_sms_invoice_005 (doc_type,status,is_posted),
KEY ind_invoice_date_acct (doc_type,date_acct),
KEY idx_sms_invoice_004 (recharge_no)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin /*T![auto_rand_base] AUTO_RANDOM_BASE=60001 */

1赞

INSERT INTO sms_invoice_test1
( org_id ,
is_delete ,
is_active ,
created ,
createdby ,
updated ,
updatedby ,
invoice_no ,
doc_type ,
status ,
is_posted,
version ,
date_acct ,
bpartner_code ,
bill_bpartner_code ,
grand_total ,
currency_code ,
remark ,
multiply_rate ,
conversion_type_code,
recharge_no ,
bpartner_name ,
MOD_VALUE )
VALUES
(1000000,‘N’,‘Y’,‘2021-05-01 00:00:00’,‘system’,‘2021-05-01 00:00:00’,‘system’,‘ARI1521646612’,‘ARI’,‘CO’,‘Y’,NULL,‘2021-05-01 00:00:00’,‘1000069’,NULL,-0.32,‘EUR’,‘自动生成’,1.2134,‘114’,NULL,‘ss’,2),
(1000000,‘N’,‘Y’,‘2021-04-30 23:59:59’,‘system’,‘2021-04-30 23:59:59’,‘system’,‘ARI1521646613’,‘ARI’,‘CO’,‘Y’,NULL,‘2021-04-30 00:00:00’,‘10005909’,NULL,0.10,‘GBP’,‘自动生成’,1.3953,‘114’,NULL,‘ww’,3),
(1000000,‘N’,‘Y’,‘2021-04-30 23:59:59’,‘system’,‘2021-04-30 23:59:59’,‘system’,‘ARI1521646614’,‘ARI’,‘CO’,‘Y’,NULL,‘2021-04-30 00:00:00’,‘1000069’,NULL,-0.20,‘EUR’,‘自动生成’,1.2134,‘114’,NULL,‘ss’,4),
(1000000,‘N’,‘Y’,‘2021-04-30 23:59:59’,‘system’,‘2021-04-30 23:59:59’,‘system’,‘ARI1521646615’,‘ARI’,‘CO’,‘Y’,NULL,‘2021-04-30 00:00:00’,‘1000239’,NULL,0.10,‘GBP’,‘自动生成’,1.3953,‘114’,NULL,‘ss’,5),
(1000000,‘N’,‘Y’,‘2021-04-30 23:59:59’,‘system’,‘2021-04-30 23:59:59’,‘system’,‘ARI1521646616’,‘ARI’,‘CO’,‘Y’,NULL,‘2021-04-30 00:00:00’,‘1000239’,NULL,1.97,‘GBP’,‘自动生成’,1.3953,‘114’,NULL,‘ss’,6),
(1000000,‘N’,‘Y’,‘2021-04-30 23:59:59’,‘system’,‘2021-04-30 23:59:59’,‘system’,‘ARI1521646617’,‘ARI’,‘CO’,‘Y’,NULL,‘2021-04-30 00:00:00’,‘1000069’,NULL,-0.20,‘EUR’,‘自动生成’,1.2134,‘114’,NULL,‘ss’,7),
(1000000,‘N’,‘Y’,‘2021-04-30 23:59:59’,‘system’,‘2021-04-30 23:59:59’,‘system’,‘ARI1521646618’,‘ARI’,‘CO’,‘Y’,NULL,‘2021-04-30 00:00:00’,‘1000239’,NULL,-0.07,‘GBP’,‘自动生成’,1.3953,‘114’,NULL,‘ss’,8),
(1000000,‘N’,‘Y’,‘2021-04-30 23:59:59’,‘system’,‘2021-04-30 23:59:59’,‘system’,‘ARI1521646619’,‘ARI’,‘CO’,‘Y’,NULL,‘2021-04-30 00:00:00’,‘1000069’,NULL,-0.93,‘EUR’,‘自动生成’,1.2134,‘114’,NULL,‘ss’,9),
(1000000,‘N’,‘Y’,‘2021-04-30 23:59:59’,‘system’,‘2021-04-30 23:59:59’,‘system’,‘ARI1521646620’,‘ARI’,‘CO’,‘Y’,NULL,‘2021-04-30 00:00:00’,‘1000069’,NULL,-0.26,‘EUR’,‘自动生成’,1.2134,‘114’,NULL,‘ww’,0),
(1000000,‘N’,‘Y’,‘2021-04-30 23:59:59’,‘system’,‘2021-04-30 23:59:59’,‘system’,‘ARI1521646621’,‘ARI’,‘CO’,‘Y’,NULL,‘2021-04-30 00:00:00’,‘1000069’,NULL,-0.05,‘EUR’,‘自动生成’,1.2134,‘114’,NULL,‘ww’,1),
(1000000,‘N’,‘Y’,‘2021-04-30 23:59:59’,‘system’,‘2021-04-30 23:59:59’,‘system’,‘ARI1521646622’,‘ARI’,‘CO’,‘Y’,NULL,‘2021-04-30 00:00:00’,‘1000069’,NULL,-0.64,‘EUR’,‘自动生成’,1.2134,‘114’,NULL,‘ww’,2),
(1000000,‘N’,‘Y’,‘2021-04-30 23:59:59’,‘system’,‘2021-04-30 23:59:59’,‘system’,‘ARI1521646623’,‘ARI’,‘CO’,‘Y’,NULL,‘2021-04-30 00:00:00’,‘1000239’,NULL,-0.07,‘GBP’,‘自动生成’,1.3953,‘114’,NULL,‘aa’,3),
(1000000,‘N’,‘Y’,‘2021-04-30 23:59:59’,‘system’,‘2021-04-30 23:59:59’,‘system’,‘ARI1521646624’,‘ARI’,‘CO’,‘Y’,NULL,‘2021-04-30 00:00:00’,‘1000239’,NULL,0.10,‘GBP’,‘自动生成’,1.3953,‘114’,NULL,‘aa’,4),
(1000000,‘N’,‘Y’,‘2021-04-30 23:59:59’,‘system’,‘2021-04-30 23:59:59’,‘system’,‘ARI1521646625’,‘ARI’,‘CO’,‘Y’,NULL,‘2021-04-30 00:00:00’,‘1000069’,NULL,-0.10,‘EUR’,‘自动生成’,1.2134,‘114’,NULL,‘ww’,5),
(1000000,‘N’,‘Y’,‘2021-04-30 23:59:59’,‘system’,‘2021-04-30 23:59:59’,‘system’,‘ARI1521646617’,‘ARI’,‘CO’,‘Y’,NULL,‘2021-04-30 00:00:00’,‘1000069’,NULL,-0.20,‘EUR’,‘自动生成’,1.2134,‘114’,NULL,‘ss’,7),
(1000000,‘N’,‘Y’,‘2021-04-30 23:59:59’,‘system’,‘2021-04-30 23:59:59’,‘system’,‘ARI1521646618’,‘ARI’,‘CO’,‘Y’,NULL,‘2021-04-30 00:00:00’,‘1000239’,NULL,-0.07,‘GBP’,‘自动生成’,1.3953,‘114’,NULL,‘ss’,8),
(1000000,‘N’,‘Y’,‘2021-04-30 23:59:59’,‘system’,‘2021-04-30 23:59:59’,‘system’,‘ARI1521646619’,‘ARI’,‘CO’,‘Y’,NULL,‘2021-04-30 00:00:00’,‘1000069’,NULL,-0.93,‘EUR’,‘自动生成’,1.2134,‘114’,NULL,‘ss’,9),
(1000000,‘N’,‘Y’,‘2021-04-30 23:59:59’,‘system’,‘2021-04-30 23:59:59’,‘system’,‘ARI1521646620’,‘ARI’,‘CO’,‘Y’,NULL,‘2021-04-30 00:00:00’,‘1000069’,NULL,-0.26,‘EUR’,‘自动生成’,1.2134,‘114’,NULL,‘ww’,0),
(1000000,‘N’,‘Y’,‘2021-04-30 23:59:59’,‘system’,‘2021-04-30 23:59:59’,‘system’,‘ARI1521646621’,‘ARI’,‘CO’,‘Y’,NULL,‘2021-04-30 00:00:00’,‘1000069’,NULL,-0.05,‘EUR’,‘自动生成’,1.2134,‘114’,NULL,‘ww’,1),
(1000000,‘N’,‘Y’,‘2021-04-30 23:59:59’,‘system’,‘2021-04-30 23:59:59’,‘system’,‘ARI1521646622’,‘ARI’,‘CO’,‘Y’,NULL,‘2021-04-30 00:00:00’,‘1000069’,NULL,-0.64,‘EUR’,‘自动生成’,1.2134,‘114’,NULL,‘ww’,2),
(1000000,‘N’,‘Y’,‘2021-04-30 23:59:59’,‘system’,‘2021-04-30 23:59:59’,‘system’,‘ARI1521646623’,‘ARI’,‘CO’,‘Y’,NULL,‘2021-04-30 00:00:00’,‘1000239’,NULL,-0.07,‘GBP’,‘自动生成’,1.3953,‘114’,NULL,‘aa’,3),
(1000000,‘N’,‘Y’,‘2021-04-30 23:59:59’,‘system’,‘2021-04-30 23:59:59’,‘system’,‘ARI1521646624’,‘ARI’,‘CO’,‘Y’,NULL,‘2021-04-30 00:00:00’,‘1000239’,NULL,0.10,‘GBP’,‘自动生成’,1.3953,‘114’,NULL,‘aa’,4),
(1000000,‘N’,‘Y’,‘2021-04-30 23:59:59’,‘system’,‘2021-04-30 23:59:59’,‘system’,‘ARI1521646625’,‘ARI’,‘CO’,‘Y’,NULL,‘2021-04-30 00:00:00’,‘1000069’,NULL,-0.10,‘EUR’,‘自动生成’,1.2134,‘114’,NULL,‘ww’,5),
(1000000,‘N’,‘Y’,‘2021-04-30 23:59:59’,‘system’,‘2021-04-30 23:59:59’,‘system’,‘ARI1521646626’,‘ARI’,‘CO’,‘Y’,NULL,‘2021-04-30 00:00:00’,‘10005909’,NULL,0.06,‘GBP’,‘自动生成’,1.3953,‘114’,NULL,‘zz’,6);

1赞

不停地重复执行这条sql。

1赞

已重现,但是未出现5位以下的ID值。根据官方文档说明,感觉这里是正常的。值的位数范围应该是在5-20之间。

1赞

把这块拿掉试试。按官方文档5位是固定,后面是字段增长的,应该至少要大于5位。

我设置是AUTO_RANDOM(5)

Hi ~ 又确认了一下,理论上是有可能出现 2、3 位数的情况,但是有一定的概率。计算 shard 是一个取 hash 的过程,可以认为是随机的吧。如果想要顺序写入唯一值,可以按照时间构建。

跟文档的说法有很大出入,我认为是tidb bug。

如果需要一个顺序的 ID,目前建议通过业务程序写入一个字段,并维护这个字段的顺序性和唯一性。