问题现象

TiDB数据库版本为4.0.0，业务执行一条常规SQL，前端返回查询失败，报错信息如下：

问题分析

1、跟业务人员确认，该sql不是新上线的，是一直就存在的，突然就执行失败了。

2、检查数据库侧，发现并无报错和告警。

3、跟业务人员了解到sql语句如下：

4、分析该sql发现，是3张表进行join，而当这条sql使用的内存超过限制时，就会往磁盘上写，也正是报错中的/tmp/tidb目录下面写。

5、tidb对使用临时空间的控制参数如下：

oom-use-tmp-storage：设置是否在单条 SQL 语句的内存使用超出 mem-quota-query 限制时为某些算子启用临时磁盘。

tmp-storage-path：单条 SQL 语句的内存使用超出 mem-quota-query 限制时，某些算子的临时磁盘存储位置。

tmp-storage-quota：tmp-storage-path 存储使用的限额。当单条 SQL 语句使用临时磁盘，导致 TiDB server 的总体临时磁盘总量超过 tmp-storage-quota 时，当前 SQL 操作会被取消，并返回 Out Of Global Storage Quota! 错误

6、根据上述3个参数的描述，该sql之前可以执行成功，突然执行失败，则该sql语句不是超过mem-quota-query和tmp-storage- quota限制导致的，进而去排查tmp-storage-path参数。

7、检查tidb节点tmp-storage-path参数对应的目录，跟报错提示的目录是一样的，那说明问题就出在这里了。

8、检查每台tidb服务器上的tmp-storage-path参数对应的目录，发现该目录不在了，问题浮出水面。

问题处理

1、在tidb server上创建/tmp/tidb目录。

2、检查crontab是否存在定期删除/tmp内容的脚本，发现后注释掉。

总结反馈

1、当数据库出现问题时，首先想到数据库是否有变更之类的操作，结合报错信息，根据数据库原理，去分析数据库问题点在哪，快速定位、分析、解决问题，保障业务的连续性；

2、对数据库系统进行操作都要谨小慎微，对数据库系统进行变更时都要按照规范流程来执行。