mysql数据库show tables 显示表名，但是查询的时候却提示此表不存在
这个问题今天弄了一整天，一直没有解决，网上搜了好多解决方案，但都没有用！ 报错如下： 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的配置不明！理解不彻！不能瞎找解决方案，尽管有些问题的描述很相似，但是解决问题的方法却是截然不同！应该分析产生问题的原因，理解自己所处的环境，看清未来的方向！ 本文出自 “从运维到ETL” 博客，请务必保留此出处http://fuwenchao.blog.51cto.com/6008712/1335516