当执行 Delete 时,你心慌了

运维 数据库运维
不仅仅是执行 DELETE 心里会咯噔下,多几次确认,哪怕是 INSERT,UPDATE, 甚至是 SELECT, 只要是在生产环境做的操作,都难免心里会有些紧张。

 [[427290]]

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

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

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

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

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

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

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

恰恰那一次堵塞,是我造成的。当我把Universe编译后的SQL拿出来一查,居然用了readcommitted 隔离级别。做过数据仓库的朋友都知道,OLAP 的查询,可能会横跨几个时间段,比如3个月,5个月,甚至12个月更久。

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

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

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

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

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

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

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

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

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

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

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

 

责任编辑:武晓燕 来源: 有关SQL
相关推荐

2021-11-10 08:00:00

容器开发安全

2015-07-16 16:28:02

移动app开发细节

2019-09-20 10:43:20

裁员Uber腾讯

2010-04-29 14:33:01

Unix系统

2010-04-26 16:23:52

Oracle dele

2010-04-27 11:43:41

Oracle dele

2023-05-06 10:28:14

云计算边缘计算

2015-08-13 13:44:21

优化多核

2021-03-19 09:06:33

华为ICT行业5G

2015-08-26 14:06:36

2023-11-29 20:03:03

2019-08-21 06:45:19

LTEWi-Fi网络通信

2016-09-14 16:31:17

QPS系统

2017-03-13 16:40:28

微软LinuxPowerShell

2015-12-04 10:23:47

2022-04-18 07:50:53

系统接入架构

2017-12-12 10:02:59

2013-09-22 09:55:23

码农程序员

2019-11-11 09:35:05

跳槽涨薪降薪

2022-02-12 17:48:03

InnoDBMySQL查询数据
点赞
收藏

51CTO技术栈公众号