出于某种原因，我的生产DB决定喷涌出此消息。 所有的应用程序调用失败与错误的DB：
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)
我不知道，这是什么意思连。 没有文件#sql_3c6_0.MYI在/tmp ，我不能创建一个带有#出于某种原因字符。 有没有人听说过或见过这个错误？ 什么可能是错误的，一些可能的事情来看待？
MySQL数据库似乎是启动和运行，并可以通过控制台进行查询，但应用程序似乎无法打通了。 有应用程序代码/文件没有变化。 它只是发生了蓝色。 所以我甚至不知道从哪里开始看或申请何种分辨率的战术。 有任何想法吗？
通常，这意味着你/tmp分区已用完的空间，无法创建文件，或无论什么原因， mysqld进程不能写，因为权限问题，目录。 有时，这种时的情况selinux上的游行降雨。
这requites一个“临时文件”的任何操作将进入/tmp的缺省目录。 你看到的名称只是一些内部随机名称。
我遇到这个错误太当我我的Fedora系统上运行WordPress的。
我GOOGLE了它，并找到一个方法来解决这个问题。
也许这将帮助你。
检查MySQL的配置：my.cnf中
cat /etc/my.cnf | grep tmpdir 我什么都看不到我my.cnf
添加tmpdir=/tmp到my.cnf下[mysqld]
重启网络/应用程序和MySQL服务器
/etc/init.d/mysqld restart
在Fedora与systemd MySQL的获取私人/ tmp目录。 在/ proc / PID_of_MySQL / mountinfo你会发现像行：
156 129 8：1 / TMP / systemd名称空间AN7vo9 /私人/ TMP RW，relatime - EXT4的/ dev / SDA1 RW，SECLABEL，数据=有序
这意味着一个临时文件夹/ TMP / systemd名称空间AN7vo9 /私人安装为在MySQL进程的专用名称空间的/ tmp。 不幸的是这个文件夹是由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
副作用是未使用的私人文件夹的命名空间将不会被自动删除。
文件名看起来像在MySQL中的查询创建临时表。 这些文件往往很短暂，他们在一个特定的查询过程中创建和清理随即。
然而，他们可能会变得非常大，这取决于数据的查询需要一个临时表来处理量。 或者你可能有多个并发查询创建临时表，并且有足够的这些查询的同时运行，它们可能会耗尽磁盘空间。
我做MySQL的咨询，我帮一个客户谁在他的root分区有间歇磁盘已满错误，尽管他每次看的时候，他有大约6GB免费。 之后，我们检查了他查询日志中，我们发现，他有时有四个或更多的查询同时运行，每个创建在/ tmp下的1.5GB的临时表，这是他的根分区。 繁荣！
解决方案我给他：
增加MySQL的配置变量tmp_table_size和max_heap_table_size因此MySQL可以在内存中创建真正的大的临时表。 但是，这不是一个好主意，让MySQL来在内存中创建1.5GB临时表，因为没有办法来限制多少这些很多都是同时创建。 你可以很快耗尽内存这种方式。
设置MySQL的配置变量tmpdir有更多空间到另一个磁盘分区的目录。
找出其中你查询的是创造这么大的临时表，并优化查询。 例如，使用索引来帮助该查询降低其扫描表中的一个小片段。 要不然归档一些故事的数据，以便查询不会有这么多行扫描。
巨大的感谢ArturZ为指向我在这个正确的方向。 我没有我的系统上安装tmpwatch所以这不是我的情况下，问题的原因。 但最终的结果是一样的：私人/ tmp中systemd创建是越来越删除。 这里是发生了什么：
systemd创建通过的clone（）与CLONE_NEWNS标志获得一个私有的命名空间的新进程。 或者，也许它调用取消共享（）与CLONE_NEWNS。 一样。
systemd将在/ tmp目录（例如，/ tmp目录/ systemd名称空间XRiWad /私有）的子目录，并安装其上的/ tmp。 由于CLONE_NEWNS在＃1套，这个挂载点是不可见的所有其他进程。
systemd然后调用mysqld的本次非公开命名空间。
一些具体的数据库操作（如“形容;”）创建和删除临时文件，其中有在/ tmp / systemd名称空间XRiWad /私有更新时间戳的副作用。 其他数据库操作执行不使用/ tmp目录在所有。
最终10天去了那里，即使数据库本身保持活性，不会发生操作该更新在/ tmp / systemd名称空间XRiWad /私人的时间戳。
/斌/ systemd-TMPFILES走来，并删除“旧”的/ tmp / systemd名称空间XRiWad / private目录，从而有效地使私人的/ tmp不能用于mysqld的，而公共/ tmp中保持可用于在系统上的一切。
重新启动mysqld的工作，因为这在步骤＃1重新开始一切，以崭新的私有/ tmp目录。 但是，问题最终还是回来再来。 然后再次。
简单的解决办法是配置/斌/ systemd-TMPFILES，以便保留在/ tmp目录与名称的/ tmp / systemd-namespace- *什么。 我这样做是通过以下内容创建/etc/tmpfiles.d/privatetmp.conf：
x /tmp/systemd-namespace-*
x /tmp/systemd-namespace-*/private
问题解决了。
对我来说，不使用MySQL的，也不是网络服务器长时间后，这个问题就来了。 所以，我相信，我的设置里正确的; 只需重新启动该服务修复了这个问题; 关于这个问题的怪异的是，人们仍然可以连接到数据库，甚至查询/添加使用mysql刀具表。 例如 ：
mysql -u root -p
我重新开始使用：
systemctl start mysqld.service
或服务的mysqld重新启动或重启/etc/init.d/mysqld
注：根据机器/环境对这些命令都应该重新启动该服务。
一种更好的方式为我工作。
chown root:root /tmp
chmod 1777 /tmp
/etc/init.d/mysqld restart
这就对了。
在这里看到： http://nixcraft.com/databases-servers/14260-error-1-hy000-cant-create-write-file-tmp-sql_9f3_0-myi-errcode-13-a.html
http://smashingweb.info/solved-mysql-tmp-error-cant-createwrite-to-file-tmpmykbo3bl-errcode-13/
这是很容易，你只授予在/ tmp文件夹的权限777。 只需键入：
chmod -R 777 /tmp
在Ubuntu中，我开始移动/ tmp目录不同的卷（符号链接）之后得到这个错误。 即使设置所需的权限1777之后，该问题尚未解决。
MySQL是通过AppArmor的，这是不允许写入新的TMP位置的/ mnt / tmp目录的保护。 我不得不添加以下行/etc/apparmor.d/abstractions/user-tmp解决这个问题
所有者的/ mnt / TMP / ** rwkl，
的/ mnt / TMP / RW，
在Debian 7.5，我得到了同样的错误。 我意识到/tmp文件夹的所有者和权限被关闭。 作为另一个答案建议我做了如下（必须是root）：
chown root:root /tmp && chmod 1777 /tmp
我甚至没有重新启动mysql的守护进程。
由于它的SELinux时启用它不会允许外部的可执行文件在系统中的位置创建临时文件，专门访问控制安全策略。
禁用SELinux通过发出以下命令：
回声0> / selinux的/执行
现在，您可以启动mysql它不会给任何许可相关errror而读/写/ tmp或系统目录。
如果您想启用SELinux的安全性上面的命令更改回0到1。
检查权限问题，mysql的配置。
还要检查，如果你还没有达到磁盘空间，配额限制。
注意：有些系统限制的文件数量（不只是空间），删除一些旧的会话文件帮助我的情况下解决了该问题。
