前言
最近，有一位朋友突然微信联系我，说MySQL出现了数据丢失的情况；毫无疑问，对于一个DBA而言，这无疑是最令人紧张的一件事情，没有之一；听到这个消息后，我也就立刻投入到问题排查中。
现场排查
一开始听到这个消息，我心里面当然也是非常紧张，不过很快就让自己冷静下来，开始进行排查：
（1）实例状态是不是正常的？ --经确认，实例状态正常
（2）业务库是哪个？是否还存在？是否被删除？ --经确认，业务库存在
（3）业务是访问哪个表报错？该表是否存在？是否被删除？ --经确认，业务表存在
（4）应用用户的权限是否正常？ --经确认，应用用户拥有业务库的所有权限
（5）业务访问是报什么错？ --经确认，业务侧是访问某些页面报错
（6）排查到这里，一方面是怀疑应用程序是否有异常，另一方面是怀疑是否出现部分记录丢失；开发侧和运维侧同时在排查，这边给运维侧排查的思路是 业务表是否有主键？业务侧访问报错和业务表的对应关系是怎样的？能否找出相对应的记录？
（7）进一步分析发现，该业务表有主键，开发侧也提供了查询的记录，经排查该记录存在，并未被误删除；开发侧排查应用程序，日志也未很清晰打印出报错信息
（8）在这种情况下，只能先咨询一下当晚是否有做什么变更/发布？ --经确认，当晚有做一些表的DDL变更
继续排查发现，当晚DDL变更有涉及到该业务表的操作，变更内容为修改字段长度，类似alter table xxx modify column xxx char(x)；问题到这里也就开始有思路了，接下去开始排查sql_mode配置、查询相应的完整行记录给开发确认，最终确认是DDL变更导致字段被截断，最后只能通过备份进行恢复，问题最终得到解决。
案例复现
看完刚刚的排查过程，相信很多童鞋都会有疑问，为什么修改字段长度对导致数据被截断？MySQL难道不会不会做数据校验吗？让我们接着往下看。
（1）场景1
mysql> select * from sbtest2 limit 1;
+----+---------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+
| id | k | c | pad |
+----+---------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+
| 1 | 3718516 | 08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977 | 63188288836-92351140030-06390587585-66802097351-49282961843 |
+----+---------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+
1 row in set (0.00 sec)
mysql> alter table sbtest2 modify column pad char(1);
ERROR 1265 (01000): Data truncated for column 'pad' at row 1
mysql> select * from sbtest2 limit 1;
+----+---------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+
| id | k | c | pad |
+----+---------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+
| 1 | 3718516 | 08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977 | 63188288836-92351140030-06390587585-66802097351-49282961843 |
+----+---------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+
1 row in set (0.00 sec)
（2）场景2
mysql> select * from sbtest2 limit 1;
+----+---------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+
| id | k | c | pad |
+----+---------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+
| 1 | 3718516 | 08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977 | 63188288836-92351140030-06390587585-66802097351-49282961843 |
+----+---------+-------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------+
1 row in set (0.00 sec)
mysql> alter table sbtest2 modify column pad char(1);Query OK, 100 rows affected, 100 warnings (0.06 sec)
Records: 100 Duplicates: 0 Warnings: 100
mysql> select * from sbtest2 limit 1;
+----+---------+-------------------------------------------------------------------------------------------------------------------------+------+
| id | k | c | pad |
+----+---------+-------------------------------------------------------------------------------------------------------------------------+------+
| 1 | 3718516 | 08566691963-88624912351-16662227201-46648573979-64646226163-77505759394-75470094713-41097360717-15161106334-50535565977 | 6 |
+----+---------+-------------------------------------------------------------------------------------------------------------------------+------+
1 row in set (0.00 sec)
场景1是比较符合我们预期的，直接报错“数据被截断”；场景2是执行成功，导致“数据部分丢失”；那么，MySQL是没有进行数据校验吗？其实MySQL都有对数据进行校验的，只是在场景2中，因为sql_mode配置有问题，没有设置STRICT_TRANS_TABLES，导致MySQL没有阻止该操作执行，从而导致“数据丢失”惨案。
总结
至此，“数据丢失”惨案也就可以告一段落，根本原因是sql_mode没有设置STRICT_TRANS_TABLES；这个案例也是在提醒我们，sql_mode是一个非常关键的配置，千万不可随便设置和修改；关于sql_mode的更多内容，下篇文章会继续给大家分享。
以上就是MySQL 数据丢失排查案例的详细内容，更多关于MySQL 数据丢失排查的资料请关注脚本之家其它相关文章！
您可能感兴趣的文章:- 解决docker重启redis,mysql数据丢失的问题
- MySQL使用Replace操作时造成数据丢失的问题解决
- 防止服务器宕机时MySQL数据丢失的几种方案
- MySQL 丢失数据的原因及解决
