前言最近偶尔会收到用户反馈数据不见了，数据丢失了的问题。从现象上来看，这类问题在数据库层面就是紧急程度最高的那一类了，抛开客观条件来说，针对这一类问题的恢复手段几乎只有备份恢复+回放 Binlog，耗时一般比较久，对业务的影响也会很大。
但是，作为一个以稳定为主的软件，其实丢数据的概率是非常低的，所以这些反馈的问题，是不是真的“丢失数据了”？
问题描述某日中午接到用户反馈，用业务账号登录数据库以后，业务库不见了。
原因分析收到这个问题的时候，气氛还是很紧张的，一边联系用户授权登录数据库排查，一边也在和用户沟通，看看最近进行了哪些变更。
登录到数据库之后，发现业务库是存在的，结合用户的反馈：“业务库不见了”，初步判断是业务账号没有权限，用show grants查看之后，发现业务账号的权限只有 USAGE，类似如下效果：
代码语言：txt复制mysql> show grants;
+----------------------------------+
| Grants for test@% |
+----------------------------------+
| GRANT USAGE ON *.* TO 'test'@'%' |
+----------------------------------+
1 row in set (0.00 sec)由于只有最低的权限，这个账号显然是“看不到业务数据的”，所以重新授权之后，问题解决了。事后排查发现最初的授权操作发生在一个其他的同名账号上，类似于：
代码语言：txt复制mysql> show grants;
+-------------------------------------------------------------+
| Grants for test@10.120.117.% |
+-------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON prd_name.* TO 'test'@'10.120.117.%' |
+-------------------------------------------------------------+
1 row in set (0.00 sec)
mysql>拓展一下对于“丢失数据”这个现象来看，如果是“丢失”了整个库级别的数据，但是数据库本身又一切正常的话，其实有蛮大的可能性和这个案例是一样的问题：权限错误。引起这种问题的可能性一般是两个：1. 登录的账号匹配到了同名的其他账号；2. 授权出现了问题，导致业务账号没有权限。当然，最糟糕的情况肯定是drop database的操作，通过解析 binlog 才能定位到执行这个操作的时间。
另外一类属于“丢失部分数据”，比如某张表不见了，或者是表的某些数据不见了等等。严格的来说，这一类问题也有可能是权限错误引起的，因为 MySQL 的权限控制确实可以做到表和列级别，只是现实中一般不会用到。大多数时候是误操作，比如 update 或者 delete 的时候没有 where 条件。这种时候只能通过历史备份，再利用 binlog 进行恢复，这个操作在腾讯云上封装成了“回档”的功能。
总结一下遇到这一类问题时，可以先花一点观察一下问题的现象，可能只需要几秒钟的时间重新授权就解决这类“丢失数据”的非常紧急且非常严重问题。