in 子查询执行计划错误

【 TiDB 版本】
7.1.1 / 7.1.0

问题:in 子查询执行计划错误,实际结果与返回结果不一致

  1. 建表:
CREATE TABLE `in_test` (
  `id` bigint(20) unsigned NOT NULL ,
  `name` varchar(45) NOT NULL,
  `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ,
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`) /*T![clustered_index] CLUSTERED */,
  KEY `inx_name` (`name`),
  KEY `idx_create_time` (`create_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin 
PARTITION BY HASH (`id`) PARTITIONS 128; 
  1. 插入数据
insert into in_test(id,name) 
values(6700402571,'张三'),(1624923463,'李四'),(5837848666,'王五'),(6542259574,'赵六');
  1. 查询语句
select id,
       `name`
from `in_test`
where id in
      (1624923463, 1624923463, 5837848666, 5837848666, 6700402571, 6700402571, 6542259574,6542259574);
  1. v7.1.1 执行计划(错误返回)
id               |estRows|actRows|task|access object                            |execution info                                                                                                                                                                                                                                             |operator info                                                                                                                 |memory|disk|
-----------------+-------+-------+----+-----------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------+------+----+
Batch_Point_Get_1|8.00   |1      |root|table:in_test, partition:p11,p71,p90,p118|time:918.7µs, loops:2, RU:0.500977, BatchGet:{num_rpc:2, total_time:1.58ms}, tikv_wall_time: 988.5µs, scan_detail: {total_process_keys: 1, total_process_keys_size: 64, total_keys: 4, get_snapshot_time: 617.1µs, rocksdb: {block: {cache_hit_count: 25}}}|handle:[1624923463 1624923463 5837848666 5837848666 6700402571 6700402571 6542259574 6542259574], keep order:false, desc:false|N/A   |N/A |
  1. v6.5.2 执行计划(正确返回)
id               |estRows|actRows|task|access object                            |execution info                                                                                                                                                                                                            |operator info                                                                                                                 |memory|disk|
-----------------+-------+-------+----+-----------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------+------+----+
Batch_Point_Get_1|8.00   |4      |root|table:in_test, partition:p11,p71,p90,p118|time:2.66ms, loops:2, BatchGet:{num_rpc:4, total_time:6.66ms}, tikv_wall_time: 1.48ms, scan_detail: {total_process_keys: 4, total_process_keys_size: 256, total_keys: 4, get_snapshot_time: 217.9µs, rocksdb: {block: {}}}|handle:[1624923463 1624923463 5837848666 5837848666 6700402571 6700402571 6542259574 6542259574], keep order:false, desc:false|N/A   |N/A |

你指的actrows 不对么?

我再7.1.1上试了下:
image
in条件里同一个值重复一遍,结果就变了。。。

是的,实际返回也不对,正确应该返回4行,实际只返回了1行

是的,7.1.0以前的版本没有这个问题,应该是7.1.0引入的

我的是 7.1.0
没有问题呀

v7.0.0


v7.1.0

可以截图看一下么?你可以看看我的截图

稍等,我截图

我在sqlyog 上跑 没问题
在黑屏,命令行,就有问题了

image


不能用第三方软件执行呢,对sql可能会有处理,需要使用客户端执行


黑屏 命令行执行,就有问题了

提bug吧 :joy:

看起来是bug 关于分区表分区值查询bug似乎不少

应该是BUG,可以创建非聚簇索引表试试能否先绕过。

是的,非聚簇表没有问题

执行了一下 ,竟然复现了,难以理解,难以理解,坐等官方结论

我反馈一下!

1 个赞

看到相关 issue 了:https://github.com/pingcap/tidb/issues/46779

2 个赞