statistics: refactor stats meta handling to use DeltaUpdate for multi-table support

[Rustin170506]

What problem does this PR solve?

Issue Number: ref #57869

Problem Summary:

What changed and how does it work?

If you want to understand how it works, read more at #57869 (comment).

This PR split from #58331.

Just updated the UpdateStatsMeta can handle multiple detla table updates by taking a slice of DeltaUpdate as an argument.

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No need to test

  • I checked and no code files have been changed.

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

None

[Rustin170506]

/retest

[codecov]

Codecov Report

Attention: Patch coverage is 78.78788% with 14 lines in your changes missing coverage. Please review.

Project coverage is 74.7839%. Comparing base (23ed0df) to head (22fbe79).
Report is 35 commits behind head on master.

Additional details and impacted files

@@               Coverage Diff                @@
##             master     #58657        +/-   ##
================================================
+ Coverage   73.0885%   74.7839%   +1.6953%     
================================================
  Files          1676       1707        +31     
  Lines        463646     482775     +19129     
================================================
+ Hits         338872     361038     +22166     
+ Misses       103927      99766      -4161     
- Partials      20847      21971      +1124     

Flag	Coverage Δ
integration	46.8320% <0.0000%> (?)
unit	73.3877% <78.7878%> (+1.1047%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
dumpling	52.6910% <ø> (ø)
parser	∅ <ø> (∅)
br	45.7539% <ø> (+0.0209%)	⬆️

[Rustin170506]

/retest

[Rustin170506]

🔢 Self-check (PR reviewed by myself and ready for feedback.)

[elsa0520]

I saw you update the function from one tabledelta to multi DeltaUpdate. But there is no code in PR to use the multi DeltaUpdate. Will/Where you use the multi interface in the future?
If the answer is yes, could you please add some test for the multi deltaupdate which is not same as the past.

[Rustin170506]

As I mentioned in the PR body, this PR split from #58331. You can find the usage from there.

If the answer is yes, could you please add some test for the multi deltaupdate which is not same as the past.

We have a lot of tests to check the count and modify_count. I think they have covered this change. To verify it independently, we need to use the mock session to execute the SQL. From my previous experience of using and maintaining it, it is difficult to understand and maintain. (Difficult to follow the mock logic and the mock framework.)

[Rustin170506]

I also verified the SQL change.

1. First create the test table:

CREATE TABLE IF NOT EXISTS mysql.stats_meta (
    version BIGINT UNSIGNED NOT NULL,
    table_id BIGINT UNSIGNED NOT NULL,
    modify_count BIGINT UNSIGNED NOT NULL DEFAULT 0,
    count BIGINT UNSIGNED NOT NULL DEFAULT 0,
    PRIMARY KEY (table_id)
) ENGINE=InnoDB;

2. Insert initial test data:

INSERT INTO mysql.stats_meta (version, table_id, modify_count, count) 
VALUES (900, 100, 10, 25)
ON DUPLICATE KEY UPDATE 
    version = VALUES(version),
    modify_count = VALUES(modify_count),
    count = VALUES(count);

3. array version of negative value handling SQL:

INSERT INTO mysql.stats_meta (version, table_id, modify_count, count) 
VALUES (1000, 100, 1, 10)
ON DUPLICATE KEY UPDATE 
    version = VALUES(version),
    modify_count = modify_count + VALUES(modify_count),
    count = IF(count > VALUES(count), count - VALUES(count), 0);

4. or a single version of the negative value handling SQL:

INSERT INTO mysql.stats_meta (version, table_id, modify_count, count) 
VALUES (1000, 100, 1, 0)
ON DUPLICATE KEY UPDATE 
    version = VALUES(version),
    modify_count = modify_count + VALUES(modify_count),
    count = IF(count > 10, count - 10, 0);

5. View results:

SELECT * FROM mysql.stats_meta WHERE table_id = 100;

For other changes, it is easy to follow, only for the negitive number there is a little refactoring.

[Rustin170506]

So there is no good way to test multiple table updates now because we're not using it yet. I guess we can add some tests after we start using it.

[Rustin170506]

(Difficult to follow the mock logic and the mock framework.)

https://github.com/Rustin170506/tidb/blob/9afe29ad06bd6a66801652ad5ee51eed128c2b77/pkg/statistics/handle/lockstats/lock_stats_test.go#L195

[elsa0520]

I have no problem leaving the manual testing steps in the PR.

[elsa0520]

As I mentioned in the PR body, this PR split from #58331. You can find the usage from there.

If the answer is yes, could you please add some test for the multi deltaupdate which is not same as the past.

We have a lot of tests to check the count and modify_count. I think they have covered this change. To verify it independently, we need to use the mock session to execute the SQL. From my previous experience of using and maintaining it, it is difficult to understand and maintain. (Difficult to follow the mock logic and the mock framework.)

OK, no question for me. Just want to know what is this PR used for.

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: qw4990, winoros

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• pkg/statistics/OWNERS [qw4990,winoros]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ti-chi-bot]

[LGTM Timeline notifier]

Timeline:

• 2025-01-06 18:59:46.638436441 +0000 UTC m=+207329.927268146: ☑️ agreed by winoros.
• 2025-01-07 07:22:28.294579274 +0000 UTC m=+251891.583410980: ☑️ agreed by qw4990.

[Rustin170506]

/test all

[Rustin170506]

/retest

[ti-chi-bot]

In response to a cherrypick label: new pull request created to branch release-8.5: #58884.