MySQL意外查不到数据，知道真相后令人惊讶不已

爱被打了一巴掌 2022-01-12 04:19 466阅读 0赞

导读 刚刚导入了几千万数据，却意外的查不到，这是为何？

先执行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(\*) 的结果可能和预期的不一样。

# 本文到此结束，喜欢的朋友帮忙转发文章和关注一下，感谢！ #

程序员找出路还是要尽量提前进行职业规划和准备，千万不要说什么：“走一步，算一步”的话。在这个一睁眼就是竞争的时代，你可以放松休息，但别人会继续前进，不会等你。

## 最后送波福利 ##

#### [Java学习、面试；文档、视频资源免费获取][Java] ####

转载于:https://juejin.im/post/5cffb47d6fb9a07ee85c211a

[Java]: https://link.juejin.im?target=https%3A%2F%2Fshimo.im%2Fdocs%2Fx95TiNclyoc3riSe