statistics: optimize stats delta dumping with batch processing

[Rustin170506]

What problem does this PR solve?

Issue Number: close #57869

close #58331

Problem Summary:

What changed and how does it work?

In this PR I changed DumpStatsDeltaToKV to dump the stats in batch instead of one by one. This will significantly improve the performance of the dump process. From my tests, the duration dropped from 40 minutes to 20 seconds under 100m table workload.

See more: #57869 (comment)

Check List

Tests

• Unit test
• Integration test
• Manual test
• 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.

提升 TiDB 在大量表和高负载下 dump stats delta 更新比较慢的问题
Improve TiDB's slow update of dump stats delta under large number of tables and high loads

[codecov]

Codecov Report

Attention: Patch coverage is 69.86301% with 44 lines in your changes missing coverage. Please review.

Project coverage is 73.9479%. Comparing base (d966219) to head (4d40e1b).
Report is 32 commits behind head on master.

Additional details and impacted files

@@               Coverage Diff                @@
##             master     #58791        +/-   ##
================================================
+ Coverage   73.0741%   73.9479%   +0.8738%     
================================================
  Files          1676       1708        +32     
  Lines        463762     477248     +13486     
================================================
+ Hits         338890     352915     +14025     
+ Misses       104006     102683      -1323     
- Partials      20866      21650       +784     

Flag	Coverage Δ
integration	45.7064% <0.0000%> (?)
unit	72.3073% <69.8630%> (+0.0401%)	⬆️

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

Components	Coverage Δ
dumpling	52.6910% <ø> (ø)
parser	∅ <ø> (∅)
br	45.7120% <ø> (-0.0240%)	⬇️

[Rustin170506]

/retest

[Rustin170506]

/retest

[Rustin170506]

I tested this PR on the real cluster:

Before this change:

After this change:

[Rustin170506]

/retest

[Rustin170506]

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

[ti-chi-bot]

[LGTM Timeline notifier]

Timeline:

• 2025-01-08 19:15:03.155221866 +0000 UTC m=+381046.444053592: ☑️ agreed by winoros.
• 2025-01-13 03:59:54.59333345 +0000 UTC m=+758137.882165154: ☑️ agreed by qw4990.

[Rustin170506]

/hold

[Rustin170506]

/retest

[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

[Rustin170506]

/unhold

[tiprow]

@Rustin170506: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
fast_test_tiprow	4d40e1b	link	true	/test fast_test_tiprow

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[ti-chi-bot]

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