【 TiDB 使用环境】测试
【 TiDB 版本】v7.5.2
【复现路径】对大表 DROP 了大列
【遇到的问题：问题现象及影响】TiKV 磁盘空间始终不下降
DROP 为同步 MySQL 上的操作，MySQL 上存储有肉眼可见得下降，大约为以前的 30 %
DROP COLUMN 后已经经过了 3 天，TiKV 磁盘空间没有下降， GC 似乎对这种情况不产生作用，监控上看 GC 都正常， GC SafePoint 也是当前时间。试着对个别 region 在 TiKV 上执行 tikv-ctl compact，前后用 tikv-ctl size 观察容量似乎也没有变化，但这个值是否会实时更新我也不确定。
想问如何操作可以让 TiKV 释放磁盘容量？
通过 TiDB 的 ADMIN SHOW GC STATUS 命令查看 GC 的状态和进度，确认 GC 是否在正常运行。
show global status;
Ssl_cipher
Ssl_cipher_list
Ssl_server_not_after
Ssl_server_not_before
Ssl_verify_mode 0
Ssl_version
Uptime 2428564
ddl_schema_version 3000
server_id 251d80aa-383c-4eee-9325-ba6ea85846ba
tidb_gc_last_run_time 20240826-16:12:06.258 +0800
tidb_gc_leader_desc host:bigdata-tidb-0, pid:1, start at 2024-07-29 13:39:06.254791482 +0800 CST m=+0.266542673
tidb_gc_leader_lease 20240826-16:17:06.264 +0800
tidb_gc_leader_uuid 643f3ff8584001b
tidb_gc_safe_point 20240826-16:02:06.258 +0800
GC 应该都是好的，我的场景是 DROP COLUMN，不是删表、删行、删 Index。
DROP COLUMN 应该是个元数据变更操作，但我希望它能真的重新组织数据。
空间的释放依赖于后续的GC过程和可能的Region Merge操作。没有搞过这种操作，确实不了解什么时候释放空间
是不是目前是不是只是标记了？？
什么叫标记了？ ALTER TABLE 已经做完了，表里删掉的字段已经看不到了。
./tikv-ctl --host localhost:20160 compact -c write -d kv --bottommost force 我尝试在节点上执行这个，现在还在跑，似乎硬盘在逐渐释放，我再观察一段时间
drop column 不是物理上的删除，TiDB 只是标记了删除的列不可见，因为要做物理删除的话需要重写数据，整个 DDL 的耗时会很长。
可以新建一个表，然后 insert into xxx select * from xxx，再把原表 drop 掉
删除列，触发不了正常的GC，必须得compact重新整合数据才行。
删列应该不会降低空间吧，因为tidb是online ddl，基本上就瞬间完成了，数据不会重整。至于gc、compact这些动作的关系是这样的：gc把过期的版本在rocksdb层执行delete(key), compact的动作是把 delete(key)和上一个版本的put(key,value) 合并后删掉。我理解删列对数据key不做任何动作，只是元数据做一些标记。
这个能手动触发吗
我在一台 TiKV 上做了 compact，稍微腾出来了一些空间，但感觉应该是没有真的把 drop 列空出来的资源释放，和 MySQL 里对比不成比例。
关注中。
只能重建表 才能释放了 你删的大字段？
是的，本来是为了节省 MySQL 里的空间，对字段做了压缩处理存进了新字段，老字段没用了要删掉，同步到 TiDB 来了。有什么办法方便的重建表吗？类似 MySQL Optimize table 之类的？
可以GC机制吗
看来gc肯定不行了
tidb 的 drop column 只是修改元信息。已有数据不会重构。所以空间不释放的。
mysql底层存储和tidb不一样的，tidb是key:value这样存的，你删列，应该相当于只是value里面有个字段被打标为失效，空间没法立刻释放，像重建表的话，dumpling+lightning快一点吧。
时刻关注中。