作者： cchouqiang 原文来源：https://tidb.net/blog/a2dbae96

问题现象

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、对数据库系统进行操作都要谨小慎微，对数据库系统进行变更时都要按照规范流程来执行。