Does the "truncate table" mark the table for deletion or mark the rows for deletion?

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

Original topic: truncate table是对表做删除标记还是对行做删除标记?

| username: 逍遥_猫

Does “truncate table” mark the table for deletion or mark the rows for deletion?
What about “drop table”?

| username: h5n1 | Original post link

Directly clean up SST and physically delete data after the drop/truncate to GC time.

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

The underlying layer of TiDB is all key-value. Truncating or dropping a table essentially marks all keys for deletion, and this is recorded in the mysql.gc_delete_range table. After the GC time is reached, the corresponding keys will be deleted. Therefore, within the GC time, truncating or dropping a table in TiDB can actually be recovered.

| username: Kongdom | Original post link

My understanding is that it marks the row for deletion :yum:

| username: 逍遥_猫 | Original post link

According to the documentation, it is a deletion mark made on the region.

| username: Kongdom | Original post link

:ok_hand::ok_hand::ok_hand:

| username: zhanggame1 | Original post link

What if multiple tables use the same region for regions?

| username: 逍遥_猫 | Original post link

According to this document, a delete marker is applied to the region.
What if multiple tables use the same region?

| username: h5n1 | Original post link

Look at this DDL flashback principle

| username: 像风一样的男子 | Original post link

Mark the key-value pairs with a delete tag, and multiple sets of key-value data form a region.

| username: 逍遥_猫 | Original post link

Thanks, boss :ghost: I have understood the principle of flashback table.

| username: heiwandou | Original post link

Region

| username: Fly-bird | Original post link

There is a GC mechanism.

| username: 逍遥_猫 | Original post link

To add, the table_id changes every time the truncate table operation is performed.

| username: zxgaa | Original post link

It should be marking the rows.

| username: 逍遥_猫 | Original post link

To be more precise, first delete the data of the entire range, then perform GC to delete the old versions of keys on each node.

| username: 随缘天空 | Original post link

The difference between “truncate table” and “delete table” is that “truncate table” is faster and uses fewer system and transaction log resources. This is because “truncate table” removes all rows from a table without logging the individual row deletions, whereas “delete table” logs each row deletion, which can be slower and more resource-intensive. Therefore, it is generally recommended to use “truncate table” to clear data.

| username: zhanggame1 | Original post link

Deleting a table in TiDB will be a write operation, causing the data volume to increase instead, and it is very slow. If the data volume is large, it will result in an OOM (Out of Memory) error.

| username: 随缘天空 | Original post link

Well, delete will log and occupy disk space, and after a period of time, GC will release the disk space. However, truncate does not log, which is relatively better.

| username: zhanggame1 | Original post link

Releasing is very difficult, and the GC of delete cannot free up the disk.