内部群炸锅了，同事又删库了...( 三 ) 最近发生了一场生产事故

对于公司来说，一个不小心的删库操作，就有可能把公司删没了。毕竟删库造成的数据损失、经济损失不是所有公司都有能力承担的。
所以，生产环境的数据安全一定是重中之重。根据我多年的删库经历，也总结了一些经验分享给你们，希望对你们有所帮助。
①研发人员不能直连生产库
生产库一般由DBA或者运维来维护，研发人员很少有需要登录生产数据库查看数据的需求，就算数据真的有问题，一般情况下DBA或运维人员也能解决。
如果一个系统需要研发人员频繁的登录数据库去维护数据，这时就该考虑在系统中增加一个管理功能来使用，而不是频繁登录数据库。
所以，研发就不应该具有生产库的登录权限。如果偶尔的需要登录生产库查看数据，可以找DBA开一个临时账号。
②登录生产库使用只读账号
大部分人使用数据库都会使用连接工具，比如Navicat、SQLyog等。
每个人的电脑上，大概率也只有一个连接工具。开发库、测试库、生产库都在同一个连接工具中打开，有时只是想在开发库中修改一条数据，却不小心修改了生产库。
而MySQL的事务是自动提交的，在连接工具中，正在修改的当前行失去光标后就会自动提交事务，极其容易操作失误。
所以，如果确实的需要登录生产库，尽量使用具有只读权限的账号登录。
③关闭autocomit、多人复核
如果确实需要在生产库进行数据的增加、修改或删除，在执行sql之前最好先关闭事务的自动提交。
在需要登录生产库修改数据的情况下，想必问题也比较复杂，一条sql语句应该是完成不了，可能需要写N多个sql才能完成数据的修改。
这么多的sql ，很有可能在执行的时候会选错。有时你只是想执行一个select语句，结果发现执行的是delete 。
更坑爹的是，大部分的数据库连接工具有执行当前选中内容的功能。有时候你只想执行当前选中的内容，结果发现执行的是全部内容。
如果关闭了自动提交，就算出现上面的情况，也还有机会挽回。
比如下面这样：
--关闭事务自动提交set@@autocommit=0;--查看需要删除的数据，共65600条select*fromt_userwhereage>18anddeptid=100;--删除deletefromt_userwhereage>18;--发现有问题，回滚select*fromt_userwhereage>18anddeptid=100;rollback;--确认没问题，提交--commit;另外，在commit之前需要至少再找一个同事进行确认。所谓当局者迷，自己有时可能处于一个错误的思路上，就想当然的认为结果没问题，这时就需要一个旁观者来指点迷津。
两个人都确认没问题之后再提交，出错的机率也会小很多。
④修改数据之前先备份
备份、备份、备份，重要的事情说三遍!!!备份虽然会麻烦一点，但它是保证数据准确性最有效的手段，况且，掌握一些技巧后，备份也不是很麻烦的事情。
比如，我们删除数据之前可以先这样备份：
--创建一个和原表一样的备份表（包含索引）createtablet_user_bakliket_user;--拷贝数据到备份表INSERTintot_user_bakselect*fromt_user;--确认数据拷贝完成select*fromt_user_bak;这样备份的数据，就算原表数据误删了，甚至都不用恢复数据，只需要把备份表的名字改成原表的名字直接使用就可以了。
在生产库修改数据之前，一定要记得备份，一旦数据修改出错，这是成本最低并且最有效的恢复途径。
⑤设置数据库定期备份
生产环境，运维人员一定要设置数据库定期备份。研发人员也有义务提醒运维同事编写自动备份脚本，因为生产库一旦出现问题需要恢复数据，没有定期备份的话，麻烦的不只是运维人员，研发人员也要跟着麻烦。