Repository: pingcap/docs
Pull request #20490: *: add TiDB workload repository
Author: login: wddevries
Labels: name: translation/done
description: This PR has been translated from English into Chinese and updated to pingcap/docs-cn in a PR.
name: size/L
description: Denotes a PR that changes 100-499 lines, ignoring generated files.
name: type/compatibility-or-feature-change
description: This PR involves compatibility changes or feature behavior changes.
name: approved
name: lgtm
name: v9.0-beta.1
description: This PR/issue applies to TiDB v9.0-beta.1.
Created: 2025-03-08T06:47:49Z | Merged: 2025-04-17T03:27:55Z

<!--Thanks for your contribution to TiDB documentation. Please answer the following questions.-->
<!--
We provide several doc templates for you to use to create documentation that aligns with our style.
Please check out these templates before you submit the pull request:
https://github.com/pingcap/docs/tree/master/resources/doc-templates
-->

### First-time contributors' checklist <!--Remove this section if you're not a first-time contributor.-->

- [ ] I've signed [**Contributor License Agreement**](https://cla-assistant.io/pingcap/docs) that's required for repo owners to accept my contribution.

### What is changed, added or deleted? (Required)

<!--Tell us what you did and why.-->
This pull request adds documentation for the Workload Repository project.

### Which TiDB version(s) do your changes apply to? (Required)

<!-- Fill in "x" in [] to tick the checkbox below.-->

**Tips for choosing the affected version(s):**

By default, **CHOOSE MASTER ONLY** so your changes will be applied to the next TiDB major or minor releases. If your PR involves a product feature behavior change or a compatibility change, **CHOOSE THE AFFECTED RELEASE BRANCH(ES) AND MASTER**.

For details, see [tips for choosing the affected versions](https://github.com/pingcap/docs/blob/master/CONTRIBUTING.md#guideline-for-choosing-the-affected-versions).

- [x] master (the latest development version)
- [x] v9.0 (TiDB 9.0 versions)
- [ ] v8.5 (TiDB 8.5 versions)
- [ ] v8.4 (TiDB 8.4 versions)
- [ ] v8.3 (TiDB 8.3 versions)
- [ ] v8.1 (TiDB 8.1 versions)
- [ ] v7.5 (TiDB 7.5 versions)
- [ ] v7.1 (TiDB 7.1 versions)
- [ ] v6.5 (TiDB 6.5 versions)
- [ ] v6.1 (TiDB 6.1 versions)
- [ ] v5.4 (TiDB 5.4 versions)

### What is the related PR or file link(s)?

<!--Reference link(s) will help reviewers review your PR quickly.-->

- This PR is translated from:
- Other reference link(s):

### Do your changes match any of the following descriptions?

- [ ] Delete files
- [ ] Change aliases
- [ ] Need modification after applied to another branch <!-- If yes, please comment "/label version-specific-changes-required" below to trigger the bot to add the label. -->
- [ ] Might cause conflicts after applied to another branch



Diff:
diff --git a/TOC.md b/TOC.md
index fdcf1c2991570..89580beff1c0d 100644
--- a/TOC.md
+++ b/TOC.md
@@ -1066,6 +1066,7 @@
   - [Table Filter](/table-filter.md)
   - [Schedule Replicas by Topology Labels](/schedule-replicas-by-topology-labels.md)
   - [URI Formats of External Storage Services](/external-storage-uri.md)
+  - [TiDB Workload Repository](/workload-repository.md)
 - FAQs
   - [FAQ Summary](/faq/faq-overview.md)
   - [TiDB FAQs](/faq/tidb-faq.md)
diff --git a/sql-statements/sql-statement-admin.md b/sql-statements/sql-statement-admin.md
index e89b62104bd66..e25d07d3e5d6e 100644
--- a/sql-statements/sql-statement-admin.md
+++ b/sql-statements/sql-statement-admin.md
@@ -14,6 +14,7 @@ This statement is a TiDB extension syntax, used to view the status of TiDB and c
 - [`ADMIN REPAIR`](#admin-repair-statement)
 - [`ADMIN SHOW NEXT_ROW_ID`](#admin-show-next_row_id-statement)
 - [`ADMIN SHOW SLOW`](#admin-show-slow-statement)
+- [`ADMIN CREATE WORKLOAD SNAPSHOT`](#admin-create-workload-snapshot-statement)
 
 ## DDL related statement
 
@@ -149,6 +150,28 @@ For details, refer to [`ADMIN SHOW SLOW` command](/identify-slow-queries.md#admi
 
 </CustomContent>
 
+## `ADMIN CREATE WORKLOAD SNAPSHOT` statement
+
+<CustomContent platform="tidb-cloud">
+
+> **Note:**
+>
+> This TiDB statement is not applicable to TiDB Cloud.
+
+</CustomContent>
+
+<CustomContent platform="tidb">
+
+The following SQL statement will trigger a manual snapshot in the [Workload Repository](/workload-repository.md):
+
+</CustomContent>
+
+```sql
+ADMIN CREATE WORKLOAD SNAPSHOT;
+```
+
+Note that the Workload Repository must be enabled for this statement to take effect. Otherwise, it will generate an error.
+
 ## Synopsis
 
 ```ebnf+diagram
@@ -186,6 +209,7 @@ AdminStmt ::=
         | 'FLUSH' ('SESSION' | 'INSTANCE') 'PLAN_CACHE'
         | 'SET' 'BDR' 'ROLE' ( 'PRIMARY' | 'SECONDARY' )
         | 'UNSET' 'BDR' 'ROLE'
+        | 'CREATE' 'WORKLOAD' 'SNAPSHOT'
     )
 
 NumList ::=
diff --git a/system-variable-reference.md b/system-variable-reference.md
index e64d96b8072eb..196e2ea97cebf 100644
--- a/system-variable-reference.md
+++ b/system-variable-reference.md
@@ -4035,6 +4035,26 @@ Referenced in:
 - [SHOW [GLOBAL|SESSION] VARIABLES](/sql-statements/sql-statement-show-variables.md)
 - [System Variables](/system-variables.md#tidb_window_concurrency-new-in-v40)
 
+### tidb_workload_repository_dest
+
+- [TiDB Workload Repository](/workload-repository.md#enable-the-workload-repository)
+- [System Variables](/system-variables.md#tidb_workload_repository_dest-new-in-v900)
+
+### tidb_workload_repository_active_sampling_interval
+
+- [TiDB Workload Repository](/workload-repository.md#time-based-sampling-process-every-5-seconds-by-default)
+- [System Variables](/system-variables.md#tidb_workload_repository_active_sampling_interval-new-in-v900)
+
+### tidb_workload_repository_retention_days
+
+- [TiDB Workload Repository](/workload-repository.md#data-retention)
+- [System Variables](/system-variables.md#tidb_workload_repository_retention_days-new-in-v900)
+
+### tidb_workload_repository_snapshot_interval
+
+- [TiDB Workload Repository](/workload-repository.md#snapshot-sampling-process-hourly-by-default)
+- [System Variables](/system-variables.md#tidb_workload_repository_snapshot_interval-new-in-v900)
+
 ### tiflash_fastscan
 
 Referenced in:
diff --git a/system-variables.md b/system-variables.md
index 750aa623c69fe..eba3d4c3239d2 100644
--- a/system-variables.md
+++ b/system-variables.md
@@ -6207,6 +6207,98 @@ For details, see [Identify Slow Queries](/identify-slow-queries.md).
 - This variable is used to set the concurrency degree of the window operator.
 - A value of `-1` means that the value of `tidb_executor_concurrency` will be used instead.
 
+### tidb_workload_repository_dest <span class="version-mark">New in v9.0.0</span>
+
+- Scope: GLOBAL
+- Persists to cluster: Yes
+- Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No
+- Type: String
+- Default value: `''`
+
+<CustomContent platform="tidb">
+
+- This variable is used to set the destination of the [Workload Repository](/workload-repository.md).
+- The value can be either `'table'` (enabling the workload repository) or `''` (disabling the workload repository).
+
+</CustomContent>
+
+<CustomContent platform="tidb-cloud">
+
+- This variable is used to set the destination of the [Workload Repository](https://docs.pingcap.com/tidb/dev/workload-repository).
+- The value can be either `'table'` (enabling the workload repository) or `''` (disabling the workload repository).
+
+</CustomContent>
+
+### tidb_workload_repository_active_sampling_interval <span class="version-mark">New in v9.0.0</span>
+
+- Scope: GLOBAL
+- Persists to cluster: Yes
+- Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No
+- Type: Integer
+- Default value: `5`
+- Range: `[0, 600]`
+- Unit: Seconds
+
+<CustomContent platform="tidb">
+
+- Sets the sampling interval for the [Workload Repository](/workload-repository.md)'s time-based sampling process.
+- Setting the value to `0` disables the time-based sampling process.
+
+</CustomContent>
+
+<CustomContent platform="tidb-cloud">
+
+- Sets the sampling interval for the [Workload Repository](https://docs.pingcap.com/tidb/dev/workload-repository)'s time-based sampling process.
+- Setting the value to `0` disables the time-based sampling process.
+
+</CustomContent>
+
+### tidb_workload_repository_retention_days <span class="version-mark">New in v9.0.0</span>
+
+- Scope: GLOBAL
+- Persists to cluster: Yes
+- Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No
+- Type: Integer
+- Default value: `7`
+- Range: `[0, 365]`
+- Unit: Days
+
+<CustomContent platform="tidb">
+
+- Sets the number of days that [Workload Repository](/workload-repository.md) data is retained.
+- Setting the value to `0` disables automatic purging of old data.
+
+</CustomContent>
+
+<CustomContent platform="tidb-cloud">
+
+- Sets the number of days that [Workload Repository](https://docs.pingcap.com/tidb/dev/workload-repository) data is retained.
+- Setting the value to `0` disables automatic purging of old data.
+
+</CustomContent>
+
+### tidb_workload_repository_snapshot_interval <span class="version-mark">New in v9.0.0</span>
+
+- Scope: GLOBAL
+- Persists to cluster: Yes
+- Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No
+- Type: Integer
+- Default value: `3600`
+- Range: `[900, 7200]`
+- Unit: Seconds
+
+<CustomContent platform="tidb">
+
+- Sets the sampling interval for the [Workload Repository](/workload-repository.md)'s snapshot sampling process.
+
+</CustomContent>
+
+<CustomContent platform="tidb-cloud">
+
+- Sets the sampling interval for the [Workload Repository](https://docs.pingcap.com/tidb/dev/workload-repository)'s snapshot sampling process.
+
+</CustomContent>
+
 ### tiflash_fastscan <span class="version-mark">New in v6.3.0</span>
 
 - Scope: SESSION | GLOBAL
diff --git a/workload-repository.md b/workload-repository.md
new file mode 100644
index 0000000000000..81fcc5a6383b6
--- /dev/null
+++ b/workload-repository.md
@@ -0,0 +1,117 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enable the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md#tidb_workload_repository_dest-new-in-v900) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The snapshot sampling process, which runs at configurable intervals, hourly by default, and can be triggered manually.
+* The time-based sampling process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot sampling process (hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various cumulative metrics tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and the process is as follows:
+
+1. From the initiating node, a row is inserted into `WORKLOAD_SCHEMA.HIST_SNAPSHOTS`, capturing the snapshot ID, start and end timestamps, and server version details.
+2. On each TiDB node, all rows from the source tables are copied to the corresponding target tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Source table | Destination table | Description |
+| --- | --- | --- |
+| [`TIDB_INDEX_USAGE`](/information-schema/information-schema-tidb-index-usage.md) | `HIST_TIDB_INDEX_USAGE` | Index usage statistics |
+| [`TIDB_STATEMENTS_STATS`](/statement-summary-tables.md) | `HIST_TIDB_STATEMENTS_STATS` | Statement statistics |
+| [`CLIENT_ERRORS_SUMMARY_BY_HOST`](/information-schema/client-errors-summary-by-host.md) | `HIST_CLIENT_ERRORS_SUMMARY_BY_HOST` | Client error summaries by host |
+| [`CLIENT_ERRORS_SUMMARY_BY_USER`](/information-schema/client-errors-summary-by-user.md) | `HIST_CLIENT_ERRORS_SUMMARY_BY_USER` | Client error summaries by user |
+| [`CLIENT_ERRORS_SUMMARY_GLOBAL`](/information-schema/client-errors-summary-global.md) | `HIST_CLIENT_ERRORS_SUMMARY_GLOBAL` | Client error summaries by global |
+
+The snapshot sampling interval can be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval-new-in-v900):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set the interval to 15 minutes
+```
+
+## Manual snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using the following SQL statement:
+
+```sql
+ADMIN CREATE WORKLOAD SNAPSHOT;
+```
+
+Manually triggering snapshots does not change the interval or timing of automatic snapshots.
+
+## Time-based sampling process (every 5 seconds by default)
+
+The time-based sampling process samples data from various non-cumulative metrics tables at intervals ranging from 1 to 600 seconds.
+
+When the time-base sampling process runs, all rows from the source tables are copied to the corresponding target tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp and instance ID.
+
+Unlike the snapshot sampling process, a row will not be added to the `HIST_SNAPSHOTS` table.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Source table | Destination table | Description |
+| --- | --- | --- |
+| [`PROCESSLIST`](/information-schema/information-schema-processlist.md) | `HIST_PROCESSLIST` | Active sessions |
+| [`DATA_LOCK_WAITS`](/information-schema/information-schema-data-lock-waits.md) | `HIST_DATA_LOCK_WAITS` | Data lock waits |
+| [`TIDB_TRX`](/information-schema/information-schema-tidb-trx.md) | `HIST_TIDB_TRX` | Active transactions |
+| [`MEMORY_USAGE`](/information-schema/information-schema-memory-usage.md) | `HIST_MEMORY_USAGE` | Memory usage |
+| [`DEADLOCKS`](/information-schema/information-schema-deadlocks.md) | `HIST_DEADLOCKS` | Deadlock information |
+
+The time-based sampling interval can be controlled with [`tidb_workload_repository_active_sampling_interval`](/system-variables.md#tidb_workload_repository_active_sampling_interval-new-in-v900):
+
+```sql
+SET GLOBAL tidb_workload_repository_active_sampling_interval = 20; -- set the interval to 20 seconds
+```
+
+Setting this global variable to `0` disables the time-based sampling process.
+
+## Data retention
+
+Historical data in the Workload Repository is retained for seven days by default. The system automatically purges data based on the retention period setting, using partitions for efficient data management.
+
+By default the Workload Repository retains historical data for seven days, but the [`tidb_workload_repository_retention_days`](/system-variables.md#tidb_workload_repository_retention_days-new-in-v900) variable can be used to control the length of this period. For example, to keep data for 30 days, run the following:
+
+```sql
+SET GLOBAL tidb_workload_repository_retention_days = 30;
+```
+
+A higher value for this variable allows for longer data retention, which might be beneficial for workload analysis, but will increase storage requirements.
+
+## Notes
+
+- Enabling the Workload Repository might have a small performance impact on the system.
+- Setting sampling intervals too short might increase system overhead.
+- Setting retention days to `0` disables automatic purging of old data.
+
+## Best practices
+
+- Start with default settings and adjust based on your monitoring needs.
+- Set reasonable retention periods based on your storage capacity.
+- Monitor the size of the `WORKLOAD_SCHEMA` database.
+- Use longer sampling intervals in production environments to minimize overhead.


Reviews:
user: login: hfxsd
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-03-24T02:29:17Z
user: login: wddevries
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-25T20:02:48Z
user: login: hfxsd
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-03-26T01:20:45Z
user: login: wddevries
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-26T04:57:01Z
user: login: hfxsd
state: APPROVED
author_association: COLLABORATOR
submitted_at: 2025-03-27T01:34:13Z
user: login: hfxsd
state: APPROVED
author_association: COLLABORATOR
submitted_at: 2025-03-27T01:34:14Z
user: login: hfxsd
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-03-27T02:08:45Z
user: login: hfxsd
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-03-27T02:17:07Z
user: login: hfxsd
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-03-27T02:20:27Z
user: login: hfxsd
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-03-27T02:28:45Z
user: login: hfxsd
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-03-27T02:48:13Z
user: login: songrijie
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-31T13:41:28Z
user: login: songrijie
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-31T13:46:51Z
user: login: songrijie
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-31T13:48:32Z
user: login: songrijie
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-31T13:52:26Z
user: login: songrijie
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-31T14:36:52Z
user: login: wddevries
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-04T03:50:50Z
user: login: wddevries
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-04T03:54:50Z
user: login: wddevries
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-04T03:55:44Z
user: login: songrijie
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-09T11:06:30Z
user: login: songrijie
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-09T11:07:39Z
user: login: songrijie
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-04-09T11:08:01Z
user: login: qiancai
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-04-14T06:57:20Z
user: login: qiancai
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-04-14T07:10:46Z
user: login: qiancai
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-04-14T07:58:44Z
user: login: qiancai
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-04-14T08:05:48Z
user: login: qiancai
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-04-14T08:19:16Z
user: login: qiancai
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-04-14T08:21:07Z
user: login: qiancai
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-04-14T08:23:31Z
user: login: qiancai
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-04-14T08:24:37Z
user: login: qiancai
body: Rest LGTM
state: APPROVED
author_association: COLLABORATOR
submitted_at: 2025-04-14T08:30:03Z
user: login: wddevries
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-04-16T06:33:08Z
user: login: hfxsd
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-04-17T01:57:04Z
user: login: hfxsd
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-04-17T01:57:39Z
user: login: hfxsd
state: APPROVED
author_association: COLLABORATOR
submitted_at: 2025-04-17T03:01:36Z

Review comments:
diff_hunk: @@ -1066,6 +1066,7 @@
   - [Table Filter](/table-filter.md)
   - [Schedule Replicas by Topology Labels](/schedule-replicas-by-topology-labels.md)
   - [URI Formats of External Storage Services](/external-storage-uri.md)
+  - [System Variable Reference](/workloadrepo.md)
path: TOC.md
user: login: hfxsd
body: ```suggestion
  - [TiDB Workload Repository](/workloadrepo.md)
```
created_at: 2025-03-24T01:51:34Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: The workload repository is a system for collecting and storing historical workload data from a TiDB cluster.
path: workloadrepo.md
user: login: hfxsd
body: ```suggestion
summary: Learn the workload repository that is a system for collecting and storing historical workload data from a TiDB cluster.
```
created_at: 2025-03-24T02:08:20Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: The workload repository is a system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the following system variable:
path: workloadrepo.md
user: login: hfxsd
body: ```suggestion
To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md/tidb_workload_repository_dest-new-in-v9.0.0) system variable:
```
created_at: 2025-03-24T02:09:48Z
author_association: COLLABORATOR
diff_hunk: @@ -6207,6 +6207,51 @@ For details, see [Identify Slow Queries](/identify-slow-queries.md).
 - This variable is used to set the concurrency degree of the window operator.
 - A value of `-1` means that the value of `tidb_executor_concurrency` will be used instead.
 
+### tidb_workload_repository_dest
+
+- Scope: GLOBAL
+- Persists to cluster: Yes
+- Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No
+- Type: String
+- Default value: `''`
+- This variable is used to set the destination of the [Workload Repository](/workloadrepo.md).
+- The value can be either `'table'` (enabling the workload repository) or `''` (disabling the workload repository).
+
+### tidb_workload_repository_active_sampling_interval
+
+- Scope: GLOBAL
+- Persists to cluster: Yes
+- Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No
+- Type: Integer
+- Default value: `5`
+- Range: `[0, 600]`
+- Unit: Seconds
+- Sets the sampling interval for the [Workload Repository](/workloadrepo.md)'s Time-based Sampling Process.
+- Setting the value to `0` disables the Time-based Sampling Process.
+
+### tidb_workload_repository_retention_days
+
+- Scope: GLOBAL
+- Persists to cluster: Yes
+- Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No
+- Type: Integer
+- Default value: `7`
+- Range: `[0, 365]`
+- Unit: Days
+- Sets the number of days that [Workload Repository](/workloadrepo.md) data is retained.
+- Setting the value to `0` disables automatic purging of old data.
+
+### tidb_workload_repository_snapshot_interval
path: system-variables.md
user: login: hfxsd
body: ```suggestion
### tidb_workload_repository_snapshot_interval <span class="version-mark">New in v9.0.0</span>
```
created_at: 2025-03-24T02:10:33Z
author_association: COLLABORATOR
diff_hunk: @@ -6207,6 +6207,51 @@ For details, see [Identify Slow Queries](/identify-slow-queries.md).
 - This variable is used to set the concurrency degree of the window operator.
 - A value of `-1` means that the value of `tidb_executor_concurrency` will be used instead.
 
+### tidb_workload_repository_dest
+
+- Scope: GLOBAL
+- Persists to cluster: Yes
+- Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No
+- Type: String
+- Default value: `''`
+- This variable is used to set the destination of the [Workload Repository](/workloadrepo.md).
+- The value can be either `'table'` (enabling the workload repository) or `''` (disabling the workload repository).
+
+### tidb_workload_repository_active_sampling_interval
+
+- Scope: GLOBAL
+- Persists to cluster: Yes
+- Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No
+- Type: Integer
+- Default value: `5`
+- Range: `[0, 600]`
+- Unit: Seconds
+- Sets the sampling interval for the [Workload Repository](/workloadrepo.md)'s Time-based Sampling Process.
+- Setting the value to `0` disables the Time-based Sampling Process.
+
+### tidb_workload_repository_retention_days
path: system-variables.md
user: login: hfxsd
body: ```suggestion
### tidb_workload_repository_retention_days <span class="version-mark">New in v9.0.0</span>
```
created_at: 2025-03-24T02:10:39Z
author_association: COLLABORATOR
diff_hunk: @@ -6207,6 +6207,51 @@ For details, see [Identify Slow Queries](/identify-slow-queries.md).
 - This variable is used to set the concurrency degree of the window operator.
 - A value of `-1` means that the value of `tidb_executor_concurrency` will be used instead.
 
+### tidb_workload_repository_dest
+
+- Scope: GLOBAL
+- Persists to cluster: Yes
+- Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No
+- Type: String
+- Default value: `''`
+- This variable is used to set the destination of the [Workload Repository](/workloadrepo.md).
+- The value can be either `'table'` (enabling the workload repository) or `''` (disabling the workload repository).
+
+### tidb_workload_repository_active_sampling_interval
path: system-variables.md
user: login: hfxsd
body: ```suggestion
### tidb_workload_repository_active_sampling_interval <span class="version-mark">New in v9.0.0</span>
```
created_at: 2025-03-24T02:10:44Z
author_association: COLLABORATOR
diff_hunk: @@ -6207,6 +6207,51 @@ For details, see [Identify Slow Queries](/identify-slow-queries.md).
 - This variable is used to set the concurrency degree of the window operator.
 - A value of `-1` means that the value of `tidb_executor_concurrency` will be used instead.
 
+### tidb_workload_repository_dest
path: system-variables.md
user: login: hfxsd
body: ```suggestion
### tidb_workload_repository_dest <span class="version-mark">New in v9.0.0</span>
```
created_at: 2025-03-24T02:10:48Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: The workload repository is a system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the following system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data Collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot Sampling Process (Hourly by default)
path: workloadrepo.md
user: login: hfxsd
body: ```suggestion
## Snapshot sampling process (hourly by default)
```
created_at: 2025-03-24T02:12:34Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: The workload repository is a system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the following system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data Collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot Sampling Process (Hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into HIST_SNAPSHOTS, capturing the snapshot’s ID, start and end timestamps, and server version details.
path: workloadrepo.md
user: login: hfxsd
body: ```suggestion
 1. From the initiating node a row is inserted into `HIST_SNAPSHOTS`, capturing the snapshot ID, start and end timestamps, and server version details.
```
created_at: 2025-03-24T02:13:25Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: The workload repository is a system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the following system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data Collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot Sampling Process (Hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into HIST_SNAPSHOTS, capturing the snapshot’s ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| TIDB_INDEX_USAGE | HIST_TIDB_INDEX_USAGE | Index usage statistics |
+| TIDB_STATEMENTS_STATS | HIST_TIDB_STATEMENTS_STATS | Statement statistics |
+| CLIENT_ERRORS_SUMMARY_BY_HOST | HIST_CLIENT_ERRORS_SUMMARY_BY_HOST | Client error summaries by host |
+| CLIENT_ERRORS_SUMMARY_BY_USER | HIST_CLIENT_ERRORS_SUMMARY_BY_USER | Client error summaries by user |
+| CLIENT_ERRORS_SUMMARY_GLOBAL | HIST_CLIENT_ERRORS_SUMMARY_GLOBAL | Client error summaries by global |
path: workloadrepo.md
user: login: hfxsd
body: ```suggestion
| `TIDB_INDEX_USAGE` | `HIST_TIDB_INDEX_USAGE` | Index usage statistics |
| `TIDB_STATEMENTS_STATS` | `HIST_TIDB_STATEMENTS_STATS` | Statement statistics |
| `CLIENT_ERRORS_SUMMARY_BY_HOST` | `HIST_CLIENT_ERRORS_SUMMARY_BY_HOST` | Client error summaries by host |
| `CLIENT_ERRORS_SUMMARY_BY_USER` | `HIST_CLIENT_ERRORS_SUMMARY_BY_USER` | Client error summaries by user |
| `CLIENT_ERRORS_SUMMARY_GLOBAL` | `HIST_CLIENT_ERRORS_SUMMARY_GLOBAL` | Client error summaries by global |
```
created_at: 2025-03-24T02:20:53Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: The workload repository is a system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the following system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data Collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot Sampling Process (Hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into HIST_SNAPSHOTS, capturing the snapshot’s ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| TIDB_INDEX_USAGE | HIST_TIDB_INDEX_USAGE | Index usage statistics |
+| TIDB_STATEMENTS_STATS | HIST_TIDB_STATEMENTS_STATS | Statement statistics |
+| CLIENT_ERRORS_SUMMARY_BY_HOST | HIST_CLIENT_ERRORS_SUMMARY_BY_HOST | Client error summaries by host |
+| CLIENT_ERRORS_SUMMARY_BY_USER | HIST_CLIENT_ERRORS_SUMMARY_BY_USER | Client error summaries by user |
+| CLIENT_ERRORS_SUMMARY_GLOBAL | HIST_CLIENT_ERRORS_SUMMARY_GLOBAL | Client error summaries by global |
+
+The snapshot sampling interval may be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval):
path: workloadrepo.md
user: login: hfxsd
body: ```suggestion
The snapshot sampling interval might be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval-new-in-v9.0.0):
```
created_at: 2025-03-24T02:21:24Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: The workload repository is a system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the following system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data Collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot Sampling Process (Hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into HIST_SNAPSHOTS, capturing the snapshot’s ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| TIDB_INDEX_USAGE | HIST_TIDB_INDEX_USAGE | Index usage statistics |
+| TIDB_STATEMENTS_STATS | HIST_TIDB_STATEMENTS_STATS | Statement statistics |
+| CLIENT_ERRORS_SUMMARY_BY_HOST | HIST_CLIENT_ERRORS_SUMMARY_BY_HOST | Client error summaries by host |
+| CLIENT_ERRORS_SUMMARY_BY_USER | HIST_CLIENT_ERRORS_SUMMARY_BY_USER | Client error summaries by user |
+| CLIENT_ERRORS_SUMMARY_GLOBAL | HIST_CLIENT_ERRORS_SUMMARY_GLOBAL | Client error summaries by global |
+
+The snapshot sampling interval may be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set interval to 15 minutes
path: workloadrepo.md
user: login: hfxsd
body: ```suggestion
SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set the interval to 15 minutes
```
created_at: 2025-03-24T02:21:51Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: The workload repository is a system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the following system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data Collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot Sampling Process (Hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into HIST_SNAPSHOTS, capturing the snapshot’s ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| TIDB_INDEX_USAGE | HIST_TIDB_INDEX_USAGE | Index usage statistics |
+| TIDB_STATEMENTS_STATS | HIST_TIDB_STATEMENTS_STATS | Statement statistics |
+| CLIENT_ERRORS_SUMMARY_BY_HOST | HIST_CLIENT_ERRORS_SUMMARY_BY_HOST | Client error summaries by host |
+| CLIENT_ERRORS_SUMMARY_BY_USER | HIST_CLIENT_ERRORS_SUMMARY_BY_USER | Client error summaries by user |
+| CLIENT_ERRORS_SUMMARY_GLOBAL | HIST_CLIENT_ERRORS_SUMMARY_GLOBAL | Client error summaries by global |
+
+The snapshot sampling interval may be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set interval to 15 minutes
+```
+
+## Taking Manual Snapshots
path: workloadrepo.md
user: login: hfxsd
body: ```suggestion
## Take manual snapshots
```
created_at: 2025-03-24T02:22:02Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: The workload repository is a system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the following system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data Collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot Sampling Process (Hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into HIST_SNAPSHOTS, capturing the snapshot’s ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| TIDB_INDEX_USAGE | HIST_TIDB_INDEX_USAGE | Index usage statistics |
+| TIDB_STATEMENTS_STATS | HIST_TIDB_STATEMENTS_STATS | Statement statistics |
+| CLIENT_ERRORS_SUMMARY_BY_HOST | HIST_CLIENT_ERRORS_SUMMARY_BY_HOST | Client error summaries by host |
+| CLIENT_ERRORS_SUMMARY_BY_USER | HIST_CLIENT_ERRORS_SUMMARY_BY_USER | Client error summaries by user |
+| CLIENT_ERRORS_SUMMARY_GLOBAL | HIST_CLIENT_ERRORS_SUMMARY_GLOBAL | Client error summaries by global |
+
+The snapshot sampling interval may be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set interval to 15 minutes
+```
+
+## Taking Manual Snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using:
path: workloadrepo.md
user: login: hfxsd
body: ```suggestion
Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using the following SQL statement:
```
created_at: 2025-03-24T02:22:45Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: The workload repository is a system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the following system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data Collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot Sampling Process (Hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into HIST_SNAPSHOTS, capturing the snapshot’s ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| TIDB_INDEX_USAGE | HIST_TIDB_INDEX_USAGE | Index usage statistics |
+| TIDB_STATEMENTS_STATS | HIST_TIDB_STATEMENTS_STATS | Statement statistics |
+| CLIENT_ERRORS_SUMMARY_BY_HOST | HIST_CLIENT_ERRORS_SUMMARY_BY_HOST | Client error summaries by host |
+| CLIENT_ERRORS_SUMMARY_BY_USER | HIST_CLIENT_ERRORS_SUMMARY_BY_USER | Client error summaries by user |
+| CLIENT_ERRORS_SUMMARY_GLOBAL | HIST_CLIENT_ERRORS_SUMMARY_GLOBAL | Client error summaries by global |
+
+The snapshot sampling interval may be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set interval to 15 minutes
+```
+
+## Taking Manual Snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
+## Time-based Sampling Process (Every 5 seconds by default)
path: workloadrepo.md
user: login: hfxsd
body: ```suggestion
## Time-based sampling process (every 5 seconds by default)
```
created_at: 2025-03-24T02:24:10Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: The workload repository is a system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the following system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data Collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot Sampling Process (Hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into HIST_SNAPSHOTS, capturing the snapshot’s ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| TIDB_INDEX_USAGE | HIST_TIDB_INDEX_USAGE | Index usage statistics |
+| TIDB_STATEMENTS_STATS | HIST_TIDB_STATEMENTS_STATS | Statement statistics |
+| CLIENT_ERRORS_SUMMARY_BY_HOST | HIST_CLIENT_ERRORS_SUMMARY_BY_HOST | Client error summaries by host |
+| CLIENT_ERRORS_SUMMARY_BY_USER | HIST_CLIENT_ERRORS_SUMMARY_BY_USER | Client error summaries by user |
+| CLIENT_ERRORS_SUMMARY_GLOBAL | HIST_CLIENT_ERRORS_SUMMARY_GLOBAL | Client error summaries by global |
+
+The snapshot sampling interval may be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set interval to 15 minutes
+```
+
+## Taking Manual Snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
+## Time-based Sampling Process (Every 5 seconds by default)
+
+The time-based sampling process, which runs every 1 to 600 seconds, samples data from various monitoring tables.
+
+When the time-base sampling process runs all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp and instance ID.
path: workloadrepo.md
user: login: hfxsd
body: ```suggestion
When the time-base sampling process runs, all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp and instance ID.
```
created_at: 2025-03-24T02:24:42Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: The workload repository is a system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the following system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data Collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot Sampling Process (Hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into HIST_SNAPSHOTS, capturing the snapshot’s ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| TIDB_INDEX_USAGE | HIST_TIDB_INDEX_USAGE | Index usage statistics |
+| TIDB_STATEMENTS_STATS | HIST_TIDB_STATEMENTS_STATS | Statement statistics |
+| CLIENT_ERRORS_SUMMARY_BY_HOST | HIST_CLIENT_ERRORS_SUMMARY_BY_HOST | Client error summaries by host |
+| CLIENT_ERRORS_SUMMARY_BY_USER | HIST_CLIENT_ERRORS_SUMMARY_BY_USER | Client error summaries by user |
+| CLIENT_ERRORS_SUMMARY_GLOBAL | HIST_CLIENT_ERRORS_SUMMARY_GLOBAL | Client error summaries by global |
+
+The snapshot sampling interval may be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set interval to 15 minutes
+```
+
+## Taking Manual Snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
+## Time-based Sampling Process (Every 5 seconds by default)
+
+The time-based sampling process, which runs every 1 to 600 seconds, samples data from various monitoring tables.
+
+When the time-base sampling process runs all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp and instance ID.
+
+Unlike the Snapshot Sampling process, a row will not be added to the `HIST_SNAPSHOTS` table.
path: workloadrepo.md
user: login: hfxsd
body: ```suggestion
Unlike the snapshot sampling process, a row will not be added to the `HIST_SNAPSHOTS` table.
```
created_at: 2025-03-24T02:25:07Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: The workload repository is a system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the following system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data Collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot Sampling Process (Hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into HIST_SNAPSHOTS, capturing the snapshot’s ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| TIDB_INDEX_USAGE | HIST_TIDB_INDEX_USAGE | Index usage statistics |
+| TIDB_STATEMENTS_STATS | HIST_TIDB_STATEMENTS_STATS | Statement statistics |
+| CLIENT_ERRORS_SUMMARY_BY_HOST | HIST_CLIENT_ERRORS_SUMMARY_BY_HOST | Client error summaries by host |
+| CLIENT_ERRORS_SUMMARY_BY_USER | HIST_CLIENT_ERRORS_SUMMARY_BY_USER | Client error summaries by user |
+| CLIENT_ERRORS_SUMMARY_GLOBAL | HIST_CLIENT_ERRORS_SUMMARY_GLOBAL | Client error summaries by global |
+
+The snapshot sampling interval may be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set interval to 15 minutes
+```
+
+## Taking Manual Snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
+## Time-based Sampling Process (Every 5 seconds by default)
+
+The time-based sampling process, which runs every 1 to 600 seconds, samples data from various monitoring tables.
+
+When the time-base sampling process runs all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp and instance ID.
+
+Unlike the Snapshot Sampling process, a row will not be added to the `HIST_SNAPSHOTS` table.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| PROCESSLIST | HIST_PROCESSLIST | Active sessions
+| DATA_LOCK_WAITS | HIST_DATA_LOCK_WAITS | Data lock waits |
+| TIDB_TRX | HIST_TIDB_TRX | Active transactions |
+| MEMORY_USAGE | HIST_MEMORY_USAGE | Memory usage |
+| DEADLOCKS | HIST_DEADLOCKS | Deadlock information |
path: workloadrepo.md
user: login: hfxsd
body: ```suggestion
| `PROCESSLIST` | `HIST_PROCESSLIST` | Active sessions |
| `DATA_LOCK_WAITS` | `HIST_DATA_LOCK_WAITS` | Data lock waits |
| `TIDB_TRX` | `HIST_TIDB_TRX` | Active transactions |
| `MEMORY_USAGE` | `HIST_MEMORY_USAGE` | Memory usage |
| `DEADLOCKS` | `HIST_DEADLOCKS` | Deadlock information |
```
created_at: 2025-03-24T02:25:57Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: The workload repository is a system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the following system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data Collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot Sampling Process (Hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into HIST_SNAPSHOTS, capturing the snapshot’s ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| TIDB_INDEX_USAGE | HIST_TIDB_INDEX_USAGE | Index usage statistics |
+| TIDB_STATEMENTS_STATS | HIST_TIDB_STATEMENTS_STATS | Statement statistics |
+| CLIENT_ERRORS_SUMMARY_BY_HOST | HIST_CLIENT_ERRORS_SUMMARY_BY_HOST | Client error summaries by host |
+| CLIENT_ERRORS_SUMMARY_BY_USER | HIST_CLIENT_ERRORS_SUMMARY_BY_USER | Client error summaries by user |
+| CLIENT_ERRORS_SUMMARY_GLOBAL | HIST_CLIENT_ERRORS_SUMMARY_GLOBAL | Client error summaries by global |
+
+The snapshot sampling interval may be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set interval to 15 minutes
+```
+
+## Taking Manual Snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
+## Time-based Sampling Process (Every 5 seconds by default)
+
+The time-based sampling process, which runs every 1 to 600 seconds, samples data from various monitoring tables.
+
+When the time-base sampling process runs all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp and instance ID.
+
+Unlike the Snapshot Sampling process, a row will not be added to the `HIST_SNAPSHOTS` table.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| PROCESSLIST | HIST_PROCESSLIST | Active sessions
+| DATA_LOCK_WAITS | HIST_DATA_LOCK_WAITS | Data lock waits |
+| TIDB_TRX | HIST_TIDB_TRX | Active transactions |
+| MEMORY_USAGE | HIST_MEMORY_USAGE | Memory usage |
+| DEADLOCKS | HIST_DEADLOCKS | Deadlock information |
+
+The time-based sampling interval may be controlled with [tidb_workload_repository_active_sampling_interval](/system-variables.md#tidb_workload_repository_active_sampling_interval):
path: workloadrepo.md
user: login: hfxsd
body: ```suggestion
The time-based sampling interval might be controlled with [`tidb_workload_repository_active_sampling_interval`](/system-variables.md#tidb_workload_repository_active_sampling_interval-new-in-v9.0.0):
```
created_at: 2025-03-24T02:26:35Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: The workload repository is a system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the following system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data Collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot Sampling Process (Hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into HIST_SNAPSHOTS, capturing the snapshot’s ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| TIDB_INDEX_USAGE | HIST_TIDB_INDEX_USAGE | Index usage statistics |
+| TIDB_STATEMENTS_STATS | HIST_TIDB_STATEMENTS_STATS | Statement statistics |
+| CLIENT_ERRORS_SUMMARY_BY_HOST | HIST_CLIENT_ERRORS_SUMMARY_BY_HOST | Client error summaries by host |
+| CLIENT_ERRORS_SUMMARY_BY_USER | HIST_CLIENT_ERRORS_SUMMARY_BY_USER | Client error summaries by user |
+| CLIENT_ERRORS_SUMMARY_GLOBAL | HIST_CLIENT_ERRORS_SUMMARY_GLOBAL | Client error summaries by global |
+
+The snapshot sampling interval may be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set interval to 15 minutes
+```
+
+## Taking Manual Snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
+## Time-based Sampling Process (Every 5 seconds by default)
+
+The time-based sampling process, which runs every 1 to 600 seconds, samples data from various monitoring tables.
+
+When the time-base sampling process runs all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp and instance ID.
+
+Unlike the Snapshot Sampling process, a row will not be added to the `HIST_SNAPSHOTS` table.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| PROCESSLIST | HIST_PROCESSLIST | Active sessions
+| DATA_LOCK_WAITS | HIST_DATA_LOCK_WAITS | Data lock waits |
+| TIDB_TRX | HIST_TIDB_TRX | Active transactions |
+| MEMORY_USAGE | HIST_MEMORY_USAGE | Memory usage |
+| DEADLOCKS | HIST_DEADLOCKS | Deadlock information |
+
+The time-based sampling interval may be controlled with [tidb_workload_repository_active_sampling_interval](/system-variables.md#tidb_workload_repository_active_sampling_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_active_sampling_interval = 20; -- set interval to 20 seconds
path: workloadrepo.md
user: login: hfxsd
body: ```suggestion
SET GLOBAL tidb_workload_repository_active_sampling_interval = 20; -- set the interval to 20 seconds
```
created_at: 2025-03-24T02:26:44Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: The workload repository is a system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the following system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data Collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot Sampling Process (Hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into HIST_SNAPSHOTS, capturing the snapshot’s ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| TIDB_INDEX_USAGE | HIST_TIDB_INDEX_USAGE | Index usage statistics |
+| TIDB_STATEMENTS_STATS | HIST_TIDB_STATEMENTS_STATS | Statement statistics |
+| CLIENT_ERRORS_SUMMARY_BY_HOST | HIST_CLIENT_ERRORS_SUMMARY_BY_HOST | Client error summaries by host |
+| CLIENT_ERRORS_SUMMARY_BY_USER | HIST_CLIENT_ERRORS_SUMMARY_BY_USER | Client error summaries by user |
+| CLIENT_ERRORS_SUMMARY_GLOBAL | HIST_CLIENT_ERRORS_SUMMARY_GLOBAL | Client error summaries by global |
+
+The snapshot sampling interval may be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set interval to 15 minutes
+```
+
+## Taking Manual Snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
+## Time-based Sampling Process (Every 5 seconds by default)
+
+The time-based sampling process, which runs every 1 to 600 seconds, samples data from various monitoring tables.
+
+When the time-base sampling process runs all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp and instance ID.
+
+Unlike the Snapshot Sampling process, a row will not be added to the `HIST_SNAPSHOTS` table.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| PROCESSLIST | HIST_PROCESSLIST | Active sessions
+| DATA_LOCK_WAITS | HIST_DATA_LOCK_WAITS | Data lock waits |
+| TIDB_TRX | HIST_TIDB_TRX | Active transactions |
+| MEMORY_USAGE | HIST_MEMORY_USAGE | Memory usage |
+| DEADLOCKS | HIST_DEADLOCKS | Deadlock information |
+
+The time-based sampling interval may be controlled with [tidb_workload_repository_active_sampling_interval](/system-variables.md#tidb_workload_repository_active_sampling_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_active_sampling_interval = 20; -- set interval to 20 seconds
+```
+
+## Data Retention
path: workloadrepo.md
user: login: hfxsd
body: ```suggestion
## Data retention
```
created_at: 2025-03-24T02:26:52Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: The workload repository is a system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the following system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data Collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot Sampling Process (Hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into HIST_SNAPSHOTS, capturing the snapshot’s ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| TIDB_INDEX_USAGE | HIST_TIDB_INDEX_USAGE | Index usage statistics |
+| TIDB_STATEMENTS_STATS | HIST_TIDB_STATEMENTS_STATS | Statement statistics |
+| CLIENT_ERRORS_SUMMARY_BY_HOST | HIST_CLIENT_ERRORS_SUMMARY_BY_HOST | Client error summaries by host |
+| CLIENT_ERRORS_SUMMARY_BY_USER | HIST_CLIENT_ERRORS_SUMMARY_BY_USER | Client error summaries by user |
+| CLIENT_ERRORS_SUMMARY_GLOBAL | HIST_CLIENT_ERRORS_SUMMARY_GLOBAL | Client error summaries by global |
+
+The snapshot sampling interval may be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set interval to 15 minutes
+```
+
+## Taking Manual Snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
+## Time-based Sampling Process (Every 5 seconds by default)
+
+The time-based sampling process, which runs every 1 to 600 seconds, samples data from various monitoring tables.
+
+When the time-base sampling process runs all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp and instance ID.
+
+Unlike the Snapshot Sampling process, a row will not be added to the `HIST_SNAPSHOTS` table.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| PROCESSLIST | HIST_PROCESSLIST | Active sessions
+| DATA_LOCK_WAITS | HIST_DATA_LOCK_WAITS | Data lock waits |
+| TIDB_TRX | HIST_TIDB_TRX | Active transactions |
+| MEMORY_USAGE | HIST_MEMORY_USAGE | Memory usage |
+| DEADLOCKS | HIST_DEADLOCKS | Deadlock information |
+
+The time-based sampling interval may be controlled with [tidb_workload_repository_active_sampling_interval](/system-variables.md#tidb_workload_repository_active_sampling_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_active_sampling_interval = 20; -- set interval to 20 seconds
+```
+
+## Data Retention
+
+The system automatically purges data based on the retention period setting, using partitions for efficient data management.
+
+The [tidb_workload_repository_retention_days](/system-variables.md#tidb_workload_repository_retention_days) variable controls the retention period for historical data in the Workload Repository. For example, to keep data for 30 days:
path: workloadrepo.md
user: login: hfxsd
body: ```suggestion
The [`tidb_workload_repository_retention_days`](/system-variables.md#tidb_workload_repository_retention_days-new-in-v9.0.0) variable controls the retention period for historical data in the Workload Repository. For example, to keep data for 30 days, run the following:
```
created_at: 2025-03-24T02:27:16Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: The workload repository is a system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the following system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data Collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot Sampling Process (Hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into HIST_SNAPSHOTS, capturing the snapshot’s ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| TIDB_INDEX_USAGE | HIST_TIDB_INDEX_USAGE | Index usage statistics |
+| TIDB_STATEMENTS_STATS | HIST_TIDB_STATEMENTS_STATS | Statement statistics |
+| CLIENT_ERRORS_SUMMARY_BY_HOST | HIST_CLIENT_ERRORS_SUMMARY_BY_HOST | Client error summaries by host |
+| CLIENT_ERRORS_SUMMARY_BY_USER | HIST_CLIENT_ERRORS_SUMMARY_BY_USER | Client error summaries by user |
+| CLIENT_ERRORS_SUMMARY_GLOBAL | HIST_CLIENT_ERRORS_SUMMARY_GLOBAL | Client error summaries by global |
+
+The snapshot sampling interval may be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set interval to 15 minutes
+```
+
+## Taking Manual Snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
+## Time-based Sampling Process (Every 5 seconds by default)
+
+The time-based sampling process, which runs every 1 to 600 seconds, samples data from various monitoring tables.
+
+When the time-base sampling process runs all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp and instance ID.
+
+Unlike the Snapshot Sampling process, a row will not be added to the `HIST_SNAPSHOTS` table.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| PROCESSLIST | HIST_PROCESSLIST | Active sessions
+| DATA_LOCK_WAITS | HIST_DATA_LOCK_WAITS | Data lock waits |
+| TIDB_TRX | HIST_TIDB_TRX | Active transactions |
+| MEMORY_USAGE | HIST_MEMORY_USAGE | Memory usage |
+| DEADLOCKS | HIST_DEADLOCKS | Deadlock information |
+
+The time-based sampling interval may be controlled with [tidb_workload_repository_active_sampling_interval](/system-variables.md#tidb_workload_repository_active_sampling_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_active_sampling_interval = 20; -- set interval to 20 seconds
+```
+
+## Data Retention
+
+The system automatically purges data based on the retention period setting, using partitions for efficient data management.
+
+The [tidb_workload_repository_retention_days](/system-variables.md#tidb_workload_repository_retention_days) variable controls the retention period for historical data in the Workload Repository. For example, to keep data for 30 days:
+
+```sql
+SET GLOBAL tidb_workload_repository_retention_days = 30;
+```
+
+A higher value for this variable allows for longer data retention, which may be beneficial for workload analysis, but will increase storage requirements.
path: workloadrepo.md
user: login: hfxsd
body: ```suggestion
A higher value for this variable allows for longer data retention, which might be beneficial for workload analysis, but will increase storage requirements.
```
created_at: 2025-03-24T02:28:09Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: The workload repository is a system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the following system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data Collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot Sampling Process (Hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into HIST_SNAPSHOTS, capturing the snapshot’s ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| TIDB_INDEX_USAGE | HIST_TIDB_INDEX_USAGE | Index usage statistics |
+| TIDB_STATEMENTS_STATS | HIST_TIDB_STATEMENTS_STATS | Statement statistics |
+| CLIENT_ERRORS_SUMMARY_BY_HOST | HIST_CLIENT_ERRORS_SUMMARY_BY_HOST | Client error summaries by host |
+| CLIENT_ERRORS_SUMMARY_BY_USER | HIST_CLIENT_ERRORS_SUMMARY_BY_USER | Client error summaries by user |
+| CLIENT_ERRORS_SUMMARY_GLOBAL | HIST_CLIENT_ERRORS_SUMMARY_GLOBAL | Client error summaries by global |
+
+The snapshot sampling interval may be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set interval to 15 minutes
+```
+
+## Taking Manual Snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
+## Time-based Sampling Process (Every 5 seconds by default)
+
+The time-based sampling process, which runs every 1 to 600 seconds, samples data from various monitoring tables.
+
+When the time-base sampling process runs all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp and instance ID.
+
+Unlike the Snapshot Sampling process, a row will not be added to the `HIST_SNAPSHOTS` table.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| PROCESSLIST | HIST_PROCESSLIST | Active sessions
+| DATA_LOCK_WAITS | HIST_DATA_LOCK_WAITS | Data lock waits |
+| TIDB_TRX | HIST_TIDB_TRX | Active transactions |
+| MEMORY_USAGE | HIST_MEMORY_USAGE | Memory usage |
+| DEADLOCKS | HIST_DEADLOCKS | Deadlock information |
+
+The time-based sampling interval may be controlled with [tidb_workload_repository_active_sampling_interval](/system-variables.md#tidb_workload_repository_active_sampling_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_active_sampling_interval = 20; -- set interval to 20 seconds
+```
+
+## Data Retention
+
+The system automatically purges data based on the retention period setting, using partitions for efficient data management.
+
+The [tidb_workload_repository_retention_days](/system-variables.md#tidb_workload_repository_retention_days) variable controls the retention period for historical data in the Workload Repository. For example, to keep data for 30 days:
+
+```sql
+SET GLOBAL tidb_workload_repository_retention_days = 30;
+```
+
+A higher value for this variable allows for longer data retention, which may be beneficial for workload analysis, but will increase storage requirements.
+
+## Notes
+
+- Enabling the Workload Repository may have a small performance impact on the system.
+- Setting sampling intervals too low may increase system overhead.
+- Setting retention days to 0 disables automatic purging of old data.
path: workloadrepo.md
user: login: hfxsd
body: ```suggestion
- Enabling the Workload Repository might have a small performance impact on the system.
- Setting sampling intervals too low might increase system overhead.
- Setting retention days to `0` disables automatic purging of old data.
```
created_at: 2025-03-24T02:28:42Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: The workload repository is a system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the following system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data Collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot Sampling Process (Hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into HIST_SNAPSHOTS, capturing the snapshot’s ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| TIDB_INDEX_USAGE | HIST_TIDB_INDEX_USAGE | Index usage statistics |
+| TIDB_STATEMENTS_STATS | HIST_TIDB_STATEMENTS_STATS | Statement statistics |
+| CLIENT_ERRORS_SUMMARY_BY_HOST | HIST_CLIENT_ERRORS_SUMMARY_BY_HOST | Client error summaries by host |
+| CLIENT_ERRORS_SUMMARY_BY_USER | HIST_CLIENT_ERRORS_SUMMARY_BY_USER | Client error summaries by user |
+| CLIENT_ERRORS_SUMMARY_GLOBAL | HIST_CLIENT_ERRORS_SUMMARY_GLOBAL | Client error summaries by global |
+
+The snapshot sampling interval may be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set interval to 15 minutes
+```
+
+## Taking Manual Snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
+## Time-based Sampling Process (Every 5 seconds by default)
+
+The time-based sampling process, which runs every 1 to 600 seconds, samples data from various monitoring tables.
+
+When the time-base sampling process runs all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp and instance ID.
+
+Unlike the Snapshot Sampling process, a row will not be added to the `HIST_SNAPSHOTS` table.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| PROCESSLIST | HIST_PROCESSLIST | Active sessions
+| DATA_LOCK_WAITS | HIST_DATA_LOCK_WAITS | Data lock waits |
+| TIDB_TRX | HIST_TIDB_TRX | Active transactions |
+| MEMORY_USAGE | HIST_MEMORY_USAGE | Memory usage |
+| DEADLOCKS | HIST_DEADLOCKS | Deadlock information |
+
+The time-based sampling interval may be controlled with [tidb_workload_repository_active_sampling_interval](/system-variables.md#tidb_workload_repository_active_sampling_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_active_sampling_interval = 20; -- set interval to 20 seconds
+```
+
+## Data Retention
+
+The system automatically purges data based on the retention period setting, using partitions for efficient data management.
+
+The [tidb_workload_repository_retention_days](/system-variables.md#tidb_workload_repository_retention_days) variable controls the retention period for historical data in the Workload Repository. For example, to keep data for 30 days:
+
+```sql
+SET GLOBAL tidb_workload_repository_retention_days = 30;
+```
+
+A higher value for this variable allows for longer data retention, which may be beneficial for workload analysis, but will increase storage requirements.
+
+## Notes
+
+- Enabling the Workload Repository may have a small performance impact on the system.
+- Setting sampling intervals too low may increase system overhead.
+- Setting retention days to 0 disables automatic purging of old data.
+
+## Best Practices
+
+1. Start with default settings and adjust based on your monitoring needs.
+2. Set reasonable retention periods based on your storage capacity.
+3. Monitor the size of the `WORKLOAD_SCHEMA` database.
+4. Use longer sampling intervals in production environments to minimize overhead.
path: workloadrepo.md
user: login: hfxsd
body: ```suggestion
## Best practices

- Start with default settings and adjust based on your monitoring needs.
- Set reasonable retention periods based on your storage capacity.
- Monitor the size of the `WORKLOAD_SCHEMA` database.
- Use longer sampling intervals in production environments to minimize overhead.
```
created_at: 2025-03-24T02:29:14Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: The workload repository is a system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the following system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data Collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot Sampling Process (Hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into HIST_SNAPSHOTS, capturing the snapshot’s ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| TIDB_INDEX_USAGE | HIST_TIDB_INDEX_USAGE | Index usage statistics |
+| TIDB_STATEMENTS_STATS | HIST_TIDB_STATEMENTS_STATS | Statement statistics |
+| CLIENT_ERRORS_SUMMARY_BY_HOST | HIST_CLIENT_ERRORS_SUMMARY_BY_HOST | Client error summaries by host |
+| CLIENT_ERRORS_SUMMARY_BY_USER | HIST_CLIENT_ERRORS_SUMMARY_BY_USER | Client error summaries by user |
+| CLIENT_ERRORS_SUMMARY_GLOBAL | HIST_CLIENT_ERRORS_SUMMARY_GLOBAL | Client error summaries by global |
+
+The snapshot sampling interval may be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval):
path: workloadrepo.md
user: login: wddevries
body: I changed 'may be' to 'can be.' I also fixed the link though.
created_at: 2025-03-25T19:15:27Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: The workload repository is a system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the following system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data Collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot Sampling Process (Hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into HIST_SNAPSHOTS, capturing the snapshot’s ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| TIDB_INDEX_USAGE | HIST_TIDB_INDEX_USAGE | Index usage statistics |
+| TIDB_STATEMENTS_STATS | HIST_TIDB_STATEMENTS_STATS | Statement statistics |
+| CLIENT_ERRORS_SUMMARY_BY_HOST | HIST_CLIENT_ERRORS_SUMMARY_BY_HOST | Client error summaries by host |
+| CLIENT_ERRORS_SUMMARY_BY_USER | HIST_CLIENT_ERRORS_SUMMARY_BY_USER | Client error summaries by user |
+| CLIENT_ERRORS_SUMMARY_GLOBAL | HIST_CLIENT_ERRORS_SUMMARY_GLOBAL | Client error summaries by global |
+
+The snapshot sampling interval may be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set interval to 15 minutes
+```
+
+## Taking Manual Snapshots
path: workloadrepo.md
user: login: wddevries
body: It should either be 'Taking manual snapshots' or 'Manual snapshots.' I changed it to the latter, which seems in line with what you wanted.
created_at: 2025-03-25T19:15:49Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: The workload repository is a system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the following system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data Collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot Sampling Process (Hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into HIST_SNAPSHOTS, capturing the snapshot’s ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| TIDB_INDEX_USAGE | HIST_TIDB_INDEX_USAGE | Index usage statistics |
+| TIDB_STATEMENTS_STATS | HIST_TIDB_STATEMENTS_STATS | Statement statistics |
+| CLIENT_ERRORS_SUMMARY_BY_HOST | HIST_CLIENT_ERRORS_SUMMARY_BY_HOST | Client error summaries by host |
+| CLIENT_ERRORS_SUMMARY_BY_USER | HIST_CLIENT_ERRORS_SUMMARY_BY_USER | Client error summaries by user |
+| CLIENT_ERRORS_SUMMARY_GLOBAL | HIST_CLIENT_ERRORS_SUMMARY_GLOBAL | Client error summaries by global |
+
+The snapshot sampling interval may be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set interval to 15 minutes
+```
+
+## Taking Manual Snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
+## Time-based Sampling Process (Every 5 seconds by default)
+
+The time-based sampling process, which runs every 1 to 600 seconds, samples data from various monitoring tables.
+
+When the time-base sampling process runs all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp and instance ID.
+
+Unlike the Snapshot Sampling process, a row will not be added to the `HIST_SNAPSHOTS` table.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| PROCESSLIST | HIST_PROCESSLIST | Active sessions
+| DATA_LOCK_WAITS | HIST_DATA_LOCK_WAITS | Data lock waits |
+| TIDB_TRX | HIST_TIDB_TRX | Active transactions |
+| MEMORY_USAGE | HIST_MEMORY_USAGE | Memory usage |
+| DEADLOCKS | HIST_DEADLOCKS | Deadlock information |
+
+The time-based sampling interval may be controlled with [tidb_workload_repository_active_sampling_interval](/system-variables.md#tidb_workload_repository_active_sampling_interval):
path: workloadrepo.md
user: login: wddevries
body: I fixed the link and changed 'may' to 'can.'
created_at: 2025-03-25T19:16:28Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: The workload repository is a system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the following system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data Collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot Sampling Process (Hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into HIST_SNAPSHOTS, capturing the snapshot’s ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| TIDB_INDEX_USAGE | HIST_TIDB_INDEX_USAGE | Index usage statistics |
+| TIDB_STATEMENTS_STATS | HIST_TIDB_STATEMENTS_STATS | Statement statistics |
+| CLIENT_ERRORS_SUMMARY_BY_HOST | HIST_CLIENT_ERRORS_SUMMARY_BY_HOST | Client error summaries by host |
+| CLIENT_ERRORS_SUMMARY_BY_USER | HIST_CLIENT_ERRORS_SUMMARY_BY_USER | Client error summaries by user |
+| CLIENT_ERRORS_SUMMARY_GLOBAL | HIST_CLIENT_ERRORS_SUMMARY_GLOBAL | Client error summaries by global |
+
+The snapshot sampling interval may be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set interval to 15 minutes
+```
+
+## Taking Manual Snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
+## Time-based Sampling Process (Every 5 seconds by default)
+
+The time-based sampling process, which runs every 1 to 600 seconds, samples data from various monitoring tables.
+
+When the time-base sampling process runs all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp and instance ID.
+
+Unlike the Snapshot Sampling process, a row will not be added to the `HIST_SNAPSHOTS` table.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| PROCESSLIST | HIST_PROCESSLIST | Active sessions
+| DATA_LOCK_WAITS | HIST_DATA_LOCK_WAITS | Data lock waits |
+| TIDB_TRX | HIST_TIDB_TRX | Active transactions |
+| MEMORY_USAGE | HIST_MEMORY_USAGE | Memory usage |
+| DEADLOCKS | HIST_DEADLOCKS | Deadlock information |
+
+The time-based sampling interval may be controlled with [tidb_workload_repository_active_sampling_interval](/system-variables.md#tidb_workload_repository_active_sampling_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_active_sampling_interval = 20; -- set interval to 20 seconds
+```
+
+## Data Retention
+
+The system automatically purges data based on the retention period setting, using partitions for efficient data management.
+
+The [tidb_workload_repository_retention_days](/system-variables.md#tidb_workload_repository_retention_days) variable controls the retention period for historical data in the Workload Repository. For example, to keep data for 30 days:
+
+```sql
+SET GLOBAL tidb_workload_repository_retention_days = 30;
+```
+
+A higher value for this variable allows for longer data retention, which may be beneficial for workload analysis, but will increase storage requirements.
path: workloadrepo.md
user: login: wddevries
body: I don't think changing 'may' to 'might' improves this sentence.  It suggests a higher level of skepticism than I intended.
created_at: 2025-03-25T19:18:27Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: The workload repository is a system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the following system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data Collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot Sampling Process (Hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into HIST_SNAPSHOTS, capturing the snapshot’s ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| TIDB_INDEX_USAGE | HIST_TIDB_INDEX_USAGE | Index usage statistics |
+| TIDB_STATEMENTS_STATS | HIST_TIDB_STATEMENTS_STATS | Statement statistics |
+| CLIENT_ERRORS_SUMMARY_BY_HOST | HIST_CLIENT_ERRORS_SUMMARY_BY_HOST | Client error summaries by host |
+| CLIENT_ERRORS_SUMMARY_BY_USER | HIST_CLIENT_ERRORS_SUMMARY_BY_USER | Client error summaries by user |
+| CLIENT_ERRORS_SUMMARY_GLOBAL | HIST_CLIENT_ERRORS_SUMMARY_GLOBAL | Client error summaries by global |
+
+The snapshot sampling interval may be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set interval to 15 minutes
+```
+
+## Taking Manual Snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
+## Time-based Sampling Process (Every 5 seconds by default)
+
+The time-based sampling process, which runs every 1 to 600 seconds, samples data from various monitoring tables.
+
+When the time-base sampling process runs all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp and instance ID.
+
+Unlike the Snapshot Sampling process, a row will not be added to the `HIST_SNAPSHOTS` table.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| PROCESSLIST | HIST_PROCESSLIST | Active sessions
+| DATA_LOCK_WAITS | HIST_DATA_LOCK_WAITS | Data lock waits |
+| TIDB_TRX | HIST_TIDB_TRX | Active transactions |
+| MEMORY_USAGE | HIST_MEMORY_USAGE | Memory usage |
+| DEADLOCKS | HIST_DEADLOCKS | Deadlock information |
+
+The time-based sampling interval may be controlled with [tidb_workload_repository_active_sampling_interval](/system-variables.md#tidb_workload_repository_active_sampling_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_active_sampling_interval = 20; -- set interval to 20 seconds
+```
+
+## Data Retention
+
+The system automatically purges data based on the retention period setting, using partitions for efficient data management.
+
+The [tidb_workload_repository_retention_days](/system-variables.md#tidb_workload_repository_retention_days) variable controls the retention period for historical data in the Workload Repository. For example, to keep data for 30 days:
+
+```sql
+SET GLOBAL tidb_workload_repository_retention_days = 30;
+```
+
+A higher value for this variable allows for longer data retention, which may be beneficial for workload analysis, but will increase storage requirements.
+
+## Notes
+
+- Enabling the Workload Repository may have a small performance impact on the system.
+- Setting sampling intervals too low may increase system overhead.
+- Setting retention days to 0 disables automatic purging of old data.
path: workloadrepo.md
user: login: wddevries
body: I added the backticks to the number, but 'may' seems better to than 'might' to me.
created_at: 2025-03-25T19:19:32Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: The workload repository is a system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the following system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data Collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot Sampling Process (Hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into HIST_SNAPSHOTS, capturing the snapshot’s ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| TIDB_INDEX_USAGE | HIST_TIDB_INDEX_USAGE | Index usage statistics |
+| TIDB_STATEMENTS_STATS | HIST_TIDB_STATEMENTS_STATS | Statement statistics |
+| CLIENT_ERRORS_SUMMARY_BY_HOST | HIST_CLIENT_ERRORS_SUMMARY_BY_HOST | Client error summaries by host |
+| CLIENT_ERRORS_SUMMARY_BY_USER | HIST_CLIENT_ERRORS_SUMMARY_BY_USER | Client error summaries by user |
+| CLIENT_ERRORS_SUMMARY_GLOBAL | HIST_CLIENT_ERRORS_SUMMARY_GLOBAL | Client error summaries by global |
+
+The snapshot sampling interval may be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set interval to 15 minutes
+```
+
+## Taking Manual Snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
+## Time-based Sampling Process (Every 5 seconds by default)
+
+The time-based sampling process, which runs every 1 to 600 seconds, samples data from various monitoring tables.
+
+When the time-base sampling process runs all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp and instance ID.
+
+Unlike the Snapshot Sampling process, a row will not be added to the `HIST_SNAPSHOTS` table.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| PROCESSLIST | HIST_PROCESSLIST | Active sessions
+| DATA_LOCK_WAITS | HIST_DATA_LOCK_WAITS | Data lock waits |
+| TIDB_TRX | HIST_TIDB_TRX | Active transactions |
+| MEMORY_USAGE | HIST_MEMORY_USAGE | Memory usage |
+| DEADLOCKS | HIST_DEADLOCKS | Deadlock information |
+
+The time-based sampling interval may be controlled with [tidb_workload_repository_active_sampling_interval](/system-variables.md#tidb_workload_repository_active_sampling_interval):
+
+```sql
+SET GLOBAL tidb_workload_repository_active_sampling_interval = 20; -- set interval to 20 seconds
+```
+
+## Data Retention
+
+The system automatically purges data based on the retention period setting, using partitions for efficient data management.
+
+The [tidb_workload_repository_retention_days](/system-variables.md#tidb_workload_repository_retention_days) variable controls the retention period for historical data in the Workload Repository. For example, to keep data for 30 days:
+
+```sql
+SET GLOBAL tidb_workload_repository_retention_days = 30;
+```
+
+A higher value for this variable allows for longer data retention, which may be beneficial for workload analysis, but will increase storage requirements.
path: workloadrepo.md
user: login: hfxsd
body: We follow this rule: https://developers.google.cn/style/word-list#may
created_at: 2025-03-26T01:20:45Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: The workload repository is a system for collecting and storing historical workload data from a TiDB cluster.
path: workloadrepo.md
user: login: wddevries
body: This now starts with "Introduces the workload repository system."
created_at: 2025-03-26T04:57:01Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md/tidb_workload_repository_dest-new-in-v9.0.0) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data Collection
path: workloadrepo.md
user: login: hfxsd
body: ```suggestion
## Data collection
```
created_at: 2025-03-27T02:08:45Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md/tidb_workload_repository_dest-new-in-v9.0.0) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot sampling process (hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into `HIST_SNAPSHOTS`, capturing the snapshot ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| `TIDB_INDEX_USAGE` | `HIST_TIDB_INDEX_USAGE` | Index usage statistics |
+| `TIDB_STATEMENTS_STATS` | `HIST_TIDB_STATEMENTS_STATS` | Statement statistics |
+| `CLIENT_ERRORS_SUMMARY_BY_HOST` | `HIST_CLIENT_ERRORS_SUMMARY_BY_HOST` | Client error summaries by host |
+| `CLIENT_ERRORS_SUMMARY_BY_USER` | `HIST_CLIENT_ERRORS_SUMMARY_BY_USER` | Client error summaries by user |
+| `CLIENT_ERRORS_SUMMARY_GLOBAL` | `HIST_CLIENT_ERRORS_SUMMARY_GLOBAL` | Client error summaries by global |
+
+The snapshot sampling interval can be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval-new-in-v9.0.0):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set the interval to 15 minutes
+```
+
+## Manual snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using the following SQL statement:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
+## Time-based sampling process (every 5 seconds by default)
+
+The time-based sampling process, which runs every 1 to 600 seconds, samples data from various monitoring tables.
+
+When the time-base sampling process runs, all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp and instance ID.
path: workloadrepo.md
user: login: hfxsd
body: ```suggestion
When the time-base sampling process runs, all rows from the source tables are copied to the corresponding history tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp and instance ID.
```
created_at: 2025-03-27T02:17:07Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md/tidb_workload_repository_dest-new-in-v9.0.0) system variable:
path: workloadrepo.md
user: login: hfxsd
body: ```suggestion
To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md#tidb_workload_repository_dest-new-in-v9.0.0) system variable:
```
created_at: 2025-03-27T02:20:27Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md#tidb_workload_repository_dest-new-in-v9.0.0) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot sampling process (hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into `HIST_SNAPSHOTS`, capturing the snapshot ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the 'HIST_' prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
path: workloadrepo.md
user: login: hfxsd
body: ```suggestion
 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
```
created_at: 2025-03-27T02:28:45Z
author_association: COLLABORATOR
diff_hunk: @@ -4035,6 +4035,26 @@ Referenced in:
 - [SHOW [GLOBAL|SESSION] VARIABLES](/sql-statements/sql-statement-show-variables.md)
 - [System Variables](/system-variables.md#tidb_window_concurrency-new-in-v40)
 
+### tidb_workload_repository_dest
+
+- [TiDB Workload Repository](/workloadrepo.md#enabling-the-workload-repository)
+- [System Variables](/system-variables.md#tidb_workload_repository_dest)
+
+### tidb_workload_repository_active_sampling_interval
+
+- [TiDB Workload Repository](/workloadrepo.md#time-based-sampling-process-every-5-seconds-by-default)
+- [System Variables](/system-variables.md#tidb_workload_repository_dest)
+
+### tidb_workload_repository_retention_days
+
+- [TiDB Workload Repository](/workloadrepo.md#data-retention)
+- [System Variables](/system-variables.md#tidb_workload_repository_dest)
+
+### tidb_workload_repository_snapshot_interval
+
+- [TiDB Workload Repository](/workloadrepo.md#snapshot-sampling-process-hourly-by-default)
+- [System Variables](/system-variables.md#tidb_workload_repository_dest)
path: system-variable-reference.md
user: login: hfxsd
body: ```suggestion
### tidb_workload_repository_dest

- [TiDB Workload Repository](/workloadrepo.md#enabling-the-workload-repository)
- [System Variables](/system-variables.md#tidb_workload_repository_dest-new-in-v900)

### tidb_workload_repository_active_sampling_interval

- [TiDB Workload Repository](/workloadrepo.md#time-based-sampling-process-every-5-seconds-by-default)
- [System Variables](/system-variables.md#tidb_workload_repository_active_sampling_interval-new-in-v900)

### tidb_workload_repository_retention_days

- [TiDB Workload Repository](/workloadrepo.md#data-retention)
- [System Variables](/system-variables.md#tidb_workload_repository_retention_days-new-in-v900)

### tidb_workload_repository_snapshot_interval

- [TiDB Workload Repository](/workloadrepo.md#snapshot-sampling-process-hourly-by-default)
- [System Variables](/system-variables.md#tidb_workload_repository_snapshot_interval-new-in-v900)
```
created_at: 2025-03-27T02:48:12Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md#tidb_workload_repository_dest-new-in-v9.0.0) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot sampling process (hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
path: workloadrepo.md
user: login: songrijie
body: ```suggestion
The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from memory tables that save cumulative metrics. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
```
created_at: 2025-03-31T13:41:28Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md#tidb_workload_repository_dest-new-in-v9.0.0) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot sampling process (hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into `HIST_SNAPSHOTS`, capturing the snapshot ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| `TIDB_INDEX_USAGE` | `HIST_TIDB_INDEX_USAGE` | Index usage statistics |
+| `TIDB_STATEMENTS_STATS` | `HIST_TIDB_STATEMENTS_STATS` | Statement statistics |
+| `CLIENT_ERRORS_SUMMARY_BY_HOST` | `HIST_CLIENT_ERRORS_SUMMARY_BY_HOST` | Client error summaries by host |
+| `CLIENT_ERRORS_SUMMARY_BY_USER` | `HIST_CLIENT_ERRORS_SUMMARY_BY_USER` | Client error summaries by user |
+| `CLIENT_ERRORS_SUMMARY_GLOBAL` | `HIST_CLIENT_ERRORS_SUMMARY_GLOBAL` | Client error summaries by global |
+
+The snapshot sampling interval can be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval-new-in-v9.0.0):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set the interval to 15 minutes
+```
+
+## Manual snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using the following SQL statement:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
path: workloadrepo.md
user: login: songrijie
body: ```suggestion
Manual snapshot doesn't change the next occurrence of auto snapshots. 

```
created_at: 2025-03-31T13:46:51Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md#tidb_workload_repository_dest-new-in-v9.0.0) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot sampling process (hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into `HIST_SNAPSHOTS`, capturing the snapshot ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| `TIDB_INDEX_USAGE` | `HIST_TIDB_INDEX_USAGE` | Index usage statistics |
+| `TIDB_STATEMENTS_STATS` | `HIST_TIDB_STATEMENTS_STATS` | Statement statistics |
+| `CLIENT_ERRORS_SUMMARY_BY_HOST` | `HIST_CLIENT_ERRORS_SUMMARY_BY_HOST` | Client error summaries by host |
+| `CLIENT_ERRORS_SUMMARY_BY_USER` | `HIST_CLIENT_ERRORS_SUMMARY_BY_USER` | Client error summaries by user |
+| `CLIENT_ERRORS_SUMMARY_GLOBAL` | `HIST_CLIENT_ERRORS_SUMMARY_GLOBAL` | Client error summaries by global |
+
+The snapshot sampling interval can be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval-new-in-v9.0.0):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set the interval to 15 minutes
+```
+
+## Manual snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using the following SQL statement:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
+## Time-based sampling process (every 5 seconds by default)
+
+The time-based sampling process, which runs every 1 to 600 seconds, samples data from various monitoring tables.
path: workloadrepo.md
user: login: songrijie
body: ```suggestion
The time-based sampling process, which runs every 1 to 600 seconds, samples data from tables that save the instant status of the cluster.
```
created_at: 2025-03-31T13:48:31Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md#tidb_workload_repository_dest-new-in-v9.0.0) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot sampling process (hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into `HIST_SNAPSHOTS`, capturing the snapshot ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| `TIDB_INDEX_USAGE` | `HIST_TIDB_INDEX_USAGE` | Index usage statistics |
+| `TIDB_STATEMENTS_STATS` | `HIST_TIDB_STATEMENTS_STATS` | Statement statistics |
+| `CLIENT_ERRORS_SUMMARY_BY_HOST` | `HIST_CLIENT_ERRORS_SUMMARY_BY_HOST` | Client error summaries by host |
+| `CLIENT_ERRORS_SUMMARY_BY_USER` | `HIST_CLIENT_ERRORS_SUMMARY_BY_USER` | Client error summaries by user |
+| `CLIENT_ERRORS_SUMMARY_GLOBAL` | `HIST_CLIENT_ERRORS_SUMMARY_GLOBAL` | Client error summaries by global |
+
+The snapshot sampling interval can be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval-new-in-v9.0.0):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set the interval to 15 minutes
+```
+
+## Manual snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using the following SQL statement:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
+## Time-based sampling process (every 5 seconds by default)
+
+The time-based sampling process, which runs every 1 to 600 seconds, samples data from various monitoring tables.
+
+When the time-base sampling process runs, all rows from the source tables are copied to the corresponding history tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp and instance ID.
+
+Unlike the snapshot sampling process, a row will not be added to the `HIST_SNAPSHOTS` table.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| `PROCESSLIST` | `HIST_PROCESSLIST` | Active sessions |
+| `DATA_LOCK_WAITS` | `HIST_DATA_LOCK_WAITS` | Data lock waits |
+| `TIDB_TRX` | `HIST_TIDB_TRX` | Active transactions |
+| `MEMORY_USAGE` | `HIST_MEMORY_USAGE` | Memory usage |
+| `DEADLOCKS` | `HIST_DEADLOCKS` | Deadlock information |
+
+The time-based sampling interval can be controlled with [`tidb_workload_repository_active_sampling_interval`](/system-variables.md#tidb_workload_repository_active_sampling_interval-new-in-v9.0.0):
+
+```sql
+SET GLOBAL tidb_workload_repository_active_sampling_interval = 20; -- set the interval to 20 seconds
+```
+
path: workloadrepo.md
user: login: songrijie
body: ```suggestion
Setting the value to `0` disables the Time-based Sampling Process

```
created_at: 2025-03-31T13:52:26Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
path: workloadrepo.md
user: login: songrijie
body: ```suggestion

Possible Scenarios for Workload Repository:

* **Troubleshooting** Database issues may occur at specific moments or during past periods. Effective diagnosis requires reviewing historical activities or events to identify the root cause.

* **Automation** Database automation relies on historical workload data. By deeply analyzing richer historical data, TiDB can provide more accurate advice for maintenance and performance tuning, such as index advisor and SQL binding advisor.

```
created_at: 2025-03-31T14:36:51Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
path: workloadrepo.md
user: login: wddevries
body: Unless I am mistaken, neither of this use-cases is complete.  After we have completed features that require the Workload Repository, we should add links to them here. 
created_at: 2025-04-04T03:50:50Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md#tidb_workload_repository_dest-new-in-v9.0.0) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot sampling process (hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into `HIST_SNAPSHOTS`, capturing the snapshot ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| `TIDB_INDEX_USAGE` | `HIST_TIDB_INDEX_USAGE` | Index usage statistics |
+| `TIDB_STATEMENTS_STATS` | `HIST_TIDB_STATEMENTS_STATS` | Statement statistics |
+| `CLIENT_ERRORS_SUMMARY_BY_HOST` | `HIST_CLIENT_ERRORS_SUMMARY_BY_HOST` | Client error summaries by host |
+| `CLIENT_ERRORS_SUMMARY_BY_USER` | `HIST_CLIENT_ERRORS_SUMMARY_BY_USER` | Client error summaries by user |
+| `CLIENT_ERRORS_SUMMARY_GLOBAL` | `HIST_CLIENT_ERRORS_SUMMARY_GLOBAL` | Client error summaries by global |
+
+The snapshot sampling interval can be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval-new-in-v9.0.0):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set the interval to 15 minutes
+```
+
+## Manual snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using the following SQL statement:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
+## Time-based sampling process (every 5 seconds by default)
+
+The time-based sampling process, which runs every 1 to 600 seconds, samples data from various monitoring tables.
path: workloadrepo.md
user: login: wddevries
body: I have updated the text to be more clear about the type of the tables sampled.
created_at: 2025-04-04T03:54:50Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md#tidb_workload_repository_dest-new-in-v9.0.0) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot sampling process (hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
path: workloadrepo.md
user: login: wddevries
body: I have updated the text to be more clear about the tables sampled.
created_at: 2025-04-04T03:55:44Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md#tidb_workload_repository_dest-new-in-v9.0.0) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot sampling process (hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various monitoring tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
path: workloadrepo.md
user: login: songrijie
body: LGTM
created_at: 2025-04-09T11:06:30Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,113 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
path: workloadrepo.md
user: login: songrijie
body: OK
created_at: 2025-04-09T11:07:39Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,117 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md#tidb_workload_repository_dest-new-in-v900) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
path: workloadrepo.md
user: login: qiancai
body: ```suggestion
* The snapshot sampling process, which runs at configurable intervals, hourly by default, and can be triggered manually.
```
created_at: 2025-04-14T06:55:26Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,117 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md#tidb_workload_repository_dest-new-in-v900) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot sampling process (hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various cumulative metrics tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into `HIST_SNAPSHOTS`, capturing the snapshot ID, start and end timestamps, and server version details.
path: workloadrepo.md
user: login: qiancai
body: ```suggestion
1. From the initiating node, a row is inserted into `WORKLOAD_SCHEMA.HIST_SNAPSHOTS`, capturing the snapshot ID, start and end timestamps, and server version details.
```
created_at: 2025-04-14T06:56:48Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,117 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md#tidb_workload_repository_dest-new-in-v900) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot sampling process (hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various cumulative metrics tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into `HIST_SNAPSHOTS`, capturing the snapshot ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
path: workloadrepo.md
user: login: qiancai
body: ```suggestion
| Source table | Destination table | Description |
```
created_at: 2025-04-14T06:57:14Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,117 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md#tidb_workload_repository_dest-new-in-v900) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot sampling process (hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various cumulative metrics tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into `HIST_SNAPSHOTS`, capturing the snapshot ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
path: workloadrepo.md
user: login: qiancai
body: ```suggestion
2. On each TiDB node, all rows from the source tables are copied to the corresponding target tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
```
created_at: 2025-04-14T06:58:36Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,117 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md#tidb_workload_repository_dest-new-in-v900) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot sampling process (hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various cumulative metrics tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into `HIST_SNAPSHOTS`, capturing the snapshot ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| `TIDB_INDEX_USAGE` | `HIST_TIDB_INDEX_USAGE` | Index usage statistics |
+| `TIDB_STATEMENTS_STATS` | `HIST_TIDB_STATEMENTS_STATS` | Statement statistics |
+| `CLIENT_ERRORS_SUMMARY_BY_HOST` | `HIST_CLIENT_ERRORS_SUMMARY_BY_HOST` | Client error summaries by host |
+| `CLIENT_ERRORS_SUMMARY_BY_USER` | `HIST_CLIENT_ERRORS_SUMMARY_BY_USER` | Client error summaries by user |
+| `CLIENT_ERRORS_SUMMARY_GLOBAL` | `HIST_CLIENT_ERRORS_SUMMARY_GLOBAL` | Client error summaries by global |
path: workloadrepo.md
user: login: qiancai
body: ```suggestion
| [`TIDB_INDEX_USAGE`](/information-schema/information-schema-tidb-index-usage.md) | `HIST_TIDB_INDEX_USAGE` | Index usage statistics |
| [`TIDB_STATEMENTS_STATS`](/statement-summary-tables.md) | `HIST_TIDB_STATEMENTS_STATS` | Statement statistics |
| [`CLIENT_ERRORS_SUMMARY_BY_HOST`](/information-schema/client-errors-summary-by-host.md) | `HIST_CLIENT_ERRORS_SUMMARY_BY_HOST` | Client error summaries by host |
| [`CLIENT_ERRORS_SUMMARY_BY_USER`](/information-schema/client-errors-summary-by-user.md) | `HIST_CLIENT_ERRORS_SUMMARY_BY_USER` | Client error summaries by user |
| [`CLIENT_ERRORS_SUMMARY_GLOBAL`](/information-schema/client-errors-summary-global.md) | `HIST_CLIENT_ERRORS_SUMMARY_GLOBAL` | Client error summaries by global |
```
created_at: 2025-04-14T07:00:29Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,117 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md#tidb_workload_repository_dest-new-in-v900) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot sampling process (hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various cumulative metrics tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into `HIST_SNAPSHOTS`, capturing the snapshot ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| `TIDB_INDEX_USAGE` | `HIST_TIDB_INDEX_USAGE` | Index usage statistics |
+| `TIDB_STATEMENTS_STATS` | `HIST_TIDB_STATEMENTS_STATS` | Statement statistics |
+| `CLIENT_ERRORS_SUMMARY_BY_HOST` | `HIST_CLIENT_ERRORS_SUMMARY_BY_HOST` | Client error summaries by host |
+| `CLIENT_ERRORS_SUMMARY_BY_USER` | `HIST_CLIENT_ERRORS_SUMMARY_BY_USER` | Client error summaries by user |
+| `CLIENT_ERRORS_SUMMARY_GLOBAL` | `HIST_CLIENT_ERRORS_SUMMARY_GLOBAL` | Client error summaries by global |
+
+The snapshot sampling interval can be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval-new-in-v900):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set the interval to 15 minutes
+```
+
+## Manual snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using the following SQL statement:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
path: workloadrepo.md
user: login: qiancai
body: Do we need to add a document for this statement? 
![image](https://github.com/user-attachments/assets/f7a445ae-d9ff-407c-aee0-e2e168f2890e)

created_at: 2025-04-14T07:08:41Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,117 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md#tidb_workload_repository_dest-new-in-v900) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot sampling process (hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various cumulative metrics tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into `HIST_SNAPSHOTS`, capturing the snapshot ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| `TIDB_INDEX_USAGE` | `HIST_TIDB_INDEX_USAGE` | Index usage statistics |
+| `TIDB_STATEMENTS_STATS` | `HIST_TIDB_STATEMENTS_STATS` | Statement statistics |
+| `CLIENT_ERRORS_SUMMARY_BY_HOST` | `HIST_CLIENT_ERRORS_SUMMARY_BY_HOST` | Client error summaries by host |
+| `CLIENT_ERRORS_SUMMARY_BY_USER` | `HIST_CLIENT_ERRORS_SUMMARY_BY_USER` | Client error summaries by user |
+| `CLIENT_ERRORS_SUMMARY_GLOBAL` | `HIST_CLIENT_ERRORS_SUMMARY_GLOBAL` | Client error summaries by global |
+
+The snapshot sampling interval can be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval-new-in-v900):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set the interval to 15 minutes
+```
+
+## Manual snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using the following SQL statement:
+
path: workloadrepo.md
user: login: qiancai
body: Are there any permission requirements to run this statement?
created_at: 2025-04-14T07:09:36Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,117 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md#tidb_workload_repository_dest-new-in-v900) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot sampling process (hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various cumulative metrics tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into `HIST_SNAPSHOTS`, capturing the snapshot ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| `TIDB_INDEX_USAGE` | `HIST_TIDB_INDEX_USAGE` | Index usage statistics |
+| `TIDB_STATEMENTS_STATS` | `HIST_TIDB_STATEMENTS_STATS` | Statement statistics |
+| `CLIENT_ERRORS_SUMMARY_BY_HOST` | `HIST_CLIENT_ERRORS_SUMMARY_BY_HOST` | Client error summaries by host |
+| `CLIENT_ERRORS_SUMMARY_BY_USER` | `HIST_CLIENT_ERRORS_SUMMARY_BY_USER` | Client error summaries by user |
+| `CLIENT_ERRORS_SUMMARY_GLOBAL` | `HIST_CLIENT_ERRORS_SUMMARY_GLOBAL` | Client error summaries by global |
+
+The snapshot sampling interval can be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval-new-in-v900):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set the interval to 15 minutes
+```
+
+## Manual snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using the following SQL statement:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
+Manually triggering snapshots does not change the interval or timing of automatic snapshots.
+
+## Time-based sampling process (every 5 seconds by default)
+
+The time-based sampling process samples data from various non-cumulative metrics tables at intervals ranging from 1 to 600 seconds.
+
+When the time-base sampling process runs, all rows from the source tables are copied to the corresponding history tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp and instance ID.
path: workloadrepo.md
user: login: qiancai
body: ```suggestion
When the time-base sampling process runs, all rows from the source tables are copied to the corresponding target tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp and instance ID.
```
created_at: 2025-04-14T07:10:13Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,117 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md#tidb_workload_repository_dest-new-in-v900) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot sampling process (hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various cumulative metrics tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into `HIST_SNAPSHOTS`, capturing the snapshot ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| `TIDB_INDEX_USAGE` | `HIST_TIDB_INDEX_USAGE` | Index usage statistics |
+| `TIDB_STATEMENTS_STATS` | `HIST_TIDB_STATEMENTS_STATS` | Statement statistics |
+| `CLIENT_ERRORS_SUMMARY_BY_HOST` | `HIST_CLIENT_ERRORS_SUMMARY_BY_HOST` | Client error summaries by host |
+| `CLIENT_ERRORS_SUMMARY_BY_USER` | `HIST_CLIENT_ERRORS_SUMMARY_BY_USER` | Client error summaries by user |
+| `CLIENT_ERRORS_SUMMARY_GLOBAL` | `HIST_CLIENT_ERRORS_SUMMARY_GLOBAL` | Client error summaries by global |
+
+The snapshot sampling interval can be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval-new-in-v900):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set the interval to 15 minutes
+```
+
+## Manual snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using the following SQL statement:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
+Manually triggering snapshots does not change the interval or timing of automatic snapshots.
+
+## Time-based sampling process (every 5 seconds by default)
+
+The time-based sampling process samples data from various non-cumulative metrics tables at intervals ranging from 1 to 600 seconds.
+
+When the time-base sampling process runs, all rows from the source tables are copied to the corresponding history tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp and instance ID.
+
+Unlike the snapshot sampling process, a row will not be added to the `HIST_SNAPSHOTS` table.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
path: workloadrepo.md
user: login: qiancai
body: ```suggestion
| Source table | Destination table | Description |
```
created_at: 2025-04-14T07:10:40Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,117 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md#tidb_workload_repository_dest-new-in-v900) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot sampling process (hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various cumulative metrics tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into `HIST_SNAPSHOTS`, capturing the snapshot ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| `TIDB_INDEX_USAGE` | `HIST_TIDB_INDEX_USAGE` | Index usage statistics |
+| `TIDB_STATEMENTS_STATS` | `HIST_TIDB_STATEMENTS_STATS` | Statement statistics |
+| `CLIENT_ERRORS_SUMMARY_BY_HOST` | `HIST_CLIENT_ERRORS_SUMMARY_BY_HOST` | Client error summaries by host |
+| `CLIENT_ERRORS_SUMMARY_BY_USER` | `HIST_CLIENT_ERRORS_SUMMARY_BY_USER` | Client error summaries by user |
+| `CLIENT_ERRORS_SUMMARY_GLOBAL` | `HIST_CLIENT_ERRORS_SUMMARY_GLOBAL` | Client error summaries by global |
+
+The snapshot sampling interval can be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval-new-in-v900):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set the interval to 15 minutes
+```
+
+## Manual snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using the following SQL statement:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
+Manually triggering snapshots does not change the interval or timing of automatic snapshots.
+
+## Time-based sampling process (every 5 seconds by default)
+
+The time-based sampling process samples data from various non-cumulative metrics tables at intervals ranging from 1 to 600 seconds.
+
+When the time-base sampling process runs, all rows from the source tables are copied to the corresponding history tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp and instance ID.
+
+Unlike the snapshot sampling process, a row will not be added to the `HIST_SNAPSHOTS` table.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| `PROCESSLIST` | `HIST_PROCESSLIST` | Active sessions |
+| `DATA_LOCK_WAITS` | `HIST_DATA_LOCK_WAITS` | Data lock waits |
+| `TIDB_TRX` | `HIST_TIDB_TRX` | Active transactions |
+| `MEMORY_USAGE` | `HIST_MEMORY_USAGE` | Memory usage |
+| `DEADLOCKS` | `HIST_DEADLOCKS` | Deadlock information |
path: workloadrepo.md
user: login: qiancai
body: ```suggestion
| [`PROCESSLIST`](/information-schema/information-schema-processlist.md) | `HIST_PROCESSLIST` | Active sessions |
| [`DATA_LOCK_WAITS`](/information-schema/information-schema-data-lock-waits.md) | `HIST_DATA_LOCK_WAITS` | Data lock waits |
| [`TIDB_TRX`](/information-schema/information-schema-tidb-trx.md) | `HIST_TIDB_TRX` | Active transactions |
| [`MEMORY_USAGE`](/information-schema/information-schema-memory-usage.md) | `HIST_MEMORY_USAGE` | Memory usage |
| [`DEADLOCKS`](/information-schema/information-schema-deadlocks.md) | `HIST_DEADLOCKS` | Deadlock information |
```
created_at: 2025-04-14T07:53:44Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,117 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md#tidb_workload_repository_dest-new-in-v900) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot sampling process (hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various cumulative metrics tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into `HIST_SNAPSHOTS`, capturing the snapshot ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| `TIDB_INDEX_USAGE` | `HIST_TIDB_INDEX_USAGE` | Index usage statistics |
+| `TIDB_STATEMENTS_STATS` | `HIST_TIDB_STATEMENTS_STATS` | Statement statistics |
+| `CLIENT_ERRORS_SUMMARY_BY_HOST` | `HIST_CLIENT_ERRORS_SUMMARY_BY_HOST` | Client error summaries by host |
+| `CLIENT_ERRORS_SUMMARY_BY_USER` | `HIST_CLIENT_ERRORS_SUMMARY_BY_USER` | Client error summaries by user |
+| `CLIENT_ERRORS_SUMMARY_GLOBAL` | `HIST_CLIENT_ERRORS_SUMMARY_GLOBAL` | Client error summaries by global |
+
+The snapshot sampling interval can be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval-new-in-v900):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set the interval to 15 minutes
+```
+
+## Manual snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using the following SQL statement:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
+Manually triggering snapshots does not change the interval or timing of automatic snapshots.
+
+## Time-based sampling process (every 5 seconds by default)
+
+The time-based sampling process samples data from various non-cumulative metrics tables at intervals ranging from 1 to 600 seconds.
+
+When the time-base sampling process runs, all rows from the source tables are copied to the corresponding history tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp and instance ID.
+
+Unlike the snapshot sampling process, a row will not be added to the `HIST_SNAPSHOTS` table.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| `PROCESSLIST` | `HIST_PROCESSLIST` | Active sessions |
+| `DATA_LOCK_WAITS` | `HIST_DATA_LOCK_WAITS` | Data lock waits |
+| `TIDB_TRX` | `HIST_TIDB_TRX` | Active transactions |
+| `MEMORY_USAGE` | `HIST_MEMORY_USAGE` | Memory usage |
+| `DEADLOCKS` | `HIST_DEADLOCKS` | Deadlock information |
+
+The time-based sampling interval can be controlled with [`tidb_workload_repository_active_sampling_interval`](/system-variables.md#tidb_workload_repository_active_sampling_interval-new-in-v900):
+
+```sql
+SET GLOBAL tidb_workload_repository_active_sampling_interval = 20; -- set the interval to 20 seconds
+```
+
+Setting this global variable to `0` disables the time-based sampling process.
+
+## Data retention
+
+The system automatically purges data based on the retention period setting, using partitions for efficient data management.
path: workloadrepo.md
user: login: qiancai
body: ```suggestion
Historical data in the Workload Repository is retained for seven days by default. The system automatically purges data based on the retention period setting, using partitions for efficient data management.
```
created_at: 2025-04-14T07:56:04Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,117 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md#tidb_workload_repository_dest-new-in-v900) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot sampling process (hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various cumulative metrics tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into `HIST_SNAPSHOTS`, capturing the snapshot ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| `TIDB_INDEX_USAGE` | `HIST_TIDB_INDEX_USAGE` | Index usage statistics |
+| `TIDB_STATEMENTS_STATS` | `HIST_TIDB_STATEMENTS_STATS` | Statement statistics |
+| `CLIENT_ERRORS_SUMMARY_BY_HOST` | `HIST_CLIENT_ERRORS_SUMMARY_BY_HOST` | Client error summaries by host |
+| `CLIENT_ERRORS_SUMMARY_BY_USER` | `HIST_CLIENT_ERRORS_SUMMARY_BY_USER` | Client error summaries by user |
+| `CLIENT_ERRORS_SUMMARY_GLOBAL` | `HIST_CLIENT_ERRORS_SUMMARY_GLOBAL` | Client error summaries by global |
+
+The snapshot sampling interval can be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval-new-in-v900):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set the interval to 15 minutes
+```
+
+## Manual snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using the following SQL statement:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
+Manually triggering snapshots does not change the interval or timing of automatic snapshots.
+
+## Time-based sampling process (every 5 seconds by default)
+
+The time-based sampling process samples data from various non-cumulative metrics tables at intervals ranging from 1 to 600 seconds.
+
+When the time-base sampling process runs, all rows from the source tables are copied to the corresponding history tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp and instance ID.
+
+Unlike the snapshot sampling process, a row will not be added to the `HIST_SNAPSHOTS` table.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| `PROCESSLIST` | `HIST_PROCESSLIST` | Active sessions |
+| `DATA_LOCK_WAITS` | `HIST_DATA_LOCK_WAITS` | Data lock waits |
+| `TIDB_TRX` | `HIST_TIDB_TRX` | Active transactions |
+| `MEMORY_USAGE` | `HIST_MEMORY_USAGE` | Memory usage |
+| `DEADLOCKS` | `HIST_DEADLOCKS` | Deadlock information |
+
+The time-based sampling interval can be controlled with [`tidb_workload_repository_active_sampling_interval`](/system-variables.md#tidb_workload_repository_active_sampling_interval-new-in-v900):
+
+```sql
+SET GLOBAL tidb_workload_repository_active_sampling_interval = 20; -- set the interval to 20 seconds
+```
+
+Setting this global variable to `0` disables the time-based sampling process.
+
+## Data retention
+
+The system automatically purges data based on the retention period setting, using partitions for efficient data management.
+
+The [`tidb_workload_repository_retention_days`](/system-variables.md#tidb_workload_repository_retention_days-new-in-v900) variable controls the retention period for historical data in the Workload Repository. For example, to keep data for 30 days, run the following:
path: workloadrepo.md
user: login: qiancai
body: ```suggestion
You can use the [`tidb_workload_repository_retention_days`](/system-variables.md#tidb_workload_repository_retention_days-new-in-v900) variable to control the retention period for historical data in the Workload Repository. For example, to keep data for 30 days, run the following:
```
created_at: 2025-04-14T07:56:38Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,117 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md#tidb_workload_repository_dest-new-in-v900) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot sampling process (hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various cumulative metrics tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into `HIST_SNAPSHOTS`, capturing the snapshot ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| `TIDB_INDEX_USAGE` | `HIST_TIDB_INDEX_USAGE` | Index usage statistics |
+| `TIDB_STATEMENTS_STATS` | `HIST_TIDB_STATEMENTS_STATS` | Statement statistics |
+| `CLIENT_ERRORS_SUMMARY_BY_HOST` | `HIST_CLIENT_ERRORS_SUMMARY_BY_HOST` | Client error summaries by host |
+| `CLIENT_ERRORS_SUMMARY_BY_USER` | `HIST_CLIENT_ERRORS_SUMMARY_BY_USER` | Client error summaries by user |
+| `CLIENT_ERRORS_SUMMARY_GLOBAL` | `HIST_CLIENT_ERRORS_SUMMARY_GLOBAL` | Client error summaries by global |
+
+The snapshot sampling interval can be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval-new-in-v900):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set the interval to 15 minutes
+```
+
+## Manual snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using the following SQL statement:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
+Manually triggering snapshots does not change the interval or timing of automatic snapshots.
+
+## Time-based sampling process (every 5 seconds by default)
+
+The time-based sampling process samples data from various non-cumulative metrics tables at intervals ranging from 1 to 600 seconds.
+
+When the time-base sampling process runs, all rows from the source tables are copied to the corresponding history tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp and instance ID.
+
+Unlike the snapshot sampling process, a row will not be added to the `HIST_SNAPSHOTS` table.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| `PROCESSLIST` | `HIST_PROCESSLIST` | Active sessions |
+| `DATA_LOCK_WAITS` | `HIST_DATA_LOCK_WAITS` | Data lock waits |
+| `TIDB_TRX` | `HIST_TIDB_TRX` | Active transactions |
+| `MEMORY_USAGE` | `HIST_MEMORY_USAGE` | Memory usage |
+| `DEADLOCKS` | `HIST_DEADLOCKS` | Deadlock information |
+
+The time-based sampling interval can be controlled with [`tidb_workload_repository_active_sampling_interval`](/system-variables.md#tidb_workload_repository_active_sampling_interval-new-in-v900):
+
+```sql
+SET GLOBAL tidb_workload_repository_active_sampling_interval = 20; -- set the interval to 20 seconds
+```
+
+Setting this global variable to `0` disables the time-based sampling process.
+
+## Data retention
+
+The system automatically purges data based on the retention period setting, using partitions for efficient data management.
+
+The [`tidb_workload_repository_retention_days`](/system-variables.md#tidb_workload_repository_retention_days-new-in-v900) variable controls the retention period for historical data in the Workload Repository. For example, to keep data for 30 days, run the following:
+
+```sql
+SET GLOBAL tidb_workload_repository_retention_days = 30;
+```
+
+A higher value for this variable allows for longer data retention, which might be beneficial for workload analysis, but will increase storage requirements.
+
+## Notes
+
+- Enabling the Workload Repository might have a small performance impact on the system.
+- Setting sampling intervals too low might increase system overhead.
path: workloadrepo.md
user: login: qiancai
body: ```suggestion
- Setting sampling intervals too short might increase system overhead.
```
created_at: 2025-04-14T07:57:45Z
author_association: COLLABORATOR
diff_hunk: @@ -6207,6 +6207,51 @@ For details, see [Identify Slow Queries](/identify-slow-queries.md).
 - This variable is used to set the concurrency degree of the window operator.
 - A value of `-1` means that the value of `tidb_executor_concurrency` will be used instead.
 
+### tidb_workload_repository_dest <span class="version-mark">New in v9.0.0</span>
+
+- Scope: GLOBAL
+- Persists to cluster: Yes
+- Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No
+- Type: String
+- Default value: `''`
+- This variable is used to set the destination of the [Workload Repository](/workloadrepo.md).
+- The value can be either `'table'` (enabling the workload repository) or `''` (disabling the workload repository).
+
+### tidb_workload_repository_active_sampling_interval <span class="version-mark">New in v9.0.0</span>
+
+- Scope: GLOBAL
+- Persists to cluster: Yes
+- Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No
+- Type: Integer
+- Default value: `5`
+- Range: `[0, 600]`
+- Unit: Seconds
+- Sets the sampling interval for the [Workload Repository](/workloadrepo.md)'s Time-based Sampling Process.
path: system-variables.md
user: login: qiancai
body: ```suggestion
- Sets the sampling interval for the [Workload Repository](/workloadrepo.md)'s time-based sampling process.
```
created_at: 2025-04-14T08:04:15Z
author_association: COLLABORATOR
diff_hunk: @@ -6207,6 +6207,51 @@ For details, see [Identify Slow Queries](/identify-slow-queries.md).
 - This variable is used to set the concurrency degree of the window operator.
 - A value of `-1` means that the value of `tidb_executor_concurrency` will be used instead.
 
+### tidb_workload_repository_dest <span class="version-mark">New in v9.0.0</span>
+
+- Scope: GLOBAL
+- Persists to cluster: Yes
+- Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No
+- Type: String
+- Default value: `''`
+- This variable is used to set the destination of the [Workload Repository](/workloadrepo.md).
+- The value can be either `'table'` (enabling the workload repository) or `''` (disabling the workload repository).
+
+### tidb_workload_repository_active_sampling_interval <span class="version-mark">New in v9.0.0</span>
+
+- Scope: GLOBAL
+- Persists to cluster: Yes
+- Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No
+- Type: Integer
+- Default value: `5`
+- Range: `[0, 600]`
+- Unit: Seconds
+- Sets the sampling interval for the [Workload Repository](/workloadrepo.md)'s Time-based Sampling Process.
+- Setting the value to `0` disables the Time-based Sampling Process.
path: system-variables.md
user: login: qiancai
body: ```suggestion
- Setting the value to `0` disables the time-based sampling process.
```
created_at: 2025-04-14T08:04:36Z
author_association: COLLABORATOR
diff_hunk: @@ -6207,6 +6207,51 @@ For details, see [Identify Slow Queries](/identify-slow-queries.md).
 - This variable is used to set the concurrency degree of the window operator.
 - A value of `-1` means that the value of `tidb_executor_concurrency` will be used instead.
 
+### tidb_workload_repository_dest <span class="version-mark">New in v9.0.0</span>
+
+- Scope: GLOBAL
+- Persists to cluster: Yes
+- Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No
+- Type: String
+- Default value: `''`
+- This variable is used to set the destination of the [Workload Repository](/workloadrepo.md).
+- The value can be either `'table'` (enabling the workload repository) or `''` (disabling the workload repository).
+
+### tidb_workload_repository_active_sampling_interval <span class="version-mark">New in v9.0.0</span>
+
+- Scope: GLOBAL
+- Persists to cluster: Yes
+- Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No
+- Type: Integer
+- Default value: `5`
+- Range: `[0, 600]`
+- Unit: Seconds
+- Sets the sampling interval for the [Workload Repository](/workloadrepo.md)'s Time-based Sampling Process.
+- Setting the value to `0` disables the Time-based Sampling Process.
+
+### tidb_workload_repository_retention_days <span class="version-mark">New in v9.0.0</span>
+
+- Scope: GLOBAL
+- Persists to cluster: Yes
+- Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No
+- Type: Integer
+- Default value: `7`
+- Range: `[0, 365]`
+- Unit: Days
+- Sets the number of days that [Workload Repository](/workloadrepo.md) data is retained.
+- Setting the value to `0` disables automatic purging of old data.
+
+### tidb_workload_repository_snapshot_interval <span class="version-mark">New in v9.0.0</span>
+
+- Scope: GLOBAL
+- Persists to cluster: Yes
+- Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No
+- Type: Integer
+- Default value: `3600`
+- Range: `[900, 7200]`
+- Unit: Seconds
+- Sets the sampling interval for the [Workload Repository](/workloadrepo.md)'s Snapshot Sampling Process.
path: system-variables.md
user: login: qiancai
body: ```suggestion
- Sets the sampling interval for the [Workload Repository](/workloadrepo.md)'s snapshot sampling process.
```
created_at: 2025-04-14T08:05:03Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,117 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
path: workloadrepo.md
user: login: qiancai
body: ```suggestion
## Enable the Workload Repository
```
created_at: 2025-04-14T08:19:16Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,117 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
path: workloadrepo.md
user: login: qiancai
body: For a task-based heading, start with a [bare infinitive](https://wikipedia.org/wiki/Infinitive#English), also known as a plain form or [base form](https://wikipedia.org/wiki/English_verbs#Base_form) verb.
ref: https://developers.google.cn/style/headings
created_at: 2025-04-14T08:21:07Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,117 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md#tidb_workload_repository_dest-new-in-v900) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
path: workloadrepo.md
user: login: qiancai
body: ```suggestion
* The time-based sampling process, which runs at shorter intervals, typically every 5 seconds.
```
created_at: 2025-04-14T08:23:31Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,117 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md#tidb_workload_repository_dest-new-in-v900) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot sampling process (hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various cumulative metrics tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
path: workloadrepo.md
user: login: qiancai
body: ```suggestion
The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various cumulative metrics tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and the process is as follows:
```
created_at: 2025-04-14T08:24:37Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,117 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enabling the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md#tidb_workload_repository_dest-new-in-v900) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The Snapshot process, which runs at configurable intervals, typically hourly, and can be triggered manually.
+* The Time-based process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot sampling process (hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various cumulative metrics tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and process is as follows:
+
+ 1. From the initiating node a row is inserted into `HIST_SNAPSHOTS`, capturing the snapshot ID, start and end timestamps, and server version details.
+ 2. On each TiDB node, all rows from the source tables are copied to the corresponding history tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Table Name | Destination Table | Description |
+| --- | --- | --- |
+| `TIDB_INDEX_USAGE` | `HIST_TIDB_INDEX_USAGE` | Index usage statistics |
+| `TIDB_STATEMENTS_STATS` | `HIST_TIDB_STATEMENTS_STATS` | Statement statistics |
+| `CLIENT_ERRORS_SUMMARY_BY_HOST` | `HIST_CLIENT_ERRORS_SUMMARY_BY_HOST` | Client error summaries by host |
+| `CLIENT_ERRORS_SUMMARY_BY_USER` | `HIST_CLIENT_ERRORS_SUMMARY_BY_USER` | Client error summaries by user |
+| `CLIENT_ERRORS_SUMMARY_GLOBAL` | `HIST_CLIENT_ERRORS_SUMMARY_GLOBAL` | Client error summaries by global |
+
+The snapshot sampling interval can be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval-new-in-v900):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set the interval to 15 minutes
+```
+
+## Manual snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using the following SQL statement:
+
+```sql
+ADMIN WORKLOAD REPOSITORY TAKE SNAPSHOT;
+```
+
path: workloadrepo.md
user: login: wddevries
body: I added a section to this page for the new command.
created_at: 2025-04-16T06:33:08Z
author_association: CONTRIBUTOR
diff_hunk: @@ -149,6 +150,16 @@ For details, refer to [`ADMIN SHOW SLOW` command](/identify-slow-queries.md#admi
 
 </CustomContent>
 
+## `ADMIN CREATE WORKLOAD SNAPSHOT` statement
+
+The following SQL statement will trigger a manual snapshot in the [Workload Repository](/workloadrepo.md):
+
+```sql
+ADMIN CREATE WORKLOAD SNAPSHOT;
+```
+
+Please note that the Workload Repository must be enabled for this statement to have effect.  Otherwise, it will generate an error.
path: sql-statements/sql-statement-admin.md
user: login: hfxsd
body: ```suggestion
Note that the Workload Repository must be enabled for this statement to take effect. Otherwise, it will generate an error.
```
created_at: 2025-04-17T01:57:04Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,117 @@
+---
+title: TiDB Workload Repository
+summary: Introduces the workload repository system for collecting and storing historical workload data from a TiDB cluster.
+---
+
+# TiDB Workload Repository
+
+The workload repository is a system for collecting and storing historical workload data from a TiDB cluster. It periodically samples various system tables to track cluster performance and usage patterns over time.
+
+## Enable the Workload Repository
+
+To enable the Workload Repository, set the [`tidb_workload_repository_dest`](/system-variables.md#tidb_workload_repository_dest-new-in-v900) system variable:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = 'table';
+```
+
+To disable it:
+
+```sql
+SET GLOBAL tidb_workload_repository_dest = '';
+```
+
+## Data collection
+
+The Workload Repository stores data in tables under the `WORKLOAD_SCHEMA` database. It collects data via two different methods:
+
+* The snapshot sampling process, which runs at configurable intervals, hourly by default, and can be triggered manually.
+* The time-based sampling process, which runs at shorter intervals, typically every 5 seconds.
+
+## Snapshot sampling process (hourly by default)
+
+The snapshot sampling process, which runs every 15 minutes to 2 hours, samples data from various cumulative metrics tables. Snapshots are initiated from one of the TiDB nodes at the specified intervals, and the process is as follows:
+
+1. From the initiating node, a row is inserted into `WORKLOAD_SCHEMA.HIST_SNAPSHOTS`, capturing the snapshot ID, start and end timestamps, and server version details.
+2. On each TiDB node, all rows from the source tables are copied to the corresponding target tables with the `HIST_` prefix. The copied data includes the original columns from the source tables plus additional columns for the timestamp, instance ID, and snapshot ID.
+
+Note that the sampled tables return data specific to the TiDB node from which they are queried.
+
+Data is sampled from the following tables:
+
+| Source table | Destination table | Description |
+| --- | --- | --- |
+| [`TIDB_INDEX_USAGE`](/information-schema/information-schema-tidb-index-usage.md) | `HIST_TIDB_INDEX_USAGE` | Index usage statistics |
+| [`TIDB_STATEMENTS_STATS`](/statement-summary-tables.md) | `HIST_TIDB_STATEMENTS_STATS` | Statement statistics |
+| [`CLIENT_ERRORS_SUMMARY_BY_HOST`](/information-schema/client-errors-summary-by-host.md) | `HIST_CLIENT_ERRORS_SUMMARY_BY_HOST` | Client error summaries by host |
+| [`CLIENT_ERRORS_SUMMARY_BY_USER`](/information-schema/client-errors-summary-by-user.md) | `HIST_CLIENT_ERRORS_SUMMARY_BY_USER` | Client error summaries by user |
+| [`CLIENT_ERRORS_SUMMARY_GLOBAL`](/information-schema/client-errors-summary-global.md) | `HIST_CLIENT_ERRORS_SUMMARY_GLOBAL` | Client error summaries by global |
+
+The snapshot sampling interval can be controlled with [`tidb_workload_repository_snapshot_interval`](/system-variables.md#tidb_workload_repository_snapshot_interval-new-in-v900):
+
+```sql
+SET GLOBAL tidb_workload_repository_snapshot_interval = 900; -- set the interval to 15 minutes
+```
+
+## Manual snapshots
+
+Note that while the snapshot sampling process runs automatically based on the configured interval, you can also trigger a manual snapshot using the following SQL statement:
+
+```sql
+ADMIN CREATE WORKLOAD SNAPSHOT
path: workloadrepo.md
user: login: hfxsd
body: ```suggestion
ADMIN CREATE WORKLOAD SNAPSHOT;
```
created_at: 2025-04-17T01:57:39Z
author_association: COLLABORATOR

PR comments:
user: login: ti-chi-bot[bot]
created_at: 2025-03-27T01:34:22Z
body: @hfxsd: Your lgtm message is repeated, so it is ignored.

<details>

In response to [this](https://github.com/pingcap/docs/pull/20490#pullrequestreview-2719096315):

>


Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md).  If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.
</details>
author_association: NONE
user: login: songrijie
created_at: 2025-04-01T00:53:17Z
body: We'd better mention `tidb_statements_stats` that is derived from `statements_summary` in https://docs.pingcap.com/tidb/stable/statement-summary-tables/
author_association: CONTRIBUTOR
user: login: ti-chi-bot[bot]
created_at: 2025-04-09T11:08:06Z
body: @songrijie: adding LGTM is restricted to approvers and reviewers in OWNERS files.

<details>

In response to [this](https://github.com/pingcap/docs/pull/20490#pullrequestreview-2753093691):

>


Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md).  If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.
</details>
author_association: NONE
user: login: ti-chi-bot[bot]
created_at: 2025-04-14T08:30:13Z
body: [LGTM Timeline notifier]
---
Timeline:

- `2025-03-27 01:34:20.338670757 +0000 UTC m=+1096954.022906838`: :ballot_box_with_check: agreed by [hfxsd](https://github.com/hfxsd).
- `2025-04-14 08:30:12.619978644 +0000 UTC m=+2677106.304214741`: :ballot_box_with_check: agreed by [qiancai](https://github.com/qiancai).
author_association: NONE
user: login: hfxsd
created_at: 2025-04-17T03:09:21Z
body: /approve
author_association: COLLABORATOR
user: login: hfxsd
created_at: 2025-04-17T03:24:26Z
body: /approve
author_association: COLLABORATOR
user: login: ti-chi-bot[bot]
created_at: 2025-04-17T03:24:33Z
body: [APPROVALNOTIFIER] This PR is **APPROVED**

This pull-request has been approved by: *<a href="https://github.com/pingcap/docs/pull/20490#issuecomment-2811633655" title="Approved">hfxsd</a>*

The full list of commands accepted by this bot can be found [here](https://prow.tidb.net/command-help?repo=pingcap%2Fdocs).

The pull request process is described [here](https://book.prow.tidb.net/#/workflows/pr)

<details >
Needs approval from an approver in each of these files:

- ~~[OWNERS](https://github.com/pingcap/docs/blob/master/OWNERS)~~ [hfxsd]

Approvers can indicate their approval by writing `/approve` in a comment
Approvers can cancel approval by writing `/approve cancel` in a comment
</details>
<!-- META={"approvers":[]} -->
author_association: NONE