Impact of truncate/drop table/database on the cluster

This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: truncate/drop table/database对集群影响

| username: TiDBer_yUoxD0vR

[TiDB Usage Environment] Production Environment / Testing / PoC
[TiDB Version]
[Reproduction Path] What operations were performed when the issue occurred
When truncating/dropping a table/database, what is the impact on the cluster during the background cleanup by the GC worker? For example, in MySQL, dropping a large table locks the InnoDB buffer pool, affecting the entire cluster. What is the impact of dropping a large table (7 million rows) in TiDB? Besides high I/O, what other impacts are there?
The official documentation describes it as follows:
When TiDB deletes a table, it actually only deletes the table’s metadata and writes a record to the mysql.gc_delete_range table for the data (row data and index data) that needs to be deleted. The GC Worker in the background of TiDB periodically retrieves keys from the mysql.gc_delete_range table that exceed the GC lifetime and deletes them.

[Encountered Issue: Symptoms and Impact]
[Resource Configuration]
[Attachments: Screenshots/Logs/Monitoring]

| username: tidb菜鸟一只 | Original post link

In theory, GC operations mainly affect I/O, simply deleting data from the disk that has exceeded the GC time.

| username: caiyfc | Original post link

The impact of GC data cleanup on the cluster is minimal. The GC worker has only one thread, so the deletion speed is limited. If a large amount of data is deleted at once, it may cause the GC worker to get blocked and unable to delete the data that should be deleted in time. For example, if data is deleted every 10 minutes and the GC is blocked, you may find that MVCC version data from an hour ago can still be queried. The impact of this situation is that the select operation will scan more historical data information. Overall, the impact on the cluster is still not significant. I tested this in a production environment, deleting 14TB of data simultaneously, and did not observe any performance issues in the monitoring.

| username: system | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.