MySQL:Can'；t创建/写入文件'/tmp/#sql#u3c6_0.MYI'；（错误代码：2）-这到底是什么意思？

出于某种原因，我的生产数据库决定发出此消息。所有对数据库的应用程序调用都失败，错误如下：

PreparedStatementCallback; SQL [ /*long sql statement here*/ ]; 
Can't create/write to file '/tmp/#sql_3c6_0.MYI' (Errcode: 2); 
nested exception is java.sql.SQLException: Can't create/write to file '/tmp/#sql_3c6_0.MYI' (Errcode: 2)

我甚至不知道这意味着什么。

/tmp

中没有文件

#sql_3c6_0.MYI

，出于某种原因，我无法创建带有

#

字符的文件。有人听说过或看到过这个错误吗？可能有什么问题以及一些可能的问题需要考虑

---

MySQL数据库似乎已经启动并运行，可以通过控制台进行查询，但应用程序似乎无法访问它。应用程序代码/文件没有更改。事情突然发生了。所以我甚至不知道从哪里开始，或者应该采取什么解决策略。有什么想法吗？

这通常意味着您的

/tmp

分区空间不足，无法创建文件，或者由于权限问题，

mysqld

进程无法写入该目录。有时，当

selinux

下雨时，你的游行队伍就会出现这种情况

---

默认情况下，任何需要“临时文件”的操作都将进入

/tmp

目录。您看到的名称只是一些内部随机名称。

在Fedora系统上运行wordpress时，我也遇到了这个错误

我在谷歌上搜索了一下，想办法解决这个问题

也许这对你也有帮助

检查mysql配置：my.cnf

 cat /etc/my.cnf | grep tmpdir

我的

my.cnf

将

tmpdir=/tmp

添加到

[mysqld]

重新启动web/app和mysql服务器

/etc/init.d/mysqld重新启动

---

文件名看起来像是MySQL中查询创建的临时表。这些文件通常是非常短暂的，它们是在一个特定的查询过程中创建的，然后立即清理

然而，它们可能会变得非常大，这取决于查询需要在临时表中处理的数据量。或者您可能有多个创建临时表的并发查询，如果同时运行足够多的查询，它们可能会耗尽磁盘空间

我做MySQL咨询，我帮助了一位客户，他在根分区上有间歇性的磁盘满错误，尽管他每次查看时都有大约6GB的空闲空间。在检查了他的查询日志之后，我们发现他有时有四个或更多的查询并发运行，每个查询在/tmp中创建一个1.5GB的临时表，该表位于他的根分区上。轰

我给他的解决方案是：

• 增加MySQL配置变量

  tmp_table_size

  和

  max_heap_table_size

  以便MySQL可以在内存中创建非常大的临时表。但是，允许MySQL在内存中创建1.5GB临时表不是一个好主意，因为无法限制并发创建这些表的数量。这样你可以很快耗尽你的记忆

• 将MySQL配置变量

  tmpdir

  设置为另一个磁盘分区上具有更多空间的目录

• 找出哪些查询正在创建如此大的临时表，并优化查询。例如，使用索引帮助该查询将其扫描减少到表的较小部分。或者归档数据中的一些数据，这样查询就不会有那么多行需要扫描

---

在带有systemd MySQL的Fedora上获取私有/tmp目录。在MySQL/mountinfo的/proc/PID\u中，您会发现如下行：

156 129 8:1/tmp/systemd-namespace-AN7vo9/private/tmp rw，relatime- ext4/dev/sda1 rw，seclabel，数据=已订购

这意味着一个临时文件夹/tmp/systemd-namespace-AN7vo9/private作为/tmp挂载在MySQL进程的私有名称空间中不幸的是，如果不经常使用，tmpwatch会删除此文件夹。

我修改了/etc/cron.daily/tmpwatch并插入了排除模式

-X'/tmp/systemd namespace*'

，如下所示：

/usr/sbin/tmpwatch "$flags" -x /tmp/.X11-unix -x /tmp/.XIM-unix \
        -x /tmp/.font-unix -x /tmp/.ICE-unix -x /tmp/.Test-unix \
        -X '/tmp/systemd-namespace*' \
        -X '/tmp/hsperfdata_*' 10d /tmp

---

副作用是未使用的私有名称空间文件夹不会自动删除。

非常感谢ArturZ为我指明了正确的方向。我的系统上没有安装tmpwatch，因此这不是我的问题的原因。但最终结果是一样的：systemd创建的private/tmp正在被删除。下面是发生的情况：

systemd通过clone（）和clone\u NEWNS创建一个新进程 获取私有名称空间的标志。或者它称之为unshare（） 和克隆人纽恩斯。同样的事情

systemd在/tmp中创建一个子目录（例如。 /tmp/systemd命名空间（XRiWad/private）并将其装载到/tmp上。 因为CLONE_NEWNS设置在#1中，所以此装入点对用户不可见 所有其他过程

systemd然后在这个私有名称空间中调用mysqld

创建一些特定的数据库操作（例如“descripe；”） &删除临时文件，其副作用是更新 /tmp/systemd命名空间XRiWad/private上的时间戳。其他数据库 操作执行时根本不使用/tmp

最终10天过去了，即使数据库本身 保持活动状态，不会发生更新上的时间戳的操作 /tmp/systemd名称空间XRiWad/private

/bin/systemd tmpfiles出现并删除“旧” /tmp/systemd命名空间XRiWad/private目录，有效 使private/tmp对mysqld不可用，而public/tmp 仍可用于系统上的所有其他内容

重新启动mysqld是可行的，因为这会在第1步用一个全新的private/tmp目录重新启动一切。然而，问题最终又回来了。一次又一次

简单的解决方案是配置/bin/systemd tmpfiles，以便它保留/tmp中名为/tmp/systemd namespace-*的任何内容。为此，我创建了/etc/tmpfiles.d/privatetmp.conf，其中包含以下内容：

x   /tmp/systemd-namespace-*
x   /tmp/systemd-namespace-*/private

问题解决了。

更好的w

    chown root:root /tmp
  chmod 1777 /tmp
  /etc/init.d/mysqld restart

mysql -u root -p

systemctl start mysqld.service

chown root:root /tmp && chmod 1777 /tmp

chmod -R 777 /tmp

[mysqld]
tmpdir=/tmp 

mysqldump: Couldn't execute 'show fields from `wp_autoupdate`': Can't create/write to file '/tmp/#sql_1680_0.MAI' (Errcode: 2 "No such file or directory") (1)

    tmpdir = /var/lib/mysql/tmp

dd if=/dev/zero of=/tmp/file.txt count=1024 bs=1048576