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