這個問題今天弄了一整天，一直沒有解決，網上搜了好多解決方案，但都沒有用！ 報錯如下： 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