drop、truncate时是直接删除表了还是标记成旧版本了？

drop、truncate时是直接删除表了还是和delete类似 标记成旧版本了？

旧版本，只要还没被GC,可以找回误删除的表

都是标记删除，GC之前都是可以恢复

https://docs.pingcap.com/zh/tidb/stable/sql-statement-flashback-table#flashback-table 官方文档看下

truncate 是将表中的所有数据逐条标记删除吗？

truncate 标记删除是怎么标记的？ 逐条吗？

工作原理

TiDB 在删除表时，实际上只删除了表的元信息，并将需要删除的表数据（行数据和索引数据）写一条数据到 mysql.gc_delete_range 表。TiDB 后台的 GC Worker 会定期从 mysql.gc_delete_range 表中取出超过 GC lifetime 相关范围的 key 进行删除。

所以， FLASHBACK TABLE 只需要在 GC Worker 还没删除表数据前，恢复表的元信息并删除 mysql.gc_delete_range 表中相应的行记录即可。恢复表的元信息可以用 TiDB 的快照读实现。具体的快照读内容可以参考读取历史数据文档。下面是 FLASHBACK TABLE t TO t1 的工作流程：

1. 从 DDL History job 中查找 drop table 或者 truncate table 类型的操作，且操作的表名是 t 的第一个 DDL job，若没找到，则返回错误。
2. 检查 DDL job 的开始时间，是否在 tikv_gc_safe_point 之前。如果是 tikv_gc_safe_point 之前，说明被 DROP 或 TRUNCATE 删除的表已经被 GC 清理掉，返回错误。
3. 用 DDL job 的开始时间作为 snapshot 读取历史数据，读取表的元信息。
4. 删除 mysql.gc_delete_range 中和表 t 相关的 GC 任务。
5. 将表的元信息中的 name 修改成 t1 ，并用该元信息新建一个表。注意：这里只是修改了表名，但是 table ID 不变，依旧是之前被删除的表 t 的 table ID。

可以发现，从表 t 被删除，到表 t 被 FLASHBACK 恢复到 t1 ，一直都是对表的元信息进行操作，而表的用户数据一直未被修改过。被恢复的表 t1 和之前被删除的表 t 的 table ID 相同，所以表 t1 才能读取表 t 的用户数据。

不是的，truncate是drop+create

TiDB 在删除表时，实际上只删除了表的元信息，并将需要删除的表数据（行数据和索引数据）写一条数据到 mysql.gc_delete_range 表。TiDB 后台的 GC Worker 会定期从 mysql.gc_delete_range 表中取出超过 GC lifetime 相关范围的 key 进行删除。

发现你对官档好熟悉呀

感谢各位大佬 答疑解惑

参考数据删除规范
5.1 删除表中全部的数据时，使用 TRUNCATE 而不要使用delete。
5.2 如果大批删除，容易引发整个集群性能抖动。建议拆分SQL（少删多提）

该主题在最后一个回复创建后60天后自动关闭。不再允许新的回复。