操作数据库 update 忘了加 where

数据库线上执行的 sql 还是 dba 审核下吧

CI 中不会检测这种 SQL 吗？

回滚吧

我们线上数据库审核要求 update 不但必须有 where 还必须有 limit

拿不准就先备份再执行命令

这个时候要讲讲 jb 家的 datagrip 了，基本上风险操作都会提示的。。。
---
Unsafe query: 不带 'where' 的 'Update' 语句会同时更新所有表行

测试数据不就是这样么，我们都是要在测试环境执行一遍，再把语句给别人发布

出来工作第一年的时候我干过一模一样的事情

最后的结果就是领导陪我修数据修到十一点半，更绝的是当时领导还一只手受伤打着石膏，一只手在敲命令

往事不堪回首啊，曾经的自己真是又年轻又菜，虽然现在年轻都没有了只剩下菜

盲猜 navicat 。
一般 GUI 要么提醒没有 where ，要么自动开启事务。

这时候就体现出 autocommit 是 off 的好处了，我每次都得手动 commit 。

记得是有个配置可以配的，限制 update 必须带 where ，可以避免这种疏忽大意的问题

更新 sql 习惯性的会先 select 一下

之前在小公司的时候, 也有过直接命令行执行 SQL update 处理数据的经历. 每次在执行前都要重复看三次才能执行. 执行的时候心都是悬的.
后来到大了点的公司,生产环境就只有 DBA 才有权限了,都是发邮件去通知执行. 虽然操作上麻烦了,但是有人帮你审核就好多了.

前段时间本人在生产上执行了一个没有 where 的 update 句，还好是新功能还在灰度，影响不大

执行 sql 要两个人一起还是有效果的

出来工作第一年的时候我干过一模一样的事情 +1

大兄弟 推荐你用 mysqlworkbench https://wuhao.pw/archives/291/
执行 update 都是要 where 和 limit 来限制的，否则会提示安全风险。

所以说生产环境一般会开启没有 where 不让 update 的设置, 防这种情况.

哈哈哈，我实习第一年也这样弄过，还好废了九牛二虎之力，给恢复了

经历过，还好是开发环境，后来另一个同事生产环境来了一次，用阿里云的秒级备份恢复了

维护过一个屎山，里面的 deleteById 方法里面没有 where 。。

我们线上要三方确认，才能执行

以前公司有一天上班内部系统所有人都登录不上去了，提示密码错误。后来一看 发现所有账号的密码都是摸一样，结果是一个实习生 update 秘密没加条件，还好是公司内部系统。 从那以后所有开发人员只有查看权限了

update 是 DML 怎么会直接更新呢，除非直接带 commit 上去，兄弟这么勇的啊，不都是先检查一番再提交吗

之前线上有个 update 未拼接上查询条件，跑了一天才发现问题，还好用的 RDS 支持数据恢复

golang 的 gorm

db.Where(User{})

几年前遇到的
golang 的 gorm

db.Where(User{
id: 0
}).Update("nickname", "1234)

会直接去掉 where 执行 update

mycli 手动挡人集合！

我司只允许主键匹配的 update

打着石膏还工作？啥公司这么狠啊

有的时候操作 大意就是会犯各种低级错误
所以生产环境一定要 按规范来

没关系，这种事干一次就能记住，损失越大越深刻。

下次注意，MySQL 可以设置一下有安全提示。

https://dev.mysql.com/doc/refman/8.0/en/mysql-tips.html#safe-updates

oracle flashback 挺好用

曾经一家公司是卖软件给保险公司的，有时候出 bug 了就登录到客户的数据库改改数据，听说一个新人需要删除一批数据，再添加一些新数据，但远程数据库比较慢，他就 Google 了下怎么快速删除记录，查到了 truncate 这个命令，而且他还真敢用，结果导致了一个重大事故

害 我们小伙伴还有删表的呢

你直接断掉 update 不就行了，直接回滚无事发生，不带条件的 update 一般跑很久够你断掉了

我一般会把要执行的 SQL 写在 sublime text 上，自己 review 一遍再执行（即使是本地测试环境），生产环境的 SQL 要写进文档里让其他同事一起 review 。养成好习惯，保护好自己的年终奖

我司的 SQL 工单后台提交之前会计算一个大概的影响行数，虽然不太准

@zhoudaiyu #2 没读题，没看到是命令行

至少要把 select 的语句复制一下，留着 where 呀

我操作数据库，都先备份整个库。还好生产环境和我没啥关系，不然太刺激了，受不了，也备份不动

咦？我用的 ORM 如果不写 Where 的话 Update 会报错，所以所有 Update 都有 Where 。
换个 ORM 吧。

不要回滚，用备份恢复数据到新表，然后根据 ID 从新表更新数据到原表即可。这样损失最小。

这个情况... 没什么规范的情况下, 只要是改库都是先 select 吧

反正我吐槽现公司让非开发人员有数据库权限这事一年多了, 都不当回事我也没办法, 开发人员手写 SQL 都那么危险, 还让运营人员直连, 真是没在社会挨过打

牛的,10 年前有幸干了一次.
我直接执行了开发传过来的升级脚本.
刚开始执行就听到他人墩墩墩吨的跑来大喊"别执行别执行!"
好家伙把我所有用户的资料全 update 了. 当时我双手都在颤抖...
没办法影响面太大只能直接回滚到一个小时之前.

每次线上执行语句，我都要测试服先试下，就怕出现这种事故。

先执行 begin 命令，然后 update ，确保没问题，再执行 commit 命令。

我们生产的一个脚本里 update 没有 where 好久了，一直没人提，我发现了但我也没提。

最近年底全面测试，被人作为 BUG 提了出来，我才改了的

CLI 手敲 SQL ，习惯先敲 where ，再移到前面敲 update ，防止手抖。。

上 archery ，不要让开发人员直接连数据库去执行 sql

我也干过，还是在生产环境……好在不是什么重要数据，而且刚刚备份完。

怕什么，又没爆头。

update xxxx where 1=1

update 和 delete 我一般后面都会加上 limit

现在我都生产环境设置为大红色了，有点警示作用。

用 dbeaver ，update 不加 where 会有危险警告，确认才会继续执行。

我有幸也干过两次，不过都是在测试环境

与 rm -rf 执行差不太多

@securityCoding
#12 这是好习惯，我也是这样，哈哈哈哈

不要怕啊，赶紧执行 rm -rf 恢复一下，快！！！！

遇到过一次 navi 的坑，查询 where 是中文字符，结果拷贝到正式环境执行的时候，中文字符被过滤掉了，变成了 where xx like '%%'

我朋友在生产环境犯了同样的错，被全集团通报了。

@feiyangenator #47 这个办法确实好，严谨

生产环境上 sql ，建议用一些 sql 审核工具吧？

只要是人就一定会出错，靠自觉是没用的。生产环境的命令一定要 code review 。即使有 review 也不能保证安全，因为可能俩人都犯傻了。所以还要限速限量，然后规模从小到大，执行一批检查一遍。
这都是无数事故总结出来的经验。

update 忘了加 where

大哥，你们平台就没个提醒的？这都能直接提交？就离谱，这哪能靠人自觉啊！

我用 heidisql ，如果没 where 执行前会提示你

敏感操作前先备份是好习惯
话说 测试库 不是随便玩

rm -rf / 这个操作我还真干过，不过立马反映过来，中止了！只是损失了一些数据，系统没有受影响！想想都后怕

@weiwenhao 哈哈，用 0 当成没传参数了吧

一般提交这种 sql 需要多叫几个人 check 一下。

线上数据库除了查询操作，其他都需要发公文让领导知道，哪怕是一条 sql ，目前公司政策

教训：在做 update/delete 之前 一定要先 select 一下

先写查询 /匹配语句，检查语句没有问题后，再写操作命令(update/delete)

update table set delete_time='xxxxx' where (order_id)
这种语句竟然不报错

我们一般就是先查询有多少条 然后再 update limit 查询条数 ，如果只处理 1 条 就是 limit 1

线上都是先敲好 where 语句，然后再补 update ... set ...
就怕手抖提交了

领导：问题不大。这小伙子永远不要再碰数据库了。

程序员的必经过程之一。

今天一样的经历，好在是测试数据库，binglog 也是 row 。很快就修复了。以后说什么终端打 sql 要加 begin 了。

妈耶 看到这标题我血压就开始升高了 敏感操作前备份是个好习惯 好歹能回滚下

1.无论是 SQL 、程序代码、甚至在服务器上安装程序，或者在服务器上执行 shell ，请都先在相同的测试环境下，进行测试。执行后，确认业务任然正常，确认压测结论没有太大性能变化，再去服务器上执行。

而且 SQL 这种执行前，对服务器做个数据备份，还是很有必要的。

2.这种方案，不仅能避免自己写错导致的问题，甚至连一些软件的 bug ，也能避开一部分。

3.千万别偷懒，请做好测试，请在正式环境中执行危险操作前做好备份！

@weiwenhao gorm 这个特性，害了很多公司，很多人

以前我也办过这种事，干活的时候没看清把公司 OA 生产环境的数据库清空了。突然嗷的一嗓子整层楼乱成一团，我赶紧把昨天的备份导进去才安静下来

手动执行 update 是比较危险，最好 begin transaction ，然后 update 再 commit ；
为了保险起见，我还有个习惯是先敲 where 条件， 再退回来敲 set xx=xxx

这种事情都会经历的，不经历记不住，就看影响大小了。
当年我在小公司做的项目数据库都没备份的，直到有一次 本以为在操作测试环境， 结果操作了生产环境，把所有人昵称都改成统一的了，反正就是头皮发麻，现在那种感觉现在都记得，估计当时高血压了。
后来才养成了习惯 每个项目无论用哪种手段每天 必须备份数据库，虽然后来一次也没用的上。

想起来我前年入职第一家公司的时候，也是忘了加 where ，当时心里是真的慌得一 p 啊，只能说还好是测试环境

@lwldcr #8 同病相怜啊，我也是写的修数据脚本有 bug ，在生产环境上跑，结果把数据全清掉了，害得 cto 陪我一起修数据修到 11 点

上线 SQL 用 https://github.com/hhyo/Archery ，这个工具使用 goinception 做 SQL 的执行和备份，可以检查不安全的语句，以及执行 SQL 后回滚的 SQL 都会给你自动生成。

archery 的同类品还有如下：
https://github.com/jly8866/archer
https://github.com/cookieY/Yearning