tidb v5.3.0统计数量时判断条件位置不同导致返回结果不一致问题

🪐 TiDB 技术问题
1

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】v5.3.0
【遇到的问题】统计单一表数据量时，使用的条件先后顺序不同，导致产生了不一样的返回结果
【复现路径】做过哪些操作出现的问题
【问题现象及影响】

image
image854×490 16 KB

image
image964×396 16.6 KB

image
image1358×514 29.5 KB

image
image1363×481 26.6 KB

2

目前看来就是order_status放在最后面时执行计划里就没有用到CRC32那一段的条件

3

麻烦反馈下表结构，方便复现，感谢。

4

下面是表结构：

CREATE TABLE order_center.Untitled (
id bigint(20) NOT NULL AUTO_INCREMENT,
unique_incr_id bigint(20) NOT NULL DEFAULT 0,
transaction_id varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL DEFAULT ‘’,
source_id bigint(20) NOT NULL,
persist_table tinyint(4) NOT NULL,
order_id varchar(128) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL,
order_id_key bigint(20) GENERATED ALWAYS AS (crc32(order_id)) VIRTUAL,
source_app_id smallint(6) NOT NULL,
uid bigint(20) NOT NULL DEFAULT 0,
deviceid varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL DEFAULT ‘’,
order_source tinyint(4) NOT NULL,
order_channel smallint(6) NOT NULL,
app_channel varchar(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NULL DEFAULT NULL,
order_status tinyint(4) NOT NULL DEFAULT 1,
order_amount int(11) NOT NULL DEFAULT 0,
pay_time int(11) NOT NULL DEFAULT 0,
order_create_time timestamp(0) NULL DEFAULT NULL,
pay_channel varchar(20) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL,
pay_channel_code tinyint(4) NOT NULL DEFAULT 20,
pay_amount int(11) NOT NULL DEFAULT 0,
refund_amount int(11) NOT NULL DEFAULT 0,
refund_time int(11) NOT NULL DEFAULT 0,
transfer tinyint(4) NOT NULL DEFAULT 0,
discount bigint(20) NULL DEFAULT 0,
currency varchar(10) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NULL DEFAULT NULL,
quantity int(11) NOT NULL DEFAULT 1,
product_code varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL,
product_code_key bigint(20) GENERATED ALWAYS AS (crc32(product_code)) VIRTUAL NULL,
product_name varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NULL DEFAULT ‘’,
product_name_key bigint(20) GENERATED ALWAYS AS (crc32(product_name)) VIRTUAL NULL,
product_type tinyint(4) NULL DEFAULT 0,
create_time timestamp(0) NOT NULL DEFAULT CURRENT_TIMESTAMP(0),
update_time timestamp(0) NOT NULL DEFAULT CURRENT_TIMESTAMP(0) ON UPDATE CURRENT_TIMESTAMP(0),
version int(11) NOT NULL DEFAULT 0,
PRIMARY KEY (id) USING BTREE,
INDEX uid_index(uid) USING BTREE,
INDEX pay_time_index(pay_time) USING BTREE,
INDEX source_id_index(source_id) USING BTREE,
INDEX pck_index(product_code_key) USING BTREE,
INDEX pnk_index(product_name_key) USING BTREE,
UNIQUE INDEX sid_tname_index(source_id, persist_table) USING BTREE,
INDEX order_id_key(order_id_key) USING BTREE,
INDEX idx_did(deviceid) USING BTREE,
INDEX order_ct_idx(order_create_time) USING BTREE,
UNIQUE INDEX unique_idx(unique_incr_id) USING BTREE,
INDEX tid_idx(transaction_id) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 36589893 CHARACTER SET = utf8mb4 COLLATE = utf8mb4_bin= ‘主订单表’ ROW_FORMAT = Compact;

5

同样的表结构，我们在两个环境下，只有一个环境出现了该问题

6

如果不是必现的问题，请参考以下文档，使用 sql-plan-replayer 导出问题集群和正常集群的信息。
https://docs.pingcap.com/zh/tidb/v5.3/sql-plan-replayer

7

我觉得or的两个条件分开写，然后再加一下结果应该就没问题了，感觉是and or and太多导致执行计划出问题。