Execution Plan Error

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: 执行计划有错误

| username: zhanggame1

[TiDB Usage Environment] Production Environment / Testing / Poc
[TiDB Version] 7.5
[Reproduction Path] What operations were performed to cause the issue
[Encountered Issue: Problem Phenomenon and Impact]

CREATE TABLE `win_ticket` (
  `draw_id` int(11) NOT NULL,
  `ticket_no` varchar(30) NOT NULL,
  `win_prz_lvl` int(11) NOT NULL,
  `clerk_id` int(11) unsigned DEFAULT NULL,
  `ticket_pwd` varchar(40) DEFAULT NULL,
  `sale_time` datetime DEFAULT NULL,
  `chances` int(11) unsigned DEFAULT NULL,
  `selection` varchar(4000) DEFAULT NULL,
  `multiple` int(11) unsigned DEFAULT NULL,
  `transaction_id` int(11) DEFAULT NULL,
  `term_id` int(11) unsigned DEFAULT NULL,
  `prz_cnt` decimal(50,12) DEFAULT NULL,
  `prz_amt` decimal(50,2) DEFAULT NULL,
  `tax_amt` decimal(50,2) DEFAULT NULL,
  `paid_type` int(11) DEFAULT NULL,
  `paid_time` datetime DEFAULT NULL,
  `paid_operator_id` int(11) DEFAULT NULL,
  `withdraw_amt` int(11) DEFAULT NULL,
  `bno` int(11) DEFAULT NULL,
  `eno` int(11) DEFAULT NULL,
  `win_time` datetime NOT NULL,
  `paid_term_id` int(11) DEFAULT NULL,
  `end_paid_time` datetime DEFAULT NULL,
  `win_selection_chances` int(11) DEFAULT NULL,
  `payment_type` int(11) DEFAULT NULL,
  PRIMARY KEY (`draw_id`,`ticket_no`,`win_prz_lvl`) /*T![clustered_index] CLUSTERED */,
  KEY `ind_paid_time` (`paid_time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

This table has an index on the paid_time column, KEY ind_paid_time (paid_time), but I don’t know why the execution plan is having issues here.

Export statistics information
win_ticket.json (1.1 MB)

| username: 小龙虾爱大龙虾 | Original post link

Export the statistics information according to this: 常规统计信息 | PingCAP 文档中心

| username: zhanggame1 | Original post link

Already uploaded.

| username: heiwandou | Original post link

Interval problem

| username: zhanggame1 | Original post link

Could you be more specific?

| username: oceanzhang | Original post link

Implicit conversion??? It shouldn’t be.

| username: WalterWj | Original post link

Try adding a hint and collecting statistics.

| username: zhanggame1 | Original post link

After re-collecting the statistics, it returned to normal.

| username: 芮芮是产品 | Original post link

If you are using partitioned tables, it is recommended to lock the statistics.

| username: zhanggame1 | Original post link

This is a regular table.

| username: h5n1 | Original post link

Let’s check the current statistics.

| username: 小龙虾爱大龙虾 | Original post link

It still feels like an evaluation issue.

| username: 有猫万事足 | Original post link

Does this mean that the ind_paid_time index is only partial, so it can’t be used?

| username: 有猫万事足 | Original post link

Your database keeps encountering these statistics issues.
It’s happened several times. Either the global statistics don’t work after collecting statistics for a certain partition, or the statistics for a certain field don’t work.
I feel like you’ve encountered this type of problem several times. It’s reached a point where it can’t be treated as a coincidence anymore.

| username: h5n1 | Original post link

The explain method shows that the estimated cost of the index scan is lower than that of the full table scan. I’m not sure how this estimation is calculated, but looking at the histogram and distinct values, there shouldn’t be more than 600,000 rows.

| username: 有猫万事足 | Original post link

The code contains a comment explaining the meaning of stats:partial. It is indeed caused by the incomplete loading of index statistics.

| username: zhanggame1 | Original post link

There are 256 entries.

| username: zhanggame1 | Original post link

You must be mistaken. There has only been one post about the execution plan selection being incorrect.

| username: h5n1 | Original post link

I want to see what the buckets that meet your SQL conditions look like.

| username: zhanggame1 | Original post link

I remember seeing some related issues about statistics not being fully loaded in TiDB, such as one TiDB server analyzing data that another TiDB server cannot see.