这是学习笔记的第 2056 篇文章
如果一个线上数据库发生了问题，需要做数据恢复，作为DBA应该给自己留一些改进的余地，否则陷入两难的境地，只会让自己更加被动。
我可以随便举出一些异常的场景。
一个预置账户
比如我们的数据文件在/data下面，这个目录下有多个实例的相关数据文件，如果把这个目录误删除了，那么我们还是存在一些恢复的可能性的，这个时候我们是无法通过句柄恢复，但是可以通过mysqldump的方式转储数据文件，在数据量不大的情况下算是一个救命的方法了，当然这里我们必然要做好准备，那就是推荐配置一个管理员账号，基于本机即可，需要注意的是MySQL里面主机localhost默认是基于socket方式，而主机为127.0.0.1则默认是基于TCP/IP的连接方式，这种异常情况下，只有TCP/IP的方式依旧可靠，希望这个账户平时不需要用到，但是在一些关键时刻能够充分的使用到。
线上环境应该杜绝drop操作
在我的理解中，DBA是否有drop权限是一件值得讨论的事情。我们不能想当然的认为因为是DBA所有应该有drop权限。
在MySQL里面，基于它的设计方式（8.0之后有了默认的共享表空间，情况发生了变化），在5.7及以下版本中，完全可以通过rename操作完成，比如我们设置一个数据库test,它的归档数据库为test_arch，那我们的用户对有test_arch才有drop权限，而其他线上用户都应该杜绝，同类低于truncate操作也需要格外谨慎。
可用的备份
关键时候恢复的时候，如果发现备份存在问题不够完整，那么就失去了整个备份恢复的最后一根稻草。至于备份的方式，可以综合根据数据量使用情况来进行选型，比如阿里云的默认是物理备份的方式，可以根据实际的业务特点进行方案的对齐。
必要的表结构备份
通常在物理/逻辑的全库备份中，可以把表结构的备份也融入进去，一般来说备份表结构，这个操作基本是秒级完成，从时间成本上来说不存在问题，而有时候我们需要的仅仅是一些结构的信息，如果表数量比较大，那么使用表结构的逻辑备份就派上用场了。
异常恢复的一些技巧
上面的是一些常规的操作场景，至少有了备份恢复是可行的，但是我们不能指望一定是最完美的方案，我们需要在技能上占领高地，提前储备一些技能，以防数据恢复时的被动。
- 解析.frm文件得到DDL
- 基于ibd文件的数据恢复
- 基于句柄的数据恢复方法
- 基于DML闪回方案的补充测试
这些方法，除了常规的备份之外，我们需要储备这些硬技能，让那些艰难的数据恢复场景有了一些可行性，而这个是作为后备方案，来对已有的恢复异常提供补充。
