MySQL workbench的一个坑

今天一个开发同事找到我们，问能不能帮忙做一个存储过程的恢复，因为这是一套开发测试环境，所以我们给了开发足够的权限使用，每天会在后端做一次数据库备份工作。

碰到这种数据恢复的情况，倒不是很稀奇了，不过我还是重新了解了下数据丢失的整个过程，根据描述这个存储过程不是手工直接删除的，这位同学是在workbench端打开了这个存储过程，在这个基础上进行修改，然后

存储过程就不见了。我对于这种看起来奇怪的问题比较感兴趣，于是就去他的工位那里进行了解。

经过他的描述和环境的情况，这个存储过程（假设是test_proc）通过workbench查看不到，我在后端进行了检查，在information_schema.routines里面找了下，确实没有，所以不是权限丢失的问题。

为什么这个存储过程会平白无故的不见了呢，我和这位同学聊得更细了些，让他在本地环境复现了下这个问题，他复现的步骤是：

1. 创建一个新的存储过程test_proc
2. 通过workbench工具打开，做一些编辑改动，故意修改几处让存储过程存在一些编译错误
3. 编译失败，然后选择不保存退出
4. 再次查看列表发现，刚刚的存储过程不见了。

对于这个操作，我还是带着一些幻想，如果是近期创建的，完全可以不用备份就从binlog里面抓取得到存储过程的语句，同时也可以看下在操作的那个时间节点，后端是不是做了drop的相关操作。

结果分析binlog发现，里面有多处drop procedure if exists的日志，可见我们的存储过程在变更中其实是分为两个步骤，一个是删除，一个是重建，而这个操作带来的风险就是一旦不保存退出，则会导致之前的变更被刷掉，这个问题严格来说是工具和使用中的理解的偏差导致。

如果是一个线上业务，那问题就来了。

目前对于MySQL应用开发来说，主要有以下的几类客户端工具，我们很少关注是否付费，也很容易忽略它和我们使用中的一些理解的偏差。

（1）SQLyog

SQLyog 是一个快速而简洁的管理MySQL数据库的图形化工具，由业界著名的Webyog公司出品，属于付费产品。

（2）Navicat

是一套快速、可靠并价格适中的数据库管理工具，专为简化数据库的管理及降低系统管理成本而设计，它的设计符合数据库管理员、开发人员及中小企业的需要，属于付费产品。

（3）MySQL Workbench

为MySQL设计的ER/数据库建模工具，可以支持数据库管理、数据迁移、数据建模等功能，它同时有开源和商业化两个版本。

（4）SQL developer

这个工具是Oracle推出的一款免费的数据库管理工具，它主要支持Oracle，如果要支持MySQL，则需要额外下载一个驱动包。

工具可以简化我们的工作，但是显然没有完美的工具。有时候工具带来问题。。。