MySQL意外查不到數據，知道真相後使人驚訝不已

導讀 剛剛導入了幾千萬數據，卻意外的查不到，這是爲什麼？

先執行COUNT(*)統計總數

[root@yejr.me]> select count(*) from t1;
+----------+
| count(*) |
+----------+
| 0 |
+----------+
1 row in set (1 min 25.85 sec)
複製代碼

SQL運行的有點慢，結果的確是空的。

再任意查詢一條記錄看看：

[root@yejr.me]> select * from t1 limit 1;
Empty set (13.63 sec)
複製代碼

只查一條記錄而已，這SQL運行的也忒慢了點，結果也仍是空的。

好吧，再看看錶的狀態：

[root@yejr.me]> show table status G
*************************** 1. row ***************************
 Name: t1
 Engine: InnoDB
 Version: 10
 Row_format: Dynamic
 Rows: 28159173
 Avg_row_length: 45
 Data_length: 1269825536
Max_data_length: 0
 Index_length: 1308606464
 Data_free: 1063256064
 Auto_increment: 12851381
 Create_time: 2019-06-04 10:49:44
 Update_time: NULL
 Check_time: NULL
 Collation: utf8mb4_general_ci
 Checksum: NULL
 Create_options: 
 Comment: 
1 row in set (0.00 sec)
 
[root@yejr.me]# ll
-rw-r----- 1 mysql mysql 67 Jun 4 10:34 db.opt
-rw-r----- 1 mysql mysql 8732 Jun 4 10:49 t1.frm
-rw-r----- 1 mysql mysql 2931818496 Jun 4 13:09 t1.ibd
複製代碼

看着明明是有數據的呀，真特麼邪門，下巴都快掉了。

再看看執行SELECT時的線程狀態，發現是正常的Sending data，沒啥特別的。

好吧，要真的放大招了，再看看InnoDB事務狀態：

------------
TRANSACTIONS
------------
Trx id counter 41220
Purge done for trx's n:o < 40288 undo n:o < 0 state: running but idle History list length 44 LIST OF TRANSACTIONS FOR EACH SESSION: ---TRANSACTION 422164356356832, not started 0 lock struct(s), heap size 1136, 0 row lock(s) ---TRANSACTION 40199, ACTIVE 1361 sec recovered trx ROLLING BACK 1 lock struct(s), heap size 1136, 0 row lock(s), undo log entries 3637207 複製代碼

注意到事務 40199 的狀態是正在回滾中"ROLLING BACK"，影響的undo log有3637207之多。

通過確認，緣由肯定了，事務 40199 在導入數據過程當中，導入過程發生了啥問題，對導入線程賤賤的按了CTRL+C。

就問你意不意外，驚不驚喜吧。。。

結果就悲劇了，導入線程的事務被回滾，因此纔看到了那麼多的undo log entries，總共是幾千萬數據啊，只不過咱們看到的時候還剩下300多萬。

後來，又作了一次導入，此次又悲劇了，由於公司斷網了，導入線程又一次被回滾（畫外音，論遠程操做時用screen的重要性）。

在上面這個例子中，可能有同窗會奇怪，爲何導入還沒結束，但卻能看到表空間文件已經挺大的了，並且show table status也能看到rows值比較大。

• 首先，在本案例中，導入數據過程當中，因爲buffer pool有限，沒辦法把全部新數據都放在buffer pool中，部分數據會先寫入到表空間磁盤文件中，因此才能看到表空間文件大小不爲零。
• 其次，show table status看到的統計信息自己不是精確值，在本案中，隨着導入數據增多（雖然導入事務還沒提交），但統計信息也會更新。

和本案相似的場景還有，一個大表被執行全表delete了（不是直接truncate），這個事務產生的undo log還沒被purge完畢，或者這個事務也被回滾了，在這個過程當中，執行 COUNT(*) 的結果可能和預期的不同。

本文到此結束，喜歡的朋友幫忙點點贊和關注一下，感謝！

程序員找出路仍是要儘可能提早進行職業規劃和準備，千萬不要說什麼：「走一步，算一步」的話。在這個一睜眼就是競爭的時代，你能夠放鬆休息，但別人會繼續前進，不會等你。