前两天在朋友圈发了个小感慨：执行DELETE的时候，你慌了吗？没想到，每个人的内心戏都挺丰富的。老实说，我也是。不仅仅是执行DELETE会让我的心怦怦直跳，还要确认好几次，哪怕是INSERT、UPDATE，甚至是SELECT，只要是在生产中执行的操作环境，难免会有些紧张。然后有朋友说，为什么执行SELECT的时候会紧张呢？这一年其实有个小故事，公司刚刚推出了SAP的BI工具BO（BusinessObjects）。这个工具最好的地方是它的Universe组件。它是OLAP元引擎。负责从业务逻辑视图到物理底层存储视图的转换。只要宇宙设计好，自助BI是完全可行的方式。但正因为Universe在设计上过于繁重，下注很大，所以在事务隔离方面做得并不好。往往会导致一条由Universe编译转换的SQL，会阻塞其他进程。正是我造成的堵塞。当我把Universe编译出来的SQL拿出来查看的时候，居然使用了readcommitted隔离级别。做过数据仓库的朋友都知道，OLAP查询可能跨越几个时间段，比如3个月，5个月，甚至12个月。如此巨大的随机访问必然给数据库服务器带来巨大的压力，尤其是CPU和IO压力。再加上长事务的锁表，这样阻塞其他进程，就没有悬念了。老板连续用了三个大写的警告：千万不要在Production上拉这么大的数据！！！从那以后，我就更加关注Universe自动生成的SQL，每次都要查看，甚至对SELECT语句有一种莫名的敬畏之情。即时查询，我必须先设置隔离级别，然后再执行。你看，SELECT是如此重要，更不用说INSERT/UPDATE/DELETE了。那么如何缓解执行过程中的焦虑情绪呢？毕竟，这只是我。当我焦虑和紧张时，我的胃会痛。朋友们给出了自己的解决方案：-备份-多次检查-先过UAT，再上传生产-写辞职报告随时离开-生产不申请DML权限-鼓起勇气，闭上眼睛，一切都结束了。除了几个小伙伴是来营造气氛的，其他的建议都不错。比如备份一个数据量不大的表；多次检查where条件；先在开发环境测试，再在生产环境执行等，实践过后觉得保护胃（当然你可能是肠子，也可能是肝胆等，毕竟每个人反应不同强调），除了少吃，还要养成良好的SQL操作习惯：确认两次以上，第一次看语法，第二次看逻辑，执行后写测试逻辑验证结果.对执行脚本做双重验证，即在开发环境中由另一个队友先帮你检查。不要随意测试在生产环境中执行更新脚本，并设置一个数据维护窗口，比如中午12:00之后需要立即更新的数据。分钟级日志备份，应用加
