Skip to content

planner: tot_col_size in mysql.stats_histograms might be a negative number  #55126

@qw4990

Description

@qw4990

Bug Report

Please answer these questions before submitting your issue. Thanks!

1. Minimal reproduce step (Required)

image

It seems like the negative number is caused by this modification: https://github.com/pingcap/tidb/blob/v6.5.6/table/tables/tables.go#L477-L490

The current method to maintain the col_size:

  1. update mysql.stats_histograms.tot_col_size each time when there is a DML statement (see https://github.com/pingcap/tidb/blob/v6.5.6/table/tables/tables.go#L477-L490);
  2. calculate avg_col_size by mysql.stats_histograms.tot_col_size / mysql.stats_histograms.not_null_count when actually using it in the cost model;

The behavior above seems overly complex, which might cause unexpected result like the negative number here.
A better/simpler/robuster way to maintain avg_col_size seems to calculate and store it directly in analyze.

2. What did you expect to see? (Required)

The tot_col_size should be equal or large than 0.

3. What did you see instead (Required)

A negative number.

4. What is your TiDB version? (Required)

v6.5.6

Metadata

Metadata

Assignees

No one assigned

    Labels

    affects-5.4This bug affects the 5.4.x(LTS) versions.affects-6.1This bug affects the 6.1.x(LTS) versions.affects-6.5This bug affects the 6.5.x(LTS) versions.affects-7.1This bug affects the 7.1.x(LTS) versions.affects-7.5This bug affects the 7.5.x(LTS) versions.affects-8.1This bug affects the 8.1.x(LTS) versions.component/statisticsreport/customerCustomers have encountered this bug.severity/moderatesig/plannerSIG: Plannertype/bugThe issue is confirmed as a bug.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions