这个问题今天弄了一整天，一直没有解决，网上搜了好多解决方案，但都没有用！
报错如下：

ERROR 1146 (42S02):

Last_Error: Error 'Table 'mysqldb.frm_auditLog' doesn't exist'

Error " ERROR 1146 (42S02): Table 'database.tablename' doesn't exist" after restoration

mysql 数据库 show tables 显示表名，但是查询的时候却提示此表不存在是怎么回事？

开始以为问题的来源是这个：
问题的起因：
     有一台mysql服务器，其已经运行了很长时间了，由于后来流量增大，且新的需求中关于统计，分析之类的多了起来。为防止影响该服务器的运行，决定使用主从式配置。统计，分析之类在从服务器上进行。（数据库使用InnoDB引擎）
      在从服务器搭建好后，首先手工同步数据。在将对应的数据库目录打包复制到从服务器后，启动从服务器，在用mysql客户端登录后，发现在使用 “select * from 表名”  时出现 ERROR 1146 (42S02)。
解决过程：
      一、查mysql文档，发现在使用innoDB引擎的数据库中，其实际数据不是存放在数据库目录下的，而是放在一个叫ibdata1的文件内(默认配置时)，其目录下只是放置了数据库的表及表结构相关的信息。复制ibdata1文件至从服务器对应目录后，重启，仍出现该问题
      二、仔细检查发现，从服务器中多了个ibdata2的文件。在检查过主从服务器的配置文件my.cnf 后发现，在从服务器的设置中，有innodb_data_file_path = ibdata1:2000M;ibdata2:10M:autoextend 语句，将该语句注释（主服务器中也是注释掉的），停止服务器，并删除ibdata2 文件及相关的其他初始文件，重启后发现该问题仍然存在
      三、经过仔细查看mysql文档，可能是由于主服务中的数据缓存而造成的问题（即此时 ibdata1文件可能是不一致的）。经过相应处理后，在从服务器的该问题得到解决。其处理过程如下：（mysql>  表示在 mysql客户端执行。 shell>表示在 linux的shell中执行）
         主服务器操作：
        1、mysql> flush tables with read lock;
        2、 mysql> reset master;
        3、 shell> 复制 ibdata1 到指定目录
        4、mysql> unlock tables;
       从服务器操作
       5、shell> 首先停止服务
       6、shell> 删除mysql在启动过程中产生的文件及ibdata1及相关文件。
       7、shell> 启动服务，并停止。
       8、shell> 复制刚才主服务器中的 ibdata1到对应的目录下（overview）
       9、 shell> 启动服务。
但是我的两个数据库引擎A是myisam，B是innodb，

1 查看系统支持的存储引擎

show engines;

2 查看表使用的存储引擎

两种方法：

a、show table status from db_name where name='table_name';

b、show create table table_name;

如果显示的格式不好看，可以用\g代替行尾分号

不管，先将B引擎修改

找到mysql安装目录下的my.cnf文件：

找到default-storage-engine=INNODB 改为default-storage-engine=MYISAM

重启mysql！

还是同样的错，按照上面的提示修改；但是在第九步的时候重启mysql根本启动不了！！！报错为pid无法更新！！！

删除ibdata1，重启成功！

但是表还是不存在错误；

http://jazka.blog.51cto.com/809003/330418

找呀找，试呀试，想把表删除之后重建，但是删除是提示找不到表，晕死！然后又执行scp命令，把服务器上的该表的三个文件同时复制到本地，重启服务，还是不行！

看到有说执行修复myisamchk filename管用，管个屁用，表都找不到

然后又是mysql>  SOURCE /download/mysql-5.6.14/build/scripts/mysql_fix_privilege_tables.sql修复，以为OK，空欢喜一场！

时间慢慢过去，一阵一阵的痛骂，但是问题还是在哪里，理清思路，沉着冷静，继续前行

终于不服有心人，看到了

项目在开发的时候在WINDOWS平台下开发的，开发完了之后在LINUX环境上部署好之后，运行时MySQL数据库报错，提示为某个表不存在之类的错误信息，后来修改了MySQL的配置文件将大小写敏感去掉，问题解决。
这个问题的根源在于，在 MySQL 中，数据库和表其实就是数据目录下的目录和文件，因而，操作系统的敏感性决定数据库和表命名的大小写敏感。这就意味着数据库和表名在 Windows 中是大小写不敏感的，而在大多数类型的 Unix/Linux 系统中是大小写敏感的。
MySQL大小写敏感可以通过配置文件的lower_case_table_names参数来控制。
WINDOWS：
编辑MySQL安装目录下的my.ini 文件，在[mysqld]节下 添加 lower_case_table_names=0 (备注：为0时大小写敏感，为1时大小写不敏感，默认为1)，可以实现MySql按照建表Sql语句的大小写状态来定义表名。
LINUX：
编辑/etc/my.cnf文件,在[mysqld]节下 添加 lower_case_table_names=1 参数，并设置相应的值 (备注：为0时大小写敏感，为1时大小写不敏感，默认为0)。


赶紧在/etc/my.cnf中添加 lower_case_table_names=1 参数！

好了，欲哭无泪呀！！！！

总结：对mysql的配置不明！理解不彻！不能瞎找解决方案，尽管有些问题的描述很相似，但是解决问题的方法却是截然不同！应该分析产生问题的原因，理解自己所处的环境，看清未来的方向！