TRUNCATE TABLE, empty table, why does it take 4 seconds?

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

Original topic: TRUNCATE TABLE ,空表,为什么需要4S啊

| username: lemonade010

[TiDB Usage Environment] Production Environment / Testing / PoC
[TiDB Version]
[Reproduction Path] TRUNCATE TABLE, empty table, why does it take 4 seconds?
[Encountered Issues: Problem Phenomenon and Impact]
[Resource Configuration] Go to TiDB Dashboard - Cluster Info - Hosts and take a screenshot of this page
[Attachments: Screenshots/Logs/Monitoring]

| username: MrSylar | Original post link

There are many factors that affect the time, such as the execution principle, resource usage, and MDL locks. In your scenario, it is highly likely that there are too many regions: show table <table_name> regions;

| username: zhanggame1 | Original post link

The “truncate table” is a DDL statement, and its execution time is not related to the amount of data. Truncate actually involves creating a new table and deleting the old one. TiDB has MDL locks, and executing DDL statements also involves a queue that prevents concurrent operations on the table. The slowness might be normal, and it is necessary to check if there were other DDL operations or MDL locks at that time.

| username: lemonade010 | Original post link

There is only one region.

| username: MrSylar | Original post link

Is this seen after truncate? The number of regions after truncate is created according to the table definition. You need to check before truncate.

| username: zhaokede | Original post link

DDL execution is queued.

| username: lemonade010 | Original post link

There was no queuing situation. When it was just executed, I checked s

| username: lemonade010 | Original post link

No data

| username: DBAER | Original post link

How large is the table? Is it similar to a large table in MySQL, involving many regions and slow disk I/O?

| username: lemonade010 | Original post link

No data, empty table.

| username: 柴米油酱 | Original post link

Truncate is actually a drop/create operation, DDL needs to enter the queue, and the owner executes it in a single thread.

| username: TiDBer_q2eTrp5h | Original post link

After looking at it for a long time, it is indeed a very confusing issue.

| username: zhaokede | Original post link

How is the health of the table, and is the statistical information accurate?

| username: zhaokede | Original post link

What is the logic behind performing TRUNCATE TABLE on an empty table?

| username: forever | Original post link

Was it a large table before it became an empty table?

| username: TiDBer_HUfcQIJx | Original post link

It doesn’t show which step is slow.

| username: Soysauce520 | Original post link

How many tables are there in the database?

| username: DBAER | Original post link

Which specific version is it? Higher versions might be causing it due to metadata locks.

| username: TIDB-Learner | Original post link

For an empty table, the TRUNCATE TABLE operation,


can reproduce a lock wait situation.
If there are no other operations, it will be completed in 0.2 seconds.

| username: 小于同学 | Original post link

Are there enough resources?