这不算高啊，tidb也是又缓存的，sql执行完了，不会立刻释放内存的。

机器上free -g看下内存使用情况呢

换俩笔记本吧

你的数据库设置的表名大小写敏感吗？

没复现这个问题。。。所有的view都不行吗？

需要compact才能真正释放空间，就算gc了，空间也没释放

直接发执行计划，explain analyze生成的

16G估计真的只能启动每个节点，然后稍微波动下就不够了，每个节点的应用起来都要占起码2G左右的内容的。。

mvcc模式，不会存在死锁或者幻读的情况

可以考虑下tidb cloud

你最喜欢的一款 TiDB 周边是什么？ 行李箱，没赶上啊。。。 你最近看到哪些创意的周边是让你感觉很 “哇塞” 的。有图片的话，可以尽可能附图哟~ 武侠类的手办

你截图的日志并不是报错级别的啊，不至于导致起不来

让你把这个关了，开着就是所有走强制走tiflash

您当前使用的云资源部署在哪个地域（城市），会考虑单一城市部署还是多城市容灾？在哪朵云上？ 都是私有云 目前运行着多少套 TiDB 集群，合计节点数 / 核心数（core）为多少？您当前 TiDB 相关资源的年度总费用是多少？ 云提供的具体折扣力度（如折扣率 / 优惠方式）是什么？ 3套吧，合计节点30+，核心数200+，费用没关注过 若迁移至 TiDB 全托管服务，您期望获得的服务等级协议（SLA）标准是什么（如可用性、故障恢复时间等）？ 暂时应该不会考虑全托

tidb_allow_mpp开，tidb_enforce_mpp关，不要开enforce_mpp [image]

【有哪些好的运维习惯/创新实践，帮你兜住了哪些风险？】 做任何操作之前都要先备份，最好是数据库全备加增量备的基础上，每操作一步，都保证能最短的时间内回滚到上一步，毕竟数据库恢复也要时间的。。。 【用了 TiDB 是否让你更省心？】 必须更省心了

集群中，有两台物理机，每台机器部署2个tiflash实例，这个部署方式有点怪，是两个物理机的物理资源非常充足吗？一般两个物理机，每个部署一个tiflash实例就好了。。。

表名和表结构一致的话，dmf应该没啥区别的地方，主要对应的table_id不一样，目录名可能需要修改下

有测试环境得话，其实有个偏方，你在测试环境创建同一个表，然后把这个表得dmf文件，恢复到生产环境试下能否正确识别