这几天一直被email困扰着，一直找原因，一直盼着email赶快恢复，心里也一直很烦很不安，我这人性子有些急躁，出了问题就希望马上解决，但也还是会静下心来找原因，找bug。也不会急躁到一时半会找不到就放弃。昨天晚上算了安心了些，email终于可以访问而且也不会刚刚一启动服务器没过一会就down了。我呢也在我仔细的检查中发现了一个问题，现在已解决。

        今天早上来登陆email的时候有发现一个问题，从来没遇到过的问题。因为没有过解决经验，就只能靠搜索引擎的帮助了。

问题：mysql错误：Can’t find file: ‘table_name’ (errno: 2)

原因：这个问题是由于服务器或MYSQL不正常的关闭造成的-网络上说的，我觉得很符合我的这种情况。

解决方案：

=恢复步骤=
1.到MySQL后台，执行删除表操作：
DROP TABLE `table_name`;
2.到MySQL后台，执行创建表操作：
CREATE TABLE table_name (
  logid mediumint(8) unsigned NOT NULL auto_increment,
  id mediumint(8) unsigned NOT NULL default '0',
  idtype char(20) NOT NULL default '',
  PRIMARY KEY  (logid)
) ENGINE=MyISAM;
 

我用此方案成功解决了mysql错误：Can’t find file: ‘table_name’ (errno: 2)错误。

下面再贴下一篇我觉得不错的也是解决该错误的文章：

配置好mutt收发邮件之后，才发现cron每天执行的时候，如果执行中有错误提示或者输出，虽然用户看不见，但他会发一封本地邮件给管理员，在mutt中能够收到。比如，我就收到了这么一封邮件：

我也是这样才发现每天备份数据库的时候都有错误了，表ads的数据根本就没有备份出来，再衍生查询一下，好几个表都这样，恐怖啊，幸亏及时发现，看来费这么大的力气来搞mutt还是有点用处的。

再来看这个错误，“Can’t find file: ‘tbl_name’ (errno: 2)”这个错误产生的原因在mysql手册中有解释，存储数据表的文件名是有大小写的，大小写错误了就会“找不到”，即使是在不去分文件名大小写的操作系统（比如windows）下，查询中引用的表名也应保持大小写的一致性。

而我产生这个错误的表，原来是在windows服务器下使用的，现在转到linux服务器下了，并且在很长的时间里都没有访问，只是一直舍不得扔掉，每次备份的时候都带着。以前这些数据表都保存在fat32分区中，上次倒腾硬盘的时候，都转换成了ext3分区。再查看一下文件名，果然存在文件名大小写的问题。

一般采用分散文件方式保存的mysql数据表（MyIsam默认，InnoDb也可以通过选项innodb_file_per_table设置），每个表一般有三个文件，扩展名分别是.frm .MYD .MYI，注意大小写！我那些提示出错的表，扩展名三个都是小写的！于是把扩展名MYD MYI都改成大写，问题解决！

至于这些表名为什么成了小写，应该是原来在fat32分区上，windows服务器的时候造成的，因为一般windows下文件的扩展名都是小写的。

本文来源于php爱好者：php教程 —http://www.phplover.cn/
原文地址：http://www.phplover.cn/post/mysql-can-not-find-file-error-2.html