TiDB节点在什么情况下会使用磁盘呢？

[kkpeter (Upstream889)]

发现集群偶发的会有TiDB节点磁盘IO上升，这个想知道都在什么情况下TiDB节点会使用磁盘呢，除了写日志和慢日志

[啦啦啦啦啦]

6.5以后加索引tidb节点也会有临时磁盘占用。 当内存使用超出 mem-quota-query限制时某些算子也会用临时磁盘

[TiDBer_5cwU0ltE]

@kkpeter

有TiDB节点磁盘IO上升，这个想知道都在什么情况下TiDB节点会使用磁盘

IO上升到影响性能的地步了么，感觉没影响的话，可以先不管。 或者用一些探测工具， 看看是什么进程在写盘。

[kkpeter (Upstream889)]

除了这些还有什么?

[TiDBer_QYr0vohO]

pd 有个dashboard，里面查看组件日志的时候也会读取磁盘TiDB server上的日志，还有监控等等

[zhanggame1 (Ti D Ber G I13ecx U)]

可以参考下这里

tidb会用到临时硬盘空间
TiDB 环境与系统配置检查 | PingCAP 文档中心

[啦啦啦啦啦]

一般来说就这两种，查日志之类的也会占一点，但是很少。

[kkpeter (Upstream889)]

这两个目录我都配置了，设置在data盘， 但是系统盘io竟然上升使用了78%，有点奇怪

[zhanggame1 (Ti D Ber G I13ecx U)]

装个iotop命令看看具体是什么进程

[Fly-bird]

临时空间吧

[昵称想不起来了]

结合linux命令结果查证下呢？
iotop命令查看使用io较高的进程
lsof命令查看进程在使用的文件
strace命令跟踪和调试进程的系统调用

[人如其名]

1、有sort排序，如果当前会话内存不足会进行外部排序，外部排序后磁盘读写效率较低导致性能较为低下，目前已有PR优化：https://github.com/pingcap/tidb/pull/46483 。
2、有hashAGG形式的聚合，在默认参数下并不会落盘，同时开启tidb_hashagg_final_concurrency=1,tidb_hashagg_partial_concurrency=1参数让其走非并行hashAGG模式，那么如果agg的结果集太大也会发生落盘，具体细节可以参考：对于hashAgg算子非并行模式下还是发生OOM ，对于并行hashAGG的落盘能力（默认参数即可）这个也已经有了issue，可以关注：https://github.com/pingcap/tidb/issues/46631 。
3、hashjoin，当hashJoin的buildSide过大时候会对数据进行落盘，在内存中仅保存行指针，具体细节可以参考：当HashJoin的BuildSide过大时容易OOM 。
4、merge_join，inner_table的重复值太多也可能会溢出磁盘。
5、CTE，公共表达式（with xxx as结构），会话内存不足时中间结果会落盘。
6、CursorFetch获取数据， 当使用 MySQL 的 Cursor Fetch 协议时，结果集占用的内存超过 tidb_mem_quota_query 的限制导致 TiDB OOM 的问题，修复后，TiDB 会自动将结果集写入磁盘以释放内存资源，具体修复PR：https://github.com/pingcap/tidb/pull/45163 ，这个已经在6.5.4修复。
7、DDL添加索引，在添加索引时走ingest会加速索引创建，但同时也会占用大量的临时空间。

我认为还需要有落盘机制的有：
1、临时表，目前临时表为内存表，使用受限较大，应有落盘机制，参考帖子：临时表能力的增强与tidb-server层缓存机制的建立 。
2、DML大事务，目前大事务会读取所有记录到tidb-server内存中，应有落盘机制，减少内存的使用（PS：delete和update操作都会向tikv中读取整行数据，应进行优化比如delete只拿key到tidb-server即可，通过减少数据量来减少内存使用）。

[redgame (Ti D Ber Pa Amoi Ul)]

临时表和排序，我们这里这两个多