diff --git a/best-practices/index-management-best-practices.md b/best-practices/index-management-best-practices.md index 48528336537b6..3b1309235e873 100644 --- a/best-practices/index-management-best-practices.md +++ b/best-practices/index-management-best-practices.md @@ -167,7 +167,7 @@ By using `CLUSTER_TIDB_INDEX_USAGE`, you can gain a global perspective on index ## Identify unused indexes using `schema_unused_indexes` -Manually analyzing index usage data can be time-consuming. To simplify this process, TiDB provides [`schema_unused_indexes`](/sys-schema/sys-schema-unused-indexes.md), a system view that lists indexes that have not been used since the database is last restarted. +Manually analyzing index usage data can be time-consuming. To simplify this process, TiDB provides [`schema_unused_indexes`](/sys-schema/sys-schema-unused-indexes.md), a system view that lists an index when none of the TiDB instances currently has an access record for that index. Index usage is tracked separately on each TiDB instance and is reset when that instance restarts. This provides a quick way for you to do the following: @@ -179,7 +179,7 @@ By using `schema_unused_indexes`, you can quickly identify unnecessary indexes a ### How `schema_unused_indexes` works -The `schema_unused_indexes` view is derived from `TIDB_INDEX_USAGE`, meaning it automatically filters out indexes that have recorded zero query activity since the last TiDB restart. +The `schema_unused_indexes` view is derived from `CLUSTER_TIDB_INDEX_USAGE`. It returns an index only if no TiDB instance has recorded an access to it since its own most recent restart. To retrieve a list of unused indexes, run the following SQL statement: @@ -202,7 +202,7 @@ A result similar to the following is returned: Take the following points into consideration when you use `schema_unused_indexes`. -#### Indexes are considered unused only since the last restart +#### Index usage data is reset when a TiDB instance restarts - If a TiDB node restarts, the usage tracking data is reset. - Ensure the system has been running long enough to capture a representative workload before relying on this data.