摘要:引言数据库一直是个大问题。那么如果做到防止数据库误删或者是误更新,可以参考下以下几点,下面总结的都是业务层面,和一些配置层面。软删除的好处也很明显,如果是业务发现误删,还能有回旋的余地。账号在非必须情况下,尽量不要参与日常运维,维护的工作。
引言
数据库一直是个大问题。如果没有做数据备份,或者是开启binlog,那真得就是没了就是没了,全表更新就是真的回不去了,就算开启了备份,也很麻烦。光是数据恢复就够喝一壶的,而且说不影响线上正在跑的业务,那是骗人的。那么如果做到防止数据库误删或者是误更新,可以参考下以下几点,下面总结的都是业务层面,和一些配置层面。
防护手段 业务代码
update delete 尽量不允许where条件为空
ThinkPHP框架where为空导致全表
$whereString = ""; $whereArr = []; $sql1 = M("test")->where($whereString)->buildSql(); $sql2 = M("test")->where($whereArr)->buildSql(); echo $sql1; // SELECT * FROM mall_test echo $sql2; // SELECT * FROM mall_test
分析:
那么问题就很尴尬了。程序员没好好检查下where条件,有可能传了空的字符串或者数组,TP框架源码我看了下,也仅仅只做了是否有传参的检查,这还远远不够
解决思路:
业务代码中每次where必须检查,大原则上不允许where为空。数据查询也不行,不小心扫描全表也造成IO和内网带宽的开销
软删除代替物理删除
这个就是比较常见的手段了,一般是多加一个字段is_delete等等标记状态的字段,如有必要,再加上删除时间。软删除的好处也很明显,如果是业务发现误删,还能有回旋的余地。又或者,在一些线上业务中,比如说可以多一个功能,比如说用户是VIP,可以恢复以前删除的文章或者是图片等等,看似很厉害,很贴心,其实就是改变删除状态而已。
启动参数限制更新必须有条件(这里以mysql为例)
-U, --safe-updates Only allow UPDATE and DELETE that uses keys.
其实UPDATE更新表也要注意防止全表更新,因为更新也产生了不可逆的结果。
grant配置权限
分配的用户应该满足最小可用权限。比如WEB应用的操作数据库账号。root账号在非必须情况下,尽量不要参与日常运维,维护的工作。勤于多多分配账号。权限的话也要控制好,比如你开放DROP TURNCATE等等这些危险命令干嘛。如果是用了软删除的逻辑,那么DELETE应该也不允许开放
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/17763.html
阅读 3224·2021-11-11 16:55
阅读 2466·2021-10-13 09:39
阅读 2393·2021-09-13 10:27
阅读 2157·2019-08-30 15:55
阅读 3084·2019-08-30 15:54
阅读 3129·2019-08-29 16:34
阅读 1822·2019-08-29 12:41
阅读 1067·2019-08-29 11:33