这两天一直在用mysql做一些事情，但是从前天开始，系统启动时经常出现无法创建/写入文件‘c:\ temp/# SQL-XXX . myi’(errcode:13)这样的错误。我以为可能是我系统的问题，就重启了应用和MySQL，问题还是接二连三的出现，但也不是一直都出现。我注意到这个问题通常发生在查询数据量比较大的时候。我觉得应该是数据量大的数据库操作。当MySQL要向temp目录写入临时文件时，由于某种原因无法写入，导致了这个问题。对于我来说，我试着按照以下步骤来分析和处理。
第一，可能是之前MySQL生成的临时文件还存在，只是因为只读属性无法写入。我仔细检查了临时目录，但是没有找到任何扩展名为“MYI”的文件，所以我删除了临时目录中的所有文件。重启MySQL和应用系统，问题还是会出现；
第二，我怀疑temp目录是否有只读属性或者禁止对MySQL用户写，但是我的是在WindowsXP上，临时目录里会有其他系统生成的临时文件，也就是说目录是可以读写的，而且我是用超级用户启动MySQL的，所以不存在目录没有写权限的问题；
3.会不会是杀毒软件的实时文件保护使得临时文件无法写入？因为我的查杀软件病毒库每天都在升级，前几天系统没有这个问题，但是这几天，我可以了。我升级病毒库后，查杀软件阻止MySQL生成临时文件了吗？我在软件查杀过程中将temp目录设置为不检测，然后重启MySQL和应用，再看temp目录。临时文件，如#sql-XXX。MYI或#sql-XXX。MYD将出现在其中，应用系统正常启动。看来问题出在查杀软件，禁止MySQL生成“MYI”或“MYD”临时文件，导致了问题的产生。
至此，我以为问题就这样解决了，但是在接下来的启动中，我看到生成了临时文件，于是我右击了临时文件#sql-XXX。MYI看到的文件属性，这是伟大的。原来的错误再次出现在应用系统中。发生了什么事？我再次停止应用程序，然后重新启动它。重启过程中，没有操作临时文件，应用程序正常启动。这是为什么呢？
我的分析可能是这样的：MySQL生成的临时文件存在时间很短，MySQL需要在临时文件生成后立即使用和删除。此时，如果另一个软件访问或操作这些临时文件，MySQL将无法及时获得文件访问权限，并会抛出错误。因为开启了文件保护功能，所以当MySQL生成临时文件时，会锁定文件进行病毒检测，导致MySQL无法立即操作这些文件，从而抛出错误。同样，当我尝试查看文件属性时，操作系统也会短时间锁定文件，这个锁定让MySQL无法自己操作，所以我也会抛出这个错误。
现在这个问题看起来已经解决了，但是是否真的解决了还有待未来几天的观察，我的分析是否正确还有待历史的评判，呵呵。
另外，我也在网上搜了一下，发现很多人也遇到了这个问题，但是大部分人认为目录没有写权限，也有人知道问题是杀软造成的，但是没有深入分析原因。我要向有同样经历的哥哥扔砖头。
