【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】6.5.4
【复现路径】
【资源配置】
【疑问】看到一篇文章说到tidb开发规范，说不要进行物理删除。而是通过设置update t1 set is_del = 1+crontatb 的方式来实现删除。所以有些不懂的点。
1、到底什么是物理删除？我理解就是delete后，经过gc+compaction实现的删除就达到了物理删除。
2、表设计的时候增加is_del 能优化delete对业务的影响的原理是什么？这个结论到底对不对？我如果业务中确实存在很多delete业务场景，应该如何设计表？分区表是一个。不能分区的表呢，有没有其他经验分享！
这种规范没有参考价值。
你要考虑的是为什么要删除数据，删除了数据是否无影响，未来也没有使用价值。
逻辑删除， 就是表的字段打tag，标记这行是否已经删除
物理删除 就是delete 语句
这个看业务设计吧，简单点就是物理删除
直接删除文件的这种是物理删除吧
delete也算是物理删除，你说的这个删除是数据库销毁 
这个开发规范的意思，就是例如你有个用户表，用户注销只是把他is_del置为1，而不是直接delete掉他。。。这个跟什么数据库没关系，存粹是开发的规范。
从tidb 读取和写入的 scan 原理入手，有参考意义么？
我记得delete from t1 where xx;的原理是把 要删除的内容都load到tidb-server的内存里。 update在内存方面的原理还不知道。
所以从内存消耗方面考虑，是不是update is_del =1 比 delete 要轻量级?
但是在 mvvc scan keys方面，是不是也有理论支撑？
从测试来看delete比update应该快一些。
从tidb底层实现来看delete和update都是插入一条kv数据
资源消耗呢？
delete成本更高吧。 update 应该只是 k_new-version = new_value。操作的时候只是把列拿到内存去庚新把。
delete我之前看到一篇文章说是整个行拿到内存去。。。
update 你想想，update是不是也得取出来数据到内存，然后修改内容，再插新数据回去
根据业务需求正常删除即可
该物理删除还是物理删除，by实际业务需求来吧，这个规范是不是没有场景上下文的断章取义呀
tidb的底层是key-value，删除就是新增一条数据，原来的key+删除标记；update也是新增一条数据，原来的key+修改过的value（包含所有列值）；这时由于对应的key有了更新的value，原来的数据就变成了废弃的数据，在达到你的gc时间的时候，会被gc掉了。从内存消耗方面可能delete要稍微好一点，毕竟删除标记要小一点，而update的value反而要大一点，但是差异不大。在 mvvc scan keys方面其实是一样的，在gc掉无用数据之前，你都会扫描到之前那条无用数据然后过滤掉。
你看的规范有点不规范
你看的规范有点不规范
感谢大佬。
我好好理解下这段话，原理这块还得持续学习！
这里追问一下， （包含所有列值） ，我如果update一列，也会把其他不变的列，load到内存，生成新的kv，进行写入么？ 还是只update一列的数据到内存即可。
之前看过一篇帖子（专栏 - TiDB MVCC 版本堆积相关原理及排查手段 | TiDB 社区
说是把所有列都拿出来，根据新的值生成一行新的kv，然后写入到底层数据。所以update的成本单纯内存来说，还是比delete要高。由此也可以推断，用replace来优化delete，其实并不成立。因为replace其实也是update
tidb的value就是所有列合并，你可以想象成一个json，你修改其中一个字段，还是需要把整个value拿出来的，然后修改完其中一个值再存储回去。用replace并不能优化delete，他只是简单的delete+insert，用来优化应用代码的，其实消耗比update也不低，因为他是先增加一条key+删除标记，然后再新建一条key+value，update是拿出原来的key+value，然后修改value重新入进去。