先說一下這篇文章包含的知識點：bin_log服務查詢，bin_log文件轉爲SQL文件，MySQL重啓，MySQL磁盤不足報錯，MySQL表名大小寫配置
事情起因：
操作數據庫的是我們的萌新妹子，不太懂MySQL數據庫這些東西，只會用，不會修，今天一開工她就給我說之前一直都可以訪問的表訪問不了，應該是被某人刪除了，而且是一大半的表都不見了！！！讓我找找原因，剛剛收到這個消息的時候我是真滴是慌，刪庫跑路的劇情要發生在年紀輕輕的我身上了嗎？？之前也沒有過恢復數據的經驗，沒辦法，只好硬着頭皮一個人單幹，我是項目的主要負責人之一那自然就得找出問題所在咯，我的MySQL客戶端用的是Linux上的DBeaver，下面請大家欣賞一下MySQL報錯的界面截圖。
org.jkiss.dbeaver.model.sql.DBSQLException: SQL 錯誤 [1146] [42S02]: Table 'vm-cmgxbs-industry-spider.zbyinformation' doesn't exist
at org.jkiss.dbeaver.model.impl.jdbc.exec.JDBCStatementImpl.executeStatement(JDBCStatementImpl.java:134)
at org.jkiss.dbeaver.model.impl.jdbc.struct.JDBCTable.readData(JDBCTable.java:186)
at org.jkiss.dbeaver.ui.controls.resultset.ResultSetJobDataRead.lambda$0(ResultSetJobDataRead.java:111)
at org.jkiss.dbeaver.model.exec.DBExecUtils.tryExecuteRecover(DBExecUtils.java:170)
at org.jkiss.dbeaver.ui.controls.resultset.ResultSetJobDataRead.run(ResultSetJobDataRead.java:109)
at org.jkiss.dbeaver.ui.controls.resultset.ResultSetViewer$17.run(ResultSetViewer.java:3580)
at org.jkiss.dbeaver.model.runtime.AbstractJob.run(AbstractJob.java:103)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: java.sql.SQLSyntaxErrorException: Table 'vm-cmgxbs-industry-spider.zbyinformation' doesn't exist
at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:118)
at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:95)
at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:122)
at com.mysql.cj.jdbc.StatementImpl.executeInternal(StatementImpl.java:790)
at com.mysql.cj.jdbc.StatementImpl.execute(StatementImpl.java:675)
at org.jkiss.dbeaver.model.impl.jdbc.exec.JDBCStatementImpl.execute(JDBCStatementImpl.java:338)
at org.jkiss.dbeaver.model.impl.jdbc.exec.JDBCStatementImpl.executeStatement(JDBCStatementImpl.java:131)
... 7 more
這裏報錯的關鍵字是：Table 'tablename' doesn't exist，妹子也給我說這個表被刪了所以有點被誤導了，以爲表真的被別人給刪了，就往恢復數據那個方向去想了，剛好我們這個MySQL開啓了bin_log服務，會自動備份，下面是查看MySQL有沒有開啓bin_log服務的查詢語句。
show variables like '%log_bin%';
看到這個大大的ON沒有，ON就是bin_log服務打開了！
然後我上去服務器/var/lib/mysql/目錄看了一下，確實有巨多bin_log文件，心裏就瞬間踏實了，以下請大家欣賞一下我數據庫中的bin_log文件：
我就想着把這些bin_log文件轉爲SQL語句，看一下哪裏執行了刪表語句，也就是DROP語句嘛，心想找到了刪表語句然後把刪表語句以及後面的操作都刪掉以後不就得到了恢復數據的SQL語句了嗎？心裏不禁泛起一陣欣喜，下面請大家欣賞一下bin_log文件轉SQL語句的命令：
mysqlbinlog -d databasesname mysql-bin.000001 >001bin.sql
下面是贈品，附贈一條數據庫全備份命令：
mysqldump -h192.168.xxx.xxx -p3306 -uroot -p123456 --all-databases > /data/backup/all_db.sql
不看不知道，一看嚇一跳，轉換後的sql文件裏面根本就沒有DROP語句，也就是說沒有表被刪除了，那麼爲什麼MySQL會報錯爲表不存在呢？？？
真的是一臉懵逼啊，於是我上服務器的數據庫目錄/var/lib/mysql/databsesname/看了一下，不看不知道，一看嚇一跳，發現裏面的表都在啊！都是有數據的！坑爹啊爲什麼表數據都在爲什麼會報錯啊！！！
我想了很久，突然靈機一動，出現奇葩問題先來個重啓，於是我運行了MySQL服務重啓命令，下面有請大家欣賞MySQL服務重啓命令：
service mysqld restart
MySQL重啓的時候是會先把MySQL服務給關掉再重新啓動的，呆呆地在屏幕前等待服務關閉在啓動，嗯，服務關閉成功，大大的綠色OK打印在了屏幕上，等了一會，屏幕上打印出了一串英文，MySQL服務啓動失敗！！！一般年輕人嘛都比較莽，我又運行了幾次MySQL重啓命令，結果還是一樣，關閉服務是成功的，啓動服務是失敗的！
哎，大哥，你啓動失敗怎麼沒有報錯啊，很不講道理啊你，於是我就找到了MySQL報錯日誌，這個報錯日誌是在/etc/my.cnf配置文件中配置的，我的服務器是這個路徑log-error=/var/log/mysqld.log，cat了一下日誌，發現了幾個報錯，下面有請大家欣賞一下我的報錯信息：
2020-05-09T03:51:33.263278Z 0 [ERROR] InnoDB: Write to file ./ibtmp1failed at offset 0, 1048576 bytes should have been written, only 0 were written. Operating system error number 28. Check that your OS and file system support files of this size. Check also that the disk is not full or a disk quota exceeded.
2020-05-09T03:51:33.263316Z 0 [ERROR] InnoDB: Error number 28 means 'No space left on device'
2020-05-09T03:51:33.263340Z 0 [Note] InnoDB: Some operating system error numbers are described at http://dev.mysql.com/doc/refman/5.7/en/operating-system-error-codes.html
2020-05-09T03:51:33.263353Z 0 [ERROR] InnoDB: Could not set the file size of './ibtmp1'. Probably out of disk space
2020-05-09T03:51:33.263370Z 0 [ERROR] InnoDB: Unable to create the shared innodb_temporary
2020-05-09T03:51:33.263382Z 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2020-05-09T03:51:33.764192020-05-09T03:51:33.784202Z mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
報錯信息當然要先找到關鍵字咯，我看到的關鍵字是：
Check that your OS and file system support files of this size. Check also that the disk is not full or a disk quota exceeded.
翻譯一下就是哎呀，你的磁盤不夠空間了，不夠空間還想啓動MySQL？吃屁吧你！
沒辦法，磁盤空間不夠我就把一些沒用的備份給刪了，空出了幾個g的空間後再重啓MySQL服務，結果是啓動成功哈哈哈哈哈！！！
有時候程序員解決問題都抱有一些神學色彩的幻想，啓動成功了啊，之前的表不存在的問題會不會也解決了呢？會不會就是這個空間不夠的問題啊！想想都有點興奮呢，結果上去數據庫一查，該報錯的表還是報錯了，和之前沒有絲毫區別。我的媽，那究竟是什麼問題啊...
我想了很久沒有頭緒。
於是我讓妹子把報錯的表名都給我列了一下，不看不知道，一看嚇一跳！！！
表名裏面居然都是大小寫混着的，每個表名都有若干個小寫字母，若干個大寫字母！！！沒有報錯的表都是沒有大寫字母的！
突然鬆了一口氣，嗨，這不就是表名的大小寫字母的問題嗎，簡單，改一下配置就好。
於是我就改了一下my.cnf中的參數，我這邊的my.cnf路徑是/etc/my.cnf，my.cnf是MySQL的配置文件，可以配置bin_log，表名大小寫和日誌路徑等等東西，下面有請大家欣賞一下我這邊導致數據庫報錯的配置：
lower_case_table_names=1
對！就是這麼一條小小的配置！
我們先了解一下這一個配置的不同參數的不同作用：
lower_case_table_names： 此參數不可以動態修改，必須重啓數據庫
lower_case_table_names = 1 表名存儲在磁盤是小寫的，但是比較的時候是不區分大小寫
lower_case_table_names = 0 表名存儲爲給定的大小和比較是區分大小寫的
lower_case_table_names = 2 表名存儲爲給定的大小寫但是比較的時候是小寫的
————————————————
版權聲明：本文爲CSDN博主「wluckdog」的原創文章，遵循CC 4.0 BY-SA版權協議
原文鏈接：https://blog.csdn.net/wll_1017/article/details/55105180
注意啊，以下都是我的猜測，不嚴謹的，沒有經過驗證。
我的思路是這樣的啊，我先假定是這個配置出問題了，然後我就認爲妹子在建表的時候這個配置是lower_case_table_names = 0，也就是說表名存儲在磁盤的是建表的時候是什麼就是什麼，大小寫混在一起用就是混在一起用，不會給你搞花裏胡哨的大小寫轉換。
那麼假如我建表的時候表名爲 testTable ，那麼 lower_case_table_names = 0 的時候表名存儲在磁盤中就是 testTable，而 lower_case_table_names = 1 的意思是表名存儲在磁盤中的都是小寫，那麼當配置爲 lower_case_table_names = 1 的時候我執行命令 select * from testTable; 它會給我轉換爲 select * from testtable; 或者 select * from TESTTABLE; 那怎麼可能查詢到這個表嘛，這兩個表名都不存在！！！
思路有了我就屁顛屁顛 vim /etc/my.cnf 把 lower_case_table_names = 1 改爲 lower_case_table_names = 0 然後重啓MySQL服務，注意啊，修改完這配置一定要重啓MySQL服務！
然後我又用MySQL客戶端DBeaver查詢了一下表，哦吼！還是原封不動地給我報錯。
我真的就不信邪了，直接上服務器打開MySQL查詢了一下，嗯哼！都查出數據了！！難道是你這個DBeaver的問題？？
最後嘛，我把DBeaver的數據庫連接斷開重連後就查詢成功啦！！
於是我立馬跑去告訴萌新妹子，妹子，數據庫恢復啦，你快上去看看！！！
可喜可賀，終於結束了。
最後總結一下：
1 原來一直可以用的表突然不可用了，但表名還在那裏顯示着的話，那就先看一下不可用的這些表名是不是有某種特徵
2 如果MySQL服務關閉成功，但啓動失敗的話先找到日誌文件所在位置，再看一下報錯信息，還有可以先考慮一下是空間不足的問題
3 表名儘量用全小寫！用全小寫！或者是全大寫！全大寫！
4 數據沒了先別忙着跑路啊，可能只是小問題