MySQL查不到導(dǎo)入的數(shù)據(jù)是什么原因

下文主要給大家?guī)?a title="MySQL" target="_blank" href="http://www.kemok4.com/mysql/">MySQL查不到導(dǎo)入的數(shù)據(jù)是什么原因，希望這些內(nèi)容能夠帶給大家實(shí)際用處，這也是我編輯MySQL查不到導(dǎo)入的數(shù)據(jù)是什么原因這篇文章的主要目的。好了，廢話不多說，大家直接看下文吧。

先執(zhí)行COUNT(*)統(tǒng)計(jì)總數(shù)

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

SQL運(yùn)行的有點(diǎn)慢，結(jié)果的確是空的。

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

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

只查一條記錄而已，這SQL運(yùn)行的也忒慢了點(diǎn)，結(jié)果也還是空的。

好吧，再看看表的狀態(tài)：

[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

看著明明是有數(shù)據(jù)的呀，真特么邪門，下巴都快掉了。

再看看執(zhí)行SELECT時(shí)的線程狀態(tài)，發(fā)現(xiàn)是正常的Sending data，沒啥特別的。

好吧，要真的放大招了，再看看InnoDB事務(wù)狀態(tài)：

------------
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

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

經(jīng)過確認(rèn)，原因確定了，事務(wù) 40199 在導(dǎo)入數(shù)據(jù)過程中，導(dǎo)入過程發(fā)生了啥問題，對(duì)導(dǎo)入線程賤賤的按了CTRL+C。

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

結(jié)果就悲劇了，導(dǎo)入線程的事務(wù)被回滾，所以才看到了那么多的undo log entries，總共是幾千萬數(shù)據(jù)啊，只不過我們看到的時(shí)候還剩下300多萬。

后來，又做了一次導(dǎo)入，這次又悲劇了，因?yàn)楣緮嗑W(wǎng)了，導(dǎo)入線程又一次被回滾（畫外音，論遠(yuǎn)程操作時(shí)用screen的重要性）。

在上面這個(gè)例子中，可能有同學(xué)會(huì)奇怪，為什么導(dǎo)入還沒結(jié)束，但卻能看到表空間文件已經(jīng)挺大的了，而且show table status也能看到rows值比較大。

• 首先，在本案例中，導(dǎo)入數(shù)據(jù)過程中，由于buffer pool有限，沒辦法把所有新數(shù)據(jù)都放在buffer pool中，部分?jǐn)?shù)據(jù)會(huì)先寫入到表空間磁盤文件中，所以才能看到表空間文件大小不為零。
• 其次，show table status看到的統(tǒng)計(jì)信息本身不是精確值，在本案中，隨著導(dǎo)入數(shù)據(jù)增多（雖然導(dǎo)入事務(wù)還沒提交），但統(tǒng)計(jì)信息也會(huì)更新。

和本案類似的場(chǎng)景還有，一個(gè)大表被執(zhí)行全表delete了（不是直接truncate），這個(gè)事務(wù)產(chǎn)生的undo log還沒被purge完畢，或者這個(gè)事務(wù)也被回滾了，在這個(gè)過程中，執(zhí)行 COUNT(*) 的結(jié)果可能和預(yù)期的不一樣。

對(duì)于以上關(guān)于MySQL查不到導(dǎo)入的數(shù)據(jù)是什么原因，大家是不是覺得非常有幫助。如果需要了解更多內(nèi)容，請(qǐng)繼續(xù)關(guān)注我們的行業(yè)資訊，相信你會(huì)喜歡上這些內(nèi)容的。