select * 与select 字段返回结果条数不一致

【 TiDB 使用环境】测试
【 TiDB 版本】V5.4.0
【复现路径】
CREATE TABLE test (
col1 bigint(20) NOT NULL COMMENT ‘资源同步序号’,
col2 varchar(36) NOT NULL COMMENT ‘IOMS唯一设备通道ID’,
col3 int(11) DEFAULT NULL COMMENT ‘设备通道标记1设备,2通道’,
col4 varchar(36) NOT NULL COMMENT ‘同步的设备ID’,
col5 varchar(255) DEFAULT NULL COMMENT ‘设备名称’,
modify_time bigint(20) DEFAULT NULL,
create_time bigint(20) DEFAULT NULL,
col6 json DEFAULT NULL COMMENT ‘同步的属性’,
col7 json DEFAULT NULL COMMENT ‘自定义的属性’,
col8 json GENERATED ALWAYS AS (json_merge_patch(ifnull(col6, _utf8mb4’{}‘), ifnull(col7, _utf8mb4’{}‘))) STORED,
col9 varchar(36) GENERATED ALWAYS AS (left(json_unquote(json_extract(col8, _utf8mb4’$.col9[0]‘)), 36)) VIRTUAL,
col10 varchar(30) GENERATED ALWAYS AS (left(json_unquote(json_extract(col8, _utf8mb4’$.col10’)), 30)) VIRTUAL,
KEY dev_idx1 (col4,col1,col10,col3,col5),
KEY dev_idx2 (col3,col1,col9)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

INSERT INTO test VALUES (-100000000, ‘123459789332’, 1, ‘123459789332’, ‘AAAAA’, 1675871871, 1675760995, ‘{"col10": "CCCCC", "col9": ["ABCDEFG"]}’, ‘{"col10": "DDDDD", "col9": ["abcdefg"]}’, DEFAULT, DEFAULT, DEFAULT);
INSERT INTO test VALUES (-100000000, ‘123459789332’, 1, ‘123459789332’, ‘BBBBB’, 1675908861, 1675908861, ‘{"col10": "CCCCC", "col9": ["ABCDEFG"]}’, NULL, DEFAULT, DEFAULT, DEFAULT);
INSERT INTO test VALUES (0, ‘123459789332’, 1, ‘123459789332’, ‘AAAAA’, 1675956409, 1675908882, ‘{"col10": "CCCCC", "col9": ["ABCDEFG"]}’, ‘{"col10": "DDDDD","col9": ["abcdefg"]}’, DEFAULT, DEFAULT, DEFAULT);
INSERT INTO test VALUES (-100000000, ‘123459789332’, 1, ‘123459789332’, ‘BBBBB’, 1675871896, 1675871896, ‘{"col10": "CCCCC","col9": ["ABCDEFG"]}’, NULL, DEFAULT, DEFAULT, DEFAULT);
INSERT INTO test VALUES (-100000000, ‘123459789332’, 1, ‘123459789332’, ‘AAAAA’, 1675908836, 1675871916, ‘{"col10": "CCCCC","col9": ["ABCDEFG"]}’, ‘{"col10": "DDDDD","col9": ["abcdefg"]}’, DEFAULT, DEFAULT, DEFAULT);

UPDATE test SET col7 = ‘{“col10”:“DDDDD”,“col9”:[“abcdefg”]}’ WHERE col2 = ‘123459789332’;
UPDATE test SET col1 = -100000000 WHERE col4 = ‘123459789332’;
DELETE FROM test WHERE col1 < 0;

select * from test; --返回0条
select col4,col1 from test; --返回2条

【遇到的问题:问题现象及影响】
更新数据后,全表查询返回的结果不一致。
这个是因为虚拟列导致的bug吗?
如果需要使用虚拟列,有什么办法可以避免这种问题?

【资源配置】
【附件:截图/日志/监控】


这么神奇,我在V6.4里面也可以重现 :rofl:

好 bug~~ :+1: :+1: :+1:

select * from test use index(dev_idx1);
ERROR 8133 (HY000): data inconsistency in table: test, index: dev_idx1, index-count:2 != record-count:0

数据和索引不一致拉。

https://docs.pingcap.com/zh/tidb/stable/troubleshoot-data-inconsistency-errors
image

解决办法:重建索引 :grinning: 已测

小表还行,大表重建索引代价也太大了。。。

重建索引后如果还有类似的update,就还会导致这个问题。 :joy:

之前在Oracle数据库里面也遇到过一次这种情况,也是重建索引。
TiDB这能重现,可以提bug让开发好好分析下拉。

大佬,能发下表结构,及sql语句嘛,楼主的sql 语句好像有点问题

索引数据不一致复现.sql (2.4 KB)
单双引号是中文的原因。查看我的附件。

重建索引

想看下表结构哈 , 好东西

有学到一招

这个BUG需要关注一下,预防问题复现。

重建索引解决

针对这种索引与数据不一致的bug的问题,可否增加些定时任务,定期检查索引、数据的一致性。若不一致则自动修复?或者在 dashboard 的集群诊断增加对索引、数据一致性的诊断,以启用用户手动校验索引与数据?

还是想知道出现这种问题的原因,如果是数据有损坏,怎么处理呢?

admin cleanup INDEX test dev_idx1;

admin cleanup INDEX test dev_idx2;

也可以解决,但是感觉和重建索引区别不大。大表依然会很慢。

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。