where条件中in()分区表,不选定分区字段会出现查询不到的情况

【 TiDB 使用环境】生产环境 & 测试
【 TiDB 版本】V7.5.1
【复现路径】
sql: SELECT * FROM anno WHERE id IN (2306162990490667171,2306162990490667175,2306162990490667170)

explain analyze:
Batch_Point_Get_1 3.00 0 root table:anno time:699.7碌s, loops:1, RU:1.800000, BatchGet:{num_rpc:3, total_time:1.6ms}, tikv_wall_time: 526.6碌s, scan_detail: {total_keys: 3, get_snapshot_time: 52.8碌s, rocksdb: {block: {cache_hit_count: 22}}} handle:[2306162990490667171 2306162990490667175 2306162990490667170], keep order:false, desc:false N/A N/A

【遇到的问题:问题现象及影响】
在ID是主键的情况下:
1、使用该sql无法查询到该有的数据
2、用等于号可以查到
3、用in()的同时,限定分区可以查到

对于分区表,全局索引不生效么?是否有官方文档对此进行了说明?

DDL:
CREATE TABLE annotate (
id bigint(20) NOT NULL /*T![auto_rand] AUTO_RANDOM(5) */ COMMENT ‘主键ID’,
task_subject_id bigint(20) DEFAULT NULL COMMENT ‘题目ID’,
data_id bigint(20) DEFAULT NULL COMMENT ‘对应数据表id’,
project_id bigint(20) NOT NULL COMMENT ‘项目ID’,
task_id bigint(20) DEFAULT NULL COMMENT ‘任务ID’,
data json NOT NULL COMMENT ‘标注记录’,
operator_id bigint(20) DEFAULT NULL COMMENT ‘操作员’,
type tinyint(2) NOT NULL DEFAULT ‘0’ COMMENT ‘结果状态:0 = 标注,1 = 返修(从1开始往后都表示返修)’,
is_delete tinyint(3) NOT NULL DEFAULT ‘0’ COMMENT ‘逻辑删除’,
create_time datetime NOT NULL COMMENT ‘创建时间’,
update_time datetime NOT NULL COMMENT ‘更新时间’,
record_type tinyint(2) NOT NULL COMMENT ‘结果类型:1 = 全局标签记录,2 = 标注记录 3组框 4跳过’,
feature_id bigint(20) DEFAULT NULL COMMENT ‘标签ID’,
source_type tinyint(2) NOT NULL DEFAULT ‘0’ COMMENT ‘来源:0=平台创建,1=导入预标注,2=自动生成标注结果,3=模型生成’,
project_subject_id bigint(20) DEFAULT NULL COMMENT ‘项目题目ID’,
frame_id bigint(20) NOT NULL DEFAULT ‘-1’ COMMENT ’ 帧数据id或者任务题目id(题目级结果时存储题目id)',
source_model_id bigint(20) DEFAULT NULL COMMENT ‘标注结果来源模型版本ID’,
confidence_level float(4,2) unsigned DEFAULT NULL COMMENT ‘置信度’,
PRIMARY KEY (id) /*T![clustered_index] CLUSTERED */,
KEY nk_task_subject_id (task_subject_id),
KEY nk_project_id (project_id),
KEY nk_project_subject_id (project_subject_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci /*T![auto_rand_base] AUTO_RANDOM_BASE=319981226791556 */
PARTITION BY HASH (project_id) PARTITIONS 64;

表结构发一下,另外这个表上有tiflash副本吗?

DDL原文已追加,没有tifalsh

7.5可以支持分区表字段不在主键里面了?怪不得你的执行计划我看着都怪。。。里面一点涉及分区的信息都没

应该是不能,我是先建表,然后alter分的区

你单独执行id=的sql的执行计划发下看看

id |estRows|actRows|task |access object |execution info |operator info |memory |disk|
------------------±------±------±--------±-------------±--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------±-------------------------------------------------------------------------------------------------------±------±—+
TableReader_8 |1.00 |1 |root |partition:all |time:7.34ms, loops:2, RU:39.461506, cop_task: {num: 64, max: 3.57ms, min: 361µs, avg: 944.7µs, p95: 1.91ms, max_proc_keys: 1, p95_proc_keys: 0, tot_proc: 3.13ms, tot_wait: 2.95ms, rpc_num: 64, rpc_time: 59.6ms, copr_cache_hit_ratio: 0.00, build_task_durat|data:TableRangeScan_7 |2.44 KB|N/A |
└─TableRangeScan_7|1.00 |1 |cop[tikv]|table:annotate|tikv_task:{proc max:0s, min:0s, avg: 0s, p80:0s, p95:0s, iters:64, tasks:64}, scan_detail: {total_process_keys: 1, total_process_keys_size: 1202, total_keys: 64, get_snapshot_time: 670.3µs, rocksdb: {block: {cache_hit_count: 389}}} |range:[2306162990490667171,2306162990490667171], keep order:false, stats:partial[idx_feature_id:missing]|N/A |N/A |

你上面那个执行计划没贴全吧,再贴一下,你id=单个值的时候,它走TableRangeScan,in多个值的时候走Batch_Point_Get,不会吧?

=的时候就两行;
“id=单个值的时候,它走TableRangeScan,in多个值的时候走Batch_Point_Get,不会吧?“:就是这样的

如果不是分区表,in多个值的时候走Batch_Point_Get,那单个值走point_get正常,但是你现在是分区表,分区字段里有没有主键,单个值走tablerangescan,多个值也应该走tablerangescan啊,不得所有分区扫描一遍吗?
你看下SHOW STATS_HEALTHY WHERE table_name=‘anno’;所有分区的统计信息都是100%吗?
另外看下你当前会话的分区裁剪参数是什么。。。SHOW VARIABLES LIKE ‘%tidb_partition_prune_mode%’;

admin show ddl jobs; 也看下,先排除数据索引不一致问题。

不然可能就是遇到了 bug。。。

tidb_partition_prune_mode:dynamic

Table_name Partition_name Healthy
anno global 99
anno p0 100
anno p1 100
anno p2 100
anno p3 100
anno p4 100
anno p5 100
anno p6 100
anno p7 100
anno p8 100
anno p9 100
anno p10 100
anno p11 100
anno p12 100
anno p13 100
anno p14 100
anno p15 100
anno p16 100
anno p17 100
anno p18 100
anno p19 100
anno p20 100
anno p21 100
anno p22 100
anno p23 100
anno p24 100
anno p25 99
anno p26 100
anno p27 100
anno p28 100
anno p29 100
anno p30 100
anno p31 90
anno p32 100
anno p33 100
anno p34 100
anno p35 100
anno p36 100
anno p37 100
anno p38 100
anno p39 100
anno p40 100
anno p41 100
anno p42 100
anno p43 100
anno p44 100
anno p45 100
anno p46 100
anno p47 100
anno p48 92
anno p49 100
anno p50 100
anno p51 100
anno p52 100
anno p53 100
anno p54 100
anno p55 100
anno p56 100
anno p57 99
anno p58 100
anno p59 100
anno p60 100
anno p61 100
anno p62 98
anno p63 100
TABLE_NAME JOB_TYPE SCHEMA_STATE SCHEMA_ID TABLE_ID ROW_COUNT CREATE_TIME START_TIME END_TIME STATE
anno add index /* ingest */ public 1385 9516 54935501 26/8/2024 17:33:13 26/8/2024 17:33:13 26/8/2024 17:37:50 synced

抱歉 打错了。
是 admin check table table_name;

SET tidb_partition_prune_mode=‘static’;
设置成静态裁剪再试下sql的执行计划

这里提了个issue https://github.com/pingcap/tidb/issues/55721