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即可，通过减少数据量来减少内存使用）。