当执行 Delete 时，你心慌了

当执行 Delete 时，你心慌了

前两天在朋友圈，我发了个小感慨：当执行 DELETE时，你心慌不慌?

没想到大家的内心戏，都挺丰富的。

老实讲，俺也一样。不仅仅是执行 DELETE 心里会咯噔下，多几次确认，哪怕是 INSERT，UPDATE， 甚至是 SELECT， 只要是在生产环境做的操作，都难免心里会有些紧张。

那有朋友说了，为什么执行 SELECT，心里都会紧张呢。这里面其实 有个小故事的

那年，公司刚上 BO(BusinessObjects),SAP 的一款BI工具。这款工具，最出色是它的 Universe 组件。它就是 OLAP 元引擎。负责了从业务逻辑视图到物理底层存储视图的转换。

只要 Universe 设计的好，自助BI是完全可行的一条路。

但正因为，Universe 设计得太过于重型，押宝押的大，它在事务隔离上并没有做的很出色。经常导致一条经Universe编译转换后的SQL， 会堵塞其他进程。

如此巨大的随机访问，给数据库服务器的压力，尤其是CPU，IO压力，一定是巨大的。再加上长事务的锁表，因此阻塞其他进程，就没有悬念了。

老板连用了三段大写的警告：Never pull suchhuge data on Production!!!

自此，我对 Universe 自动生成的 SQL就多了个心眼，每次都检查，甚至对 SELECT 语句，也产生莫名的敬畏。即时查询，我一定是先设置隔离级别，再执行。

你们看，SELECT都如此重要，更别说 INSERT/UPDATE/DELETE了。

那怎么缓解执行时的那种焦虑感呢?毕竟就我个人而已，焦虑紧张时，我会胃疼

朋友们纷纷给出自己的解决方法：

- 备份- 多次检查- 先走一遍UAT，再上生产- 写好辞职报告，随时走人- 千万别申请生产的DML权限- 壮起胆，闭好眼，干就完了

除了少数朋友，是来搞气氛的，其他的建议都不错。

比如，对小数据量的表，做备份;多检查几遍 where 条件;先在开发环境做测试，再去生产环境执行，等等。

经过实践，我觉得保护好自己的胃(当然你可能是肠子，或者是肝胆之类的，毕竟每个人应对紧张的反应不同)，除了少吃，就是要养成好的SQL操作习惯：

对条件确认二遍以上，第一遍看语法，第二遍看逻辑写好测试逻辑，来验证执行后的结果对执行脚本做双重验证，即由另一个队友帮你检查先在开发环境做测试不要随机在生产环境执行更新脚本，定一个数据维护窗口，比如晚上12点以后需要即时更新的数据，一定加好事务控制，先执行再验证，结果正确，再提交了解你所用数据库的备份机制，如果没有分钟级日志备份，申请加上